[nSLUG] dot issue seems to be a mailing list bug

Jeff Warnica jeff at coherentnetworksolutions.com
Wed Nov 30 20:46:37 AST 2005


On Wed, 2005-11-30 at 20:02 -0400, Donald Teed wrote:
> 
> The SMTP server at Gmail, and my own postfix, can email a message
> containing
> a line starting with the dot and by itself (and a blank line before
> and after) 
> and continue sending lines after that.
> 

Actually telneting to nslug.ns.ca:25 and trying this out seems to
discount this theory. Likely postfix or gmail is doing something to the
message before it gets to whatever nslug is running.


> Email processed by the mailing list server is truncating the message. 
> 
> I too have used raw SMTP and know about the . used to end the message
> block,
> but that isn't what is happening in this case.  It would be
> interesting to know how 
> MTA + SMTP servers are normally able to ignore an instance of this. 
> 
Supprisingly, the relevent RFC seems to be of little help in providing a
general, correct, solution...

>From rfc 2821:


> 4.5.2 Transparency
> 
>    Without some provision for data transparency, the character sequence
>    "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
>    In general, users are not aware of such "forbidden" sequences.  To
> 
>    allow all user composed text to be transmitted transparently, the
>    following procedures are used:
> 
>    -  Before sending a line of mail text, the SMTP client checks the
>       first character of the line.  If it is a period, one additional
>       period is inserted at the beginning of the line.
> 
>    -  When a line of mail text is received by the SMTP server, it checks
>       the line.  If the line is composed of a single period, it is
>       treated as the end of mail indicator.  If the first character is a
>       period and there are other characters on the line, the first
>       character is deleted.
> 
>    The mail data may contain any of the 128 ASCII characters.  All
>    characters are to be delivered to the recipient's mailbox, including
>    spaces, vertical and horizontal tabs, and other control characters.
>    If the transmission channel provides an 8-bit byte (octet) data
>    stream, the 7-bit ASCII codes are transmitted right justified in the
>    octets, with the high order bits cleared to zero.  See 3.7 for
>    special treatment of these conditions in SMTP systems serving a relay
>    function.
> 
>    In some systems it may be necessary to transform the data as it is
>    received and stored.  This may be necessary for hosts that use a
>    different character set than ASCII as their local character set, that
>    store data in records rather than strings, or which use special
>    character sequences as delimiters inside mailboxes.  If such
>    transformations are necessary, they MUST be reversible, especially if
>    they are applied to mail being relayed.




!DSPAM:438e4e4e306117266013695!




More information about the nSLUG mailing list