james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: new InputStream class for mail data
Date Tue, 15 Jul 2003 17:35:06 GMT
> 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:ROHammer@EarthLink.net]
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message