> I agree with you that [RFC 2821, 2.3.7] seems to clearly prohibit
> SMTP clients from sending a lone CR character in message body data.
> Since I am working on server-side SMTP code, I suppose I should allow
> the possibility that a lone CR might come in.
And what would you do with it then? Throw the exception, as in
CRLFTerminatedReader?
--- Noel
-----Original Message-----
From: Richard O. Hammer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 0:11
To: James Developers List
Subject: Re: new InputStream class for mail data
Noel J. Bergman wrote:
> It is not possible, by definition, because it is not permitted. The RFC
is
> crystal clear on this point:
>
> RFC 2821, 2.3.7 Lines
>
> SMTP commands and, unless altered by a service extension, message
> data, are transmitted in "lines". Lines consist of zero or more data
> characters terminated by the sequence ASCII character "CR" (hex value
> 0D) followed immediately by ASCII character "LF" (hex value 0A).
> This termination sequence is denoted as <CRLF> in this document.
> Conforming implementations MUST NOT recognize or generate any other
> character or character sequence as a line terminator. Limits MAY be
> imposed on line lengths by servers (see section 4.5.3).
>
> 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.
>
>
>>the fact that it will probably be munged in transport is a srong
>>disincentive to sending it, but doesn;t prohibit it
>
>
> I would say that the above paragraphs constitute prohibition.
Thank you, Noel, for calling my attention back to that section, 2.3.7.
I had been thinking that section dealt principally with envelope
command lines, but now I see that it does also deal with message body
data. And yes, I agree with you that this seems to clearly prohibit
SMTP clients from sending a lone CR character in message body data.
Since I am working on server-side SMTP code, I suppose I should allow
the possibility that a lone CR might come in.
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
