[Top] [All Lists]

RFC2821bis-09: Lines and Submission

2008-04-12 16:50:36

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 

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.


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

Version: PGP 8
Comment: QDPGP -


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