-----BEGIN PGP SIGNED MESSAGE-----
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.
Cheers,
Sabahattin
- --
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
http://sabahattin-gucukoglu.com/
-----BEGIN PGP SIGNATURE-----
Version: PGP 8
Comment: QDPGP - http://community.wow.net/grt/qdpgp.html
iQA/AwUBSAFs1CNEOmEWtR2TEQKWugCgp6LF8sURR9236vBQcmE4ghARDAUAoPyI
+nR4xc18dNdxtWenLLfvvKwW
=0WyR
-----END PGP SIGNATURE-----