bugs in /bin/mail
John Gilmore
> Why does mail go to so much trouble to preserve
> nulls in a mail file? ... Does anyone see any
> reason why stripping nulls would have a detrimental effect?
Yes. Mail should just act as a transportation mechanism without imposing
any meaning on the data being transported. In particular, making
assumptions like "nobody would want nulls in a message" is imposing
a meaning ("Nulls are useless in mail messages").
In point of fact, if mail and news would carry nulls without trouble,
we would not have to uuencode binary programs to mail them to each other,
post them to the net, etc. Since people started mailing binaries
around, this has been noticed, and I applaud the System V maintenance
team for fixing this in their /bin/mail. Berkeley hasn't fixed it,
to my knowledge, and if Sun has fixed it (they know about it), they
haven't shipped the fixed release yet.
There are also problems with bytes in which the top bit is set, at
least in Sun/Berkeley mail. Further problems appear if you send text
which has long stretches without newlines. If anyone wants specific
bug reports, ask me for a copy -- or try it yourself!
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgil...@lll-crg.arpa
(C) Copyright 1986 by John Gilmore. May the Source be with you!
sc...@cdp.uucp
How can you send binaries in mail. What happens if the string
"\nFrom" appears in te binary? Shouldn't the user agent or
delivery system or someone be inserting a '>' before the From?
Won't this screw up the binary; or, if you don't insert the
'>', won't that screw up the user agent mail parser?
-scott
{ihnp4,...}!hplabs!cdp!scott
Henry Spencer
You can't, not reliably. Mail is definitely a text-only facility.
Whether this is a good idea or not is another question, but the current
software definitely has that restriction.
> What happens if the string
> "\nFrom" appears in te binary? Shouldn't the user agent or
> delivery system or someone be inserting a '>' before the From?
Yup.
> Won't this screw up the binary...
Yup, it will. This is why uuencode and uudecode exist, for encoding
binaries as text.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
Kenneth Ng
> In article <3000002@cdp> sc...@cdp.UUCP writes:
> >How can you send binaries in mail.
>
> cheating.
>
As long as all the sites on the path are Unix machines you are probably
ok. But if it should encounter other machines on the way I wouldn't
trust uucp or uuto at all. The worst case is if "smart" mailer routes
it over bitnet for speed purposes. I seriously doubt if there will
be ANYTHING usable after it goes to bitnet and back.
--
Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102
uucp !ihnp4!allegra!bellcore!argus!ken
*** WARNING: NOT k...@bellcore.uucp ***
!psuvax1!cmcl2!ciap!andromeda!argus!ken
bitnet(prefered) k...@orion.bitnet
McCoy: "This won't hurt a bit"
Chekov: "That's what you said last time"
McCoy: "Did it?"
Chekov: "Yes"
Daniel R. Levy
>In article <3000002@cdp> sc...@cdp.UUCP writes:
>cheating.
>and its envelope. As I know nothing about X.400 except that it weighs
>more than I care to read, and very little about other mail delivery
>systems, let me ask a possibly stupid question: do any other mail
>subsystems support this separation so that binaries could be mailed?
>Jonathan Clark
>[NAC,attmail]!mtune!jhc
>My walk has become rather more silly lately.
I'd like to pose yet another issue to feed the fire: how would one implement
mailing "binaries" on, to, or from systems where, instead of the sensible Unix
paradigm of a data file being a continuous stream of bytes, there are about a
jillion different file formats, all record-based? I'm talking in particular
about our old friend VMS. One would not only have to send the raw data
itself but also supplementary data about record boundaries, record attributes,
file attributes... etc. This would seem to call for a "neutral" exchange
format, if such were even possible.
--
------------------------------- Disclaimer: The views contained herein are
| dan levy | yvel nad | my own and are not at all those of my em-
| an engihacker @ | ployer or the administrator of any computer
| at&t computer systems division | upon which I may hack.
| skokie, illinois |
-------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
go for it! allegra,ulysses,vax135}!ttrdc!levy
g...@hoptoad.uucp
In article <7...@mtune.UUCP>, j...@mtune.UUCP (Jonathan Clark) writes:
> >How can you send binaries in mail?
> You could if /bin/mail supported a logical separation between a letter
> and its envelope.... do any other mail
> subsystems support this separation so that binaries could be mailed?
Yes, the Arpanet mail standard (Simple Mail Transfer Protocol, or SMTP,
described in RFC [Request for Comments] #821) separates the text and
the header information. It specifically allows any of the 128 possible
7-bit characters to be sent, and does a trivial encoding to allow the
"end of text" marker to appear in messages. It requires that 7-bit USASCII
be used, however, which makes things hard on people in Europe and Asia.
I note that Sendmail has a bug which does not allow ASCII NUL (0x00) to
be sent. This is in violation of RFC 821.
In article <72...@utzoo.UUCP>, he...@utzoo.UUCP (Henry Spencer) writes:
> > What happens if the string
> > "\nFrom" appears in te binary? Shouldn't the user agent or
> > delivery system or someone be inserting a '>' before the From?
>
> Yup.
Actually, the mail transport system should not care about "From "s in
things. When it gets to the far end, IF it is being delivered to a
mailbox that used "\nFrom " to delimit messages, then the far end has
to worry about this. Lettuce work towards making all the software
transparent, then when someone writes a final delivery program that
uses a different format (e.g. delivers straight to an MH folder, which
keeps each message in a separate file), the whole thing will work.
Note that local mail delivery is not built in to sendmail -- you can
change sendmail.cf to have it call /bin/foomail rather than /bin/mail
and it really won't care.
Jonathan Clark
You can't. That's why uucp(1) and uuto(1) were invented. Encoding is
cheating.
You could if /bin/mail supported a logical separation between a letter
and its envelope. As I know nothing about X.400 except that it weighs
more than I care to read, and very little about other mail delivery
systems, let me ask a possibly stupid question: do any other mail
subsystems support this separation so that binaries could be mailed?
--