[Top] [All Lists]

Re: RFC2821bis-09: Lines and Submission

2008-04-12 17:54:47

--On Sunday, 13 April, 2008 00:37 +0100 Sabahattin Gucukoglu
<mail(_at_)sabahattin-gucukoglu(_dot_)com> wrote:

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> |

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.


<Prev in Thread] Current Thread [Next in Thread>