-----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: 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/AwUBSAFHwyNEOmEWtR2TEQKRCQCdGhCvmETjV8jKgu9TjAwnQlp8MFYAn2XZ
bM+0UGarxEWqYWPpb7zL3Wl0
=Cyo0
-----END PGP SIGNATURE-----