[nSLUG] Re: Dot test

Mike Spencer mspencer at tallships.ca
Wed Nov 30 22:03:20 AST 2005


> Anyway, the next line contains a dot, and then after that there is a new
> sentence.
> <NOTHING_MORE>

Um, isn't the mailer software -- the mail client -- supposed to detect
<CRLF>.<CRLF> in the DATA and change it to <CRLF>..<CRLF> before it's
submitted to the SMTP transaction? (RFC 2821, Sec. 4.5.2)

If the NSLUG server is interpreting <CRLF>...<CRLF>, or in general,
any line of data beginning with a '.' and containging other subsequent
character, as end of DATA, it need a poke in the eye with a stick.
(Same RFC ref.)

But if individual mailers -- user apps -- are opening SMTP sessions
with the NSLUG server and then submitting an unadorned <CRLF>.<CRLF>
when such a line happens to appear in the user's message text, the
mailer is messing up. 


The matter of *ix using only <LF> as a line separator while net
transactions generally specify <CRLF> is another potential source of
confusion.  I vaguely recall [1] that some software adds <CR> before
putting stuff out on the net and removes <CR> on receipt.  RFC 2821
says, "MUST NOT" treat <LF>.<LF> as a <CRLF>.<CRLF>. Not to mention
that, AFAIK, Windoes always uses <CRLF> and M$-based software could
easily be doing weirdness with Linux-originated input.


- Mike

[1] From circa 1992, when VMS several times insisted on adding a <CR>
to every <LF> when doing something or other with a compressed file,
thereby completely corrupting it.  A script to remove every 0x0d from
every 0x0d 0x0a pair would restore the file.  Bleh.

-- 
Michael Spencer                  Nova Scotia, Canada       .~. 
                                                           /V\ 
mspencer at tallships.ca                                     /( )\
http://home.tallships.ca/mspencer/                        ^^-^^
-- the end -- there are no leading dots in this message. :-)

!DSPAM:438e5957309081672717636!




More information about the nSLUG mailing list