Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!YUKON.SCRC.SYMBOLICS.COM!Foner
From: Foner@YUKON.SCRC.SYMBOLICS.COM (Leonard N. Foner)
Newsgroups: comp.protocols.tcp-ip
Subject: An SMTP Question
Message-ID: <19900806203737.8.FONER@CARDINAL.SCRC.Symbolics.COM>
Date: 6 Aug 90 20:37:00 GMT
References: <130400009@S61.Prime.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30


    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.