JB@S61.Prime.COM (08/06/90)
I have an SMTP implementation that may or may not have a problem concerning null characters in the mail data. RFC 821 states that the mail data may contain any of the 128 ASCII character codes. This statement implys that the null character must also be handled as mail data. Is this correct. I spoken with some people about this and they do not know of any implementation that supports this. We have a customer who feels this is a problem. The mail text with a null will truncate that line of the mail data since we are using C string functions. Any comments or pointers will be appreciated. ------------------------------------------------------------------------------- John Bradley UUCP: csnet-relay!s61.prime.com!jb Internet: jb@s61.prime.com Disclaimer: These opinions are my own and not my employers.
Foner@YUKON.SCRC.SYMBOLICS.COM (Leonard N. Foner) (08/07/90)
Date: 6 Aug 90 11:03:00 GMT
From: primerd!ENI!S61!JB@bloom-beacon.mit.edu
I have an SMTP implementation that may or may not have a problem concerning
null characters in the mail data. RFC 821 states that the mail data may
contain any of the 128 ASCII character codes. This statement implys that
the null character must also be handled as mail data. Is this correct.
I spoken with some people about this and they do not know of any implementation
that supports this. We have a customer who feels this is a problem. The
mail text with a null will truncate that line of the mail data since we
are using C string functions. Any comments or pointers will be appreciated.
-------------------------------------------------------------------------------
John Bradley
UUCP: csnet-relay!s61.prime.com!jb
Internet: jb@s61.prime.com
Disclaimer: These opinions are my own and not my employers.
The Symbolics Lisp Machine implementation supports NULs in messages just
fine, thank you. Only languages which try to use NUL as an end-of-string
indicator, rather than representing strings using counts, tag bits, or both,
should suffer from this problem.
Of course, this means that those with mailers
that can't handle this are doomed to miss some
of the contents of messages certain troublemakers
might like to send. Inside this message, for example. klh@NISC.SRI.COM (Ken Harrenstien) (08/07/90)
I have an SMTP implementation that may or may not have a problem concerning
null characters in the mail data. RFC 821 states that the mail data may
contain any of the 128 ASCII character codes. This statement implys that
the null character must also be handled as mail data. Is this correct.
Yes, that is exactly what the RFC means. Correct implementations do exist.
--Kenpostel@VENERA.ISI.EDU (08/07/90)
Richard Verjinski: Sure do disagree. Read the first paragraph under the DATA command on page 21 of RFC-821. The syntax you cited applies to the "header fields" of 821 not to the mail data. --jon.
erik@naggum.uu.no (Erik Naggum) (08/08/90)
In article <130400009@S61.Prime.COM>, John Bradley writes: > I have an SMTP implementation that may or may not have a problem concerning > null characters in the mail data. RFC 821 states that the mail data may > contain any of the 128 ASCII character codes. This statement implys that > the null character must also be handled as mail data. Is this correct. That's what the standard says. I regard it as correct, and sendmail (et al) as broken. Yet another design flaw and disregard of standards in sendmail. Flame... > I spoke with some people about this and they do not know of any > implementation that supports this. We have a customer who feels > this is a problem. The mail text with a null will truncate that > line of the mail data since we are using C string functions. Any > comments or pointers will be appreciated. I think it's _wrong_ to use C string functions with Internet stuff. I made my own string library for use with network stuff. Would've been easier to do with C++ than C, but it still works pretty neatly. ((short*)string)[-1] is a length word. (256 bytes in a string is a little short of the goal, when RFC 821 says minimum maximum length of lines is 1000 characters.) Some very neat and usual expressions don't work this way. In fact, I think it's about as appropriate to use UNIX and C standard ways of doing things with the Internet as it would be with ASN.1 BER, but it tends to work most of the time, so people don't care. Aarrgghh!! [Erik Naggum] (a.k.a. "that damn purist") PS: I hope that mailing to tcp-ip and namedroppers is going to get rid of the ucbvax bogosity of using my Path field in the From header. Sorry about the problem. I didn't know this was done to my articles.
barmar@think.com (Barry Margolin) (08/09/90)
In article <9008061918.AA16065@gateway.mitre.org> rich@GATEWAY.MITRE.ORG (Richard Verjinski) writes: >The MIL-STD-1781 SMTP specification shows the BNF for an SMTP string on >page 20. ... >From this information I think that it is safe to say that the NULL >character can be passed as data, but must be preceded by the "\" >character. The original question was about mail data. The BNF you referenced was for the arguments to SMTP commands such as "RCPT TO:". SMTP doesn't parse the data after a DATA command; the only thing that has to be escaped there is a line containing a single period. In addition, if SMTP is being used to transfer RPC-822 messages (the usual case) some of the header fields have quoting requirements like the ones you described, but there are still no restrictions on the message body. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar