[nSLUG] Re: Dot test
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
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  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.
 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 .~.
mspencer at tallships.ca /( )\
-- the end -- there are no leading dots in this message. :-)
More information about the nSLUG