[Top] [All Lists]

Re: RFC2821bis-09: Lines and Submission

2008-04-12 19:33:06

Hash: SHA1

Hi John,

On 12 Apr 2008 at 20:37, John C Klensin <john+smtp(_at_)jck(_dot_)com> said:

--On Sunday, 13 April, 2008 00:37 +0100 Sabahattin Gucukoglu
<mail(_at_)sabahattin-gucukoglu(_dot_)com> wrote:

I haven't yet done a complete editorial proofread (I'll get
around to that  soon, honest, although I'm quite sure all the
obvious errors will get  fixed by the editor; will send a list
when it's finished)

Please note that it is past the end of the second Last Call on
this document.  Any proofreading comments that come in after -10
is posted will be passed on to the RFC Editor, but may or may
not be incorporated.

I have already observed corrections for previously noted editorial nits in
- -08 and earlier that were made in -09, so I suspect that this won't turn 
out to be a major problem after all.  Still, I have commenced rereading of 
the draft anew with the aim of tracking only differences in future.

2.3.8 says:

| In addition, the appearance of "bare" "CR" or "LF"
| characters in text (i.e., either without the other) has a
| long history of causing problems in mail implementations and
| applications that use the mail system as a tool.  SMTP
| client implementations MUST NOT transmit these characters
| except when they are intended as line terminators and then
| MUST, as indicated above, transmit them only as a <CRLF>
| sequence.

Which does this mean?

1.  As an SMTP client, it's entirely my responsibility to
verify that all  lines, even those sent with the DATA command,
always end exclusively with  <CRLF>, irrespective of what I've
been fed as input (whether by SMTP or by  other means, I.E.
standard input on UNIX, etc) to signify the end of a  line.

2.  Sending <CRLF> is only necessary when I intend
end-of-line, which is  true for commands or the end-of-DATA
indicator, but I am not obliged to  tamper with message data
and can safely assume that all servers can and  should accept
arbitrary ASCII message content with arbitrary line length.

The first.  This is a firm requirement and has been since we
were transporting email over FTP.  Note that receiving
implementations that allocate buffers for lines, consistent with
the minimum limits elsewhere in the document, count between CRLF
pairs, so the implications for the server side are significant.
If one wants to send something in the DATA other than
CRLF-terminated lines, there are standardized extensions for
doing so.  Of course, many receiving systems are, in the
interest of robustness, quite permissive about this, but that
behavior lies outside the standard: the receiving system has the
right to expect that it will be sent message data with
CRLF-terminated lines.

Okay, this is what I imagine was intended and have provided for, but in 
that case the paragraph immediately preceeding the one quoted appears to 
contradict this intention, since it requires that servers not recognise 
anything other than <CRLF> as a line terminator.  This would make perfect 
sense, were it not the server's responsibility to normalise improperly 
submitted message data, which is now the exception to the general case of 
handling lines in buffers terminated exclusively by <CRLF> (and in 
particular, the <CRLF>.<CRLF> to finish the message data).

As it happens, I am able to find stray CR or LF characters very easily in 
DATA lines and have a choice of either converting them to pairs or 
rejecting the entire message.  I'd prefer to reject the message, but I 
suspect I'll be accused of not being liberal if I do, as qmail once was 
for doing the same.


- -- 
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399

Version: PGP 8
Comment: QDPGP -


<Prev in Thread] Current Thread [Next in Thread>