--On Sunday, 13 April, 2008 00:37 +0100 Sabahattin Gucukoglu
<[EMAIL PROTECTED]> wrote:
>
> -----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)
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.
> 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.
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.
> 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.
If it is an intrusion, it has been an intrusion for around 35
years. Given installed base and deployment issues, it cannot
be changed in 2821bis.
>...
> 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.
While there is considerable flexibility in practice and, indeed,
very few MUAs communicating with submission servers do MX
evaluation to find them, today's preferred practice is to use
RFC 4409 servers for message submission, not SMTP (2821) ones.
Further, because the relationship between a submitting MUA and
the submission server is considered a private agreement by 2821,
the mechanisms used by the client to find the server are
basically part of that agreement.
If people are convinced that additional text is needed to
explain this subject, I'd be happy to incorporate suggestion as
long as people are also convinced that any further delays it
would introduce are worth it.
john
