-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi John,
On 12 Apr 2008 at 20:37, John C Klensin <[EMAIL PROTECTED]> said: > --On Sunday, 13 April, 2008 00:37 +0100 Sabahattin Gucukoglu > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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-----
