Sendmail 8.9.3 - PPP - Trouble sending encoded binaries
Jadon
I am currently trying to send uuencoded or MIME encoded files from my SCO
box.
The problem is that I am unable to send files that have a size greater than
about 50K.
If I send straight text in the message body I have no problems with larger
files eg 1MB of straight text.
If I uuencode or MIME the text file and send that I have no problem.
Any uuencoded or MIME files less than 50K work fine anything greater hangs
for awhile in the outgoing mailq and then I get an I/O error: Error 0.
The process by which I am creating my mail files is as follows
uuencode $FILE $FILE >> $MAIL_FILE
mail -s test < $MAIL_FILE
I then connect to an ISP via Dialup PPP connection
I then do a sendmail -q -v to process the mail queue.
This I what I get with the -v option.
Connecting to mail.freshcomp.com.au. via smtp...
220 bne006m.server-mail.com ESMTP
>>> EHLO fcs.freshcomp.com.au
250-bne006m.server-mail.com
250-PIPELINING
250 8BITMIME
>>> MAIL From:<ja...@fcs.blaa.com.au>
250 ok
>>> RCPT To:<ja...@blaa.com.au>
250 ok
>>> DATA
354 go ahead
It hangs here and about after 5 mins I get
ja...@blaa.com.au... I/O error: Error 0
Closing connection to mail.freshcomp.com.au.
On all other emails I get output similar to the following
ja...@blaa.com.au... Connecting to mail.freshcomp.com.au. via smtp...
220 bne006m.server-mail.com ESMTP
>>> EHLO fcs.freshcomp.com.au
250-bne006m.server-mail.com
250-PIPELINING
250 8BITMIME
>>> MAIL From:<ja...@blaa.com.au>
250 ok
>>> RCPT To:<ja...@blaa.com.au>
250 ok
>>> DATA
354 go ahead
>>> .
250 ok 996540579 qp 32238
ja...@blaa.com.au... Sent (ok 996540579 qp 32238)
Does anyone have any idea as to what I might have wrong?
Im pulling out hair at this stage and well I dont look good bald... :)
Thanks in advance.
Jadon
Jadon
"Jadon" <str...@uq.net.au> wrote in message
news:9Qq97.18407$a04....@newsfeeds.bigpond.com...
Im running sendmail 8.9.3 on a SCO 5.0.5.
I am currently trying to send uuencoded or MIME encoded files from my SCO
box.
The problem is that I am unable to send files that have a size greater than
about 50K.
If I send straight text in the message body I have no problems with larger
files eg 1MB of straight text.
If I uuencode or MIME the text file and send that I have no problem.
Any uuencoded or MIME files less than 50K work fine anything greater hangs
for awhile in the outgoing mailq and then I get an I/O error: Error 0.
The process by which I am creating my mail files is as follows
uuencode $FILE $FILE >> $MAIL_FILE
***mail -s test < $MAIL_FILE***
mail -s test ja...@blaa.com.au < $MAIL_FILE
***** **************
Jadon
clearer...
Thx Jadon
Robert Carnegie
> Correction.
>
> "Jadon" <str...@uq.net.au> wrote in message
> news:9Qq97.18407$a04....@newsfeeds.bigpond.com...
> Im running sendmail 8.9.3 on a SCO 5.0.5.
>
> I am currently trying to send uuencoded or MIME encoded files from my SCO
> box.
>
> The problem is that I am unable to send files that have a size greater than
> about 50K.
> If I send straight text in the message body I have no problems with larger
> files eg 1MB of straight text.
> Any uuencoded or MIME files less than 50K work fine anything greater hangs
> for awhile in the outgoing mailq and then I get an I/O error: Error 0.
The line I've marked ">?" I don't get you. Are you saying that 1 MB text
uuencoded _is_ accepted, but binary files aren't?
Visiting www.freshcomp.com.au (which appeared to be your ISP) left me
little wiser, but do you know for a fact that they don't have a policy
on e-mail of rejecting attached files above a certain size?
Wrapping text in MIME may cause it to be "encoded" as the original
text bytes, and that might make a difference to the server's response.
(Your sendmail itself may have a limit set in this way, for all I know ;-)
I also found out while trying to test virus-scanning on a mail client
of my own that the mail server wouldn't pass any "executable" file,
for instance one consisting of this text when named "eicar.com",
either as uuencoded or (I think) as MIME:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
In my case, I got a mail message back explaining the policy. None of
this was on the address I'm using here, btw, but on - uuencoded ;-) -
;<F]B97)T8T!R961J86,N9G-N970N8V\N=6L*
So: does the same ISP let you send similar files from another client -
it's only with sendmail that you have trouble? Are you _sure_ that
it's sendmail's problem?
Ian Peattie
>"Jadon" <str...@uq.net.au> wrote in message
>> I am currently trying to send uuencoded or MIME encoded files from my SCO
>> box.
>>
>> The problem is that I am unable to send files that have a size greater than
>> about 50K.
>> If I send straight text in the message body I have no problems with larger
>> files eg 1MB of straight text.
>>?If I uuencode or MIME the text file and send that I have no problem.
>> Any uuencoded or MIME files less than 50K work fine anything greater hangs
>> for awhile in the outgoing mailq and then I get an I/O error: Error 0.
>The line I've marked ">?" I don't get you. Are you saying that 1 MB text
>uuencoded _is_ accepted, but binary files aren't?
I've seen this happen with poorly configured modems, where the
uuencoding resulted in magic strings such as "AT +++" in the message
body. The modem would drop the line whenever an attempt was made to send
out that message.
>Wrapping text in MIME may cause it to be "encoded" as the original
>text bytes, and that might make a difference to the server's response.
Certainly encoding will make files bigger, so while a 1Mb text file
might not be hitting a size limit, a 1Mb binary will actually be bigger
then 1Mb when encoded, so could be hitting a size limit.
Ian.
--
Ian Peattie i...@john-richard.co.uk
Edinburgh, Scotland.
Robert Carnegie
> The files that I am trying to send are binary files if that makes things any
> clearer...
>
> Thx Jadon
Afterthought:
If you're allowed to send attached text files of arbitrarily large
size, but you can't send large binary files as MIME or uuencoded -
that's what I thought you were saying - then you could uuencode
a large binary file locally, producing a large local text file -
uuencode _is_ plain text, after all - and then send _that_ by MIME
(or, conceivably, uuencode it again).
Here I'm presuming that something in the system, either your server
or the ISP's, objects to handling large files depending on their type,
possibly as a matter of policy.
With this idea, the recipient would receive a large attached file which
they could save from their mail program as, they would find, a large
text file which would be your binary file uuencoded. They would then
have to use a uudecode tool on their own system to obtain the binary
data that you wanted to send.
Thinking about it, this could also be a good way to distribute a malicious
worm program of the social-engineering type amongst recipients with a
certain limited amount of technical knowledge ;-) Imagine: "Here is
a picture for you, but to defeat your company network's naughty picture
filters, you need to download a uudecode program from Tucows or somewhere
like that to run it." And when they do -
Bill Vermillion
Ian Peattie <i...@john-richard.co.uk> wrote:
>In article <f3f18bc0.01080...@posting.google.com>, rja.ca...@excite.com (Robert Carnegie) wrote:
>>"Jadon" <str...@uq.net.au> wrote in message
>>> The problem is that I am unable to send files that have a size
>>> greater than about 50K. If I send straight text in the message
>>> body I have no problems with larger files eg 1MB of straight
>>> text.
>>>?If I uuencode or MIME the text file and send that I have no problem.
>>> Any uuencoded or MIME files less than 50K work fine anything greater hangs
>>> for awhile in the outgoing mailq and then I get an I/O error: Error 0.
>>The line I've marked ">?" I don't get you. Are you saying that 1 MB text
>>uuencoded _is_ accepted, but binary files aren't?
>I've seen this happen with poorly configured modems, where the
>uuencoding resulted in magic strings such as "AT +++" in the
>message body. The modem would drop the line whenever an attempt was
>made to send out that message.
Actually the AT +++ is an escape sequence which is supposed to
require a pause before/after the +++'s so that it a string like
this in text will not reset it.
Hayes purchased the coding/rights to what has become known as the
AT command set / Hayes compatible set in 1983 or 1984 from Concord
[I believe it was Concord]. They then require royalties from
all modem manufacturers using that set. [myth has it that Hayes
invented this but they actually purchased it].
In the late 1980's manfacturers who decided they didn't wish to pay
the royalties to Hayes anymore came up with TIES - Time Independant
Escape Sequence - as the AT <pause> +++ <pause> was time DEPENDANT
and it appeared there was no way around this. [This is from memory
on the rights Hayes actually had].
Then came up with an escape sequence that would be virtually
impossible [but not totally impossible] using any data transmission
or encoding scheme at that time. So that meant that if this data
sequence appeared in any transmitted data the modem would go into
it's command mode.
It seemed to work quite well - the Telebits used this escape
sequence in at least some of the modems.
Of course there are those who feel compelled to do anything in
their power to keep everyone following their beliefs, so the
staunch Hayes advocates [evangelists?] on such newsgroups as
comp.dcom.modems, just loved putting this 'almost impossible
to occur' sequence in their messages, thus knocking all those
with TIES based modems off line. The malicious users seem to have
been with it since the earliest days.
IOW an AT+++ in an encoded message should not cause a modem
problems unless it had the pause before and after.
>>Wrapping text in MIME may cause it to be "encoded" as the original
>>text bytes, and that might make a difference to the server's response.
>Certainly encoding will make files bigger, so while a 1Mb text file
>might not be hitting a size limit, a 1Mb binary will actually be
>bigger then 1Mb when encoded, so could be hitting a size limit.
Unless we see the files he's having problems with we'll probably
never know the cause.
--
Bill Vermillion - bv @ wjv . com
Jadon
A.txt -- 75K Simple text file
B.bin -- 25K Binary file
C.bin -- 75K Binary File
A.txt.uue -- 100K uuencoded version of A.txt
B.bin.uue -- 40K uuencoded version of B.bin
C.bin.uue -- 100K uuencoded version of C.bin
Sending the above on my sco box with the command.
mail -s test blaa.com.au < file
A.txt.uue will work fine
B.bin.uue will work fine
C.bin.uue will fail after 5 mins or so with an I/O error
I dont believe it is a problem with my ISP as if I connect through windows,
and send large mails they only fail with a message if they are larger than
4MB.
I have check the uuencoded files for '+++' type commands and there are none.
Jadon
"Robert Carnegie" <rja.ca...@excite.com> wrote in message
news:f3f18bc0.01080...@posting.google.com...
Bill Vermillion
Jadon <str...@uq.net.au> wrote:
>Thx for your replies, but I will try and explain myself a little more.
>
>A.txt -- 75K Simple text file
>B.bin -- 25K Binary file
>C.bin -- 75K Binary File
>
>A.txt.uue -- 100K uuencoded version of A.txt
>B.bin.uue -- 40K uuencoded version of B.bin
>C.bin.uue -- 100K uuencoded version of C.bin
>
>Sending the above on my sco box with the command.
>
>mail -s test blaa.com.au < file
If you type 'man mail' you will see that mail expects the
destination and then it puts you in a text entry mode and expects
the mail input to end with control-D.
Two things - try putting a Control-D at the end of the file, or
use a MUA as a front end. The syntax you are truing to use
is not as documented in the man page, so perhaps you are overflowing
the input buffer.
Only a guess because I stopped using the raw mail - as above -
about 1986, and used MUAs in front and smail and sendmail as MTAs.
Jadon
specify a destination and subject and off it goes.
This fails in the same way as above.. Small file works ok.. Bigger files
fail.
mpack -s test filename m...@blaa.com.au
Im currently trying to test on another ISP to see if thats the problem.
Jadon
"Bill Vermillion" <bi...@wjv.com> wrote in message
news:GHF8p...@wjv.com...
Robert Carnegie
We're still on MMDF - in fact, we just took delivery of a server
with sendmail and decided to switch it to MMDF instead - which means,
I think, that /bin/mailx = /bin/mail _is_ our MUA. So I'd attempt
"mail -s'Robert Carnegie\'s test message' spurious...@somewhere.com.au \
< file" (but of course with a real address).
On our OpenServer 5.0.5 I'll try
uuencode /bin/sh /bin/sh >/tmp/rjac010802.uue
uuencode manpages/vi.txt vi.txt >/tmp/rjac010802b.uue # captured "man vi"
and submit them into this......
Both worked, the messages were apparently delivered intact.
(Microsoft Outlook treats /bin/sh as "binsh" with no file extension.)
Of course the rest of my system isn't at all like Jadon's. My mail
goes through MMDF by SMTP, to Microsoft Exchange on Windows NT, and
_then_ onto the Internet. Some time later, I expect to see the mail
arrive on another Exchange server on a different Internet connection.
Offhand I can't imagine how Jadon's system _or_ ISP can choose between
A.txt.uue (100 kbytes) and C.bin.uue (100 kbytes) and treat them
differently, except by the file name that appears at the start of data
and - conceivably - some pattern of bytes _other_ than "+++" in the
data that somehow kills the connection - or by decoding the file for,
for instance, virus scanning. It's highly unlikely that sendmail is
doing _that_ (I presume?)
Of course if it's the filename then there's nothing to prevent you from
typing, for instance, "uuencode binary.tif binary_tif.txt >binary.uue"
instead of "uuencode binary.tif binary.tif >binary.uue", and having it
sorted out manually at the other end - or editing the first line with a
"sed" filter on the way into the mail system, with the same result.
Very speculatively, for instance, an ISP might object to filenames
and extensions longer than 88888888.333 - which would fit with the
files being sendable through Microsoft Windows ;-) Or filenames with
multiple dots such as innocuous.txt.windows.users.wont.see.its.really.binary
- rather a ridiculous regulation, but as I say I'm speculating.
One other random idea is that from Windows, the ISP just may be
accepting mail by one of the more exotic protocols - Microsoft Outlook
and Microsoft Exchange Server, for instance - and not applying some
restriction which _is_ applied to mail coming in by SMTP.
Out of curiosity: is it feasible to set the Windows PC to use SMTP
service on SCO UNIX as the first stop for e-mail, and to see what
happens when you send a message _from_ Windows _through_ SCO UNIX
to the ISP? But I admit I'm not entirely sure what the experiment
would prove, either way...
Robert Carnegie
> Thx for your replies, but I will try and explain myself a little more.
>
> A.txt -- 75K Simple text file
> B.bin -- 25K Binary file
> C.bin -- 75K Binary File
>
> A.txt.uue -- 100K uuencoded version of A.txt
> B.bin.uue -- 40K uuencoded version of B.bin
> C.bin.uue -- 100K uuencoded version of C.bin
>
> Sending the above on my sco box with the command.
>
> mail -s test blaa.com.au < file
>
> A.txt.uue will work fine
> B.bin.uue will work fine
> C.bin.uue will fail after 5 mins or so with an I/O error
>
> I dont believe it is a problem with my ISP as if I connect through windows,
> and send large mails they only fail with a message if they are larger than
> 4MB.
> I have check the uuencoded files for '+++' type commands and there are none.
>
> Jadon
Oh, one and a half more thoughts (and another afterthought) -
this is really bugging me. Thought #1: somewhere along the line,
the system may object to mail messages that contain a large binary
file _and nothing else_. So perhaps
uuencode /bin/binary /bin/binary | mail -s"Binary" us...@spurious.com.au
won't work;
(
echo "Here comes a binary file for you!"
echo # I'm not sure if a blank line is required here, but it's neat
# man vi # would place a _lot_ of text in the message body itself ;-)
uuencode /bin/binary /bin/binary
) | mail -s"Binary" us...@spurious.com.au
might work...
This is still quite a stretch; the connection simply dying without
much of an error message (you said "with error 0"?) isn't respectable
behaviour for an ISP's mail server hypothetically rejecting a message...
The half-thought - if you're sending messages into your mailbox
_at_ the ISP, there is probably an overall total size limit
on storage. At some point, the mailbox is going to be full,
and the server won't accept more messages for that address.
The lack of error message at this point still isn't polite,
but it might account for irregular results sending A.text.uue
versus C.bin.uue; when you sent A the mailbox was empty, when
you sent C the mailbox was full or nearly full, so A was accepted
and C was not. Perhaps.
The afterthought - you can use OpenServer's "split -b" (see "man split")
to divide up a "binary" file into smaller pieces, and then uuencode each
piece separately and - perhaps - send them all in the same e-mail message.
To reassemble the pieces at the Windows command prompt, for instance,
copy /b binarypart1+binarypart2+binarypart3 binary_original
There are utilities that can handle this sort of situation automatically
at the receiving end; these tools are used for exchanging dirty pictures
on Usenet binary newsgroups, so if you want to pursue that, go ahead...
Or if the system only chokes on recognised uuencoded data, you could
substitute -
uuencode .... | mail ...
(message body starts with "begin 755 /bin/sh", or whatever, which is
automatically recognised as the start of a uuencoded file)
with
(
echo -n "menachem "
uuencode ....
) | mail ...
(so now the message body starts "menachem begin 755 /bin/sh" ;-)
This, like another of my suggestions, would require manual extraction
of the data and use of a separate uudecode tool at the receiving end -
potentially a considerable nuisance.
Two more fractional thoughts. A particularly eccentric ISP might ban
particular types of binary file, such as MP3 and other audio data files,
to reduce heavy casual use of bandwidth and copyright violation.
About half of ISPs who receive threatening letters from music company
lawyers seem to be easily scared into abusing their paying customers
at the behest of money-grabbing un-creative parasites. Let me say that
I don't have very strong views on intellectual property rights, one
way or the other, since my own intellectual capital is limited...(?)
When you receive this you may have already ruled out lunatic ISP
server configuration issues anyway (unless they're _all_ mad...)
Lastly - I noticed that my /bin/sh, uuencoded, has a lot of white space
(byte 00 00 00 00 00...) Compressing the file with a suitable tool
(compatible with something at the other end) - gzip or bzip2, q.v. -
would fix that, if it's an issue in _your_ binary files. But since
you suspect a size limit, you should already have considered compression...?
Bill Vermillion
Jadon <str...@uq.net.au> wrote:
>I have even tried using mpack which allows you to mime encode a file and
>specify a destination and subject and off it goes.
>This fails in the same way as above.. Small file works ok.. Bigger files
>fail.
>mpack -s test filename m...@blaa.com.au
>Im currently trying to test on another ISP to see if thats the problem.
Doesn't make sense as a uuencoded file will look the same as a text
file - UNLESS they are testing for attachments such as uuencoded
files. Gut feeling - which may be wrong - says you are looking in
the wrong area.
Bill
Bill Vermillion
I dropped any use of MMDF somewhere along about ODT 2.0. As I
recall MMDF at one time was multi-platform but I believe [and
someone correct me if I'm wrong] MMDF is currently only on SCO
platforms. Sendmail still has a bad reputation from the days when
you had to edit the 'noise files' but that's not needed anymore.
For NT system sendmail can be a good choice as it is a commercial
product and is far less exepensive than the MS solution/problem
[take you pick of adjective].
>Offhand I can't imagine how Jadon's system _or_ ISP can choose between
>A.txt.uue (100 kbytes) and C.bin.uue (100 kbytes) and treat them
>differently, except by the file name that appears at the start of data
>and - conceivably - some pattern of bytes _other_ than "+++" in the
>data that somehow kills the connection - or by decoding the file for,
>for instance, virus scanning. It's highly unlikely that sendmail is
>doing _that_ (I presume?)
The +++ shouldn't kill a connection as it requires a time delay
both before and after that. I don't recall if that delay is
configurable. I'd change the escape from +++ to del/del/del before
the modems got smart enought to ignore all commands except when
off-line. [I learned that running a BBS and hackers then used to
love to call BBS systems and send the escape sequence to take the
modem and system off line. Nothing in the world should be
configured to die with +++ in a text string - not in today's world.
But then there are some stupid systems out there.
I onced telneted to a name-server to see the OS which was running [
I run -H on my telnetd daemons to hide that] and imagine my
complete surprise when with no login prompt, password prompt, etc.,
I was in / with a # prompt. Stupidity still causes a lot of
network breakins.
>Of course if it's the filename then there's nothing to prevent you from
>typing, for instance, "uuencode binary.tif binary_tif.txt >binary.uue"
>instead of "uuencode binary.tif binary.tif >binary.uue", and having it
>sorted out manually at the other end - or editing the first line with a
>"sed" filter on the way into the mail system, with the same result.
Checking on/for filenames is just fooling yourself.
>Very speculatively, for instance, an ISP might object to filenames
>and extensions longer than 88888888.333 - which would fit with the
>files being sendable through Microsoft Windows ;-)
Shouldn't be a problem in an attachment.
>Or filenames with multiple dots such as
>innocuous.txt.windows.users.wont.see.its.really.binary - rather a
>ridiculous regulation, but as I say I'm speculating.
And that just hides the true extension from users who have all
known extensions turned off. That's one reason sircam spreads so
easily.
>One other random idea is that from Windows, the ISP just may be
>accepting mail by one of the more exotic protocols - Microsoft Outlook
>and Microsoft Exchange Server, for instance - and not applying some
>restriction which _is_ applied to mail coming in by SMTP.
I can't imagine any ISP doing something like that.
Jadon
different ISP and everything works fine.
Thanks All for your help.
Jadon
"Robert Carnegie" <rja.ca...@excite.com> wrote in message
news:f3f18bc0.01080...@posting.google.com...