"Binary"/international text in mail
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.
--
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!
Jonathan Clark
>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 would claim that 7-bit ASCII isn't binary... but I would believe
that the separation of address and data works, at least for this
case. Extending the encoding mechanism would of course be easy, but
non-standard.
I'm told that X.400 separates its address and data as well.
Also that ATTMAIL provides some sort of mailing of binaries, although I
haven't been able to find out the mechanism yet (and I work there!).
>In article <72...@utzoo.UUCP>, he...@utzoo.UUCP (Henry Spencer) writes:
>> > What happens if the string "\nFrom" appears in te binary?
>Actually, the mail transport system should not care about "From "s in things.
Aye, there's the rub. You're right that it shouldn't, but too many (ie
some) do. Bummer. Perhaps we should all convert. To something.
Speaking of X.400 doesn't that use some magic internal format which
means that you really need either conversion programs in and out or a
complete new subsystem, including editors and such? I ask this having
skimmed the X.400 specs some years ago, and having had a couple of
discussions about them. Constructive comments which display my
ignorance are welcome.
--
Jonathan Clark
[NAC,attmail]!mtune!jhc
My walk has become rather more silly lately.
Andrew Draskoy
> Speaking of X.400 doesn't that use some magic internal format which
> means that you really need either conversion programs in and out or a
> complete new subsystem, including editors and such?
> Jonathan Clark
> [NAC,attmail]!mtune!jhc
X.400 uses a binary data format which is language independant (in terms
of header and envelope, not data). The envelope, header, and body are
seperate. The body may be composed of many parts, each of which can be
ASCII, telex, FAX, videotex, voice, etc.
The binary data format uses X.409 which is essentially a way of
turning linked data structures with sets, sequences, etc. into a byte
stream. X.400 defines everything you need to get from one user agent (UA)
to another. The inner workings of the UA are not defined, however, so
you can store things any way you like (though X.409 is convenient, of course).
It is a pain to have things in binary if you just want to look at a message
or run it through some UNIX filters, but it is great for working with
inside a program, since X.409 can be converted straight into a linked
data representation, and of course you don't need to parse it every time
you want to do anything.
> Perhaps we should all convert. To something.
The trend internationally is definately towards X.400. Within the states
ARPA and hence RFC822 still have a very strong hold, so X.400 is being
resisted. When people do convert from RFC822, it seems that X.400 would
be the logical choice. Certainly most of the public messaging systems
are planning X.400 compatability or gateways.
I've been thinking of writing a series of short summaries of the various
bits of X.400 if anyone is interested, since I keep getting questions
about it, and this may save me time in the long run. Send me a message
if you would like to see this.
Andrew Draskoy
dra...@ean.ubc.cdn
Henry Spencer
> 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
I thought about this a little bit, and decided not to do it on utzoo. Why?
Because it would mean that mail reaching our neighbors through us would
have at least two "From " lines on the front, where it now has one "From "
and one or more ">From ", and I am really not sure how their mailers would
react to this. Please don't tell me how they *should* react; that is not
the issue. The current situation is a botch and a blemish, but at least
people have pretty much learned to deal with it. The various mailers find
it difficult to guess return addresses as it is, and often get it wrong;
I really question the wisdom of introducing a new source of variability
in header format, however noble the motives.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
Robert Elz
> > 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...
and then writes:
> I thought about this a little bit, and decided not to do it on utzoo. Why?
> Because it would mean that mail reaching our neighbors through us would
> have at least two "From " lines on the front, where it now has one "From "
> and one or more ">From ", and I am really not sure how their mailers would
> react to this.
This seems like a separate issue, the unix "From " line at the head of
a mail item, and any subsequent ones are part of the envelope - you
should feel free to do whatever is necessary to those to maintain the
standard envelope format (eh? What standard envelope format??).
The "From " lines that it would be better not to touch are those in
th body of the mail - ones that currently tend to have a '>' stuck
in just in case someone, somewhere, were to decide that this is
really two mail items in one file.
Those ones you could leave alone (says he on a sendmail machine
that just loves to insert \n's in the middle of long lines in
the body, etc. I fixed that once, must get around to doing
it again...)
The slightly more difficult question is what to do with a mail item
that starts with "From " in the first line immediately after the
unix header line - is that part of the body, or is it another header?
Robert Elz munnari!kre