-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all,
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) but two issues which are tickling my sense of discomfort most particularly are Lines (2.3.8) and an absent mention in 2.1 about the non-use of MX records for initial submission. I have noted other issues which I don't feel, at least until I've reread the complete draft, to warrant discussion for the current draft-standard-to-be at the moment, although I'll point them out in due course. 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. Although 1 is how I read it most and how it's probably intended, it worries me: this is yet another intrusion of the mail system upon message content, and I should like not to be burdened with it. Wrapper programs can be invoked by the user to perform the initial conversion between line conventions for a non-SMTP submission, and that should suffice for getting the desired effect without introducing further complexity into an otherwise completely transparent message transfer procedure that doesn't require knowledge of conventions for supporting all octette-oriented features of SMTP (ESMTP size, CHUNKING, etc). It is convenient to use library routines to simply send and receive every line only with <CRLF> and to respond accordingly; every line not ending with <CRLF> is simply part of the line following the previous line that was. Section 2.1 of 2821bis doesn't make it clear that the MX records aren't typically used for client connections to submission servers. Given that MX is mentioned as the means of finding gateways and final delivery systems by extension, it seems only proper to exclude submission servers, which almost never are located using this method and don't fit cleanly into the definition of a relay. 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/AwUBSAFHwyNEOmEWtR2TEQKRCQCdGhCvmETjV8jKgu9TjAwnQlp8MFYAn2XZ bM+0UGarxEWqYWPpb7zL3Wl0 =Cyo0 -----END PGP SIGNATURE-----
