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: fix for bug 20370
Date Wed, 04 Jun 2003 16:16:14 GMT

I agree.  The RFC doesn't say what *to* do with CR or LF.  It just says that
we cannot recognize them as a valid line terminator for a command, and that
we must not emit them other than as CRLF.  They are not valid characters
within a command line.  Therefore it seems to me that the presence of an
invalid character is a 501.

You are correct that this class is only for the command line entry.  The
DATA command has a unique stream, and in theory an Extension can change the

What is your take on the attached?  Rather than throw an Exception
immediately, it consumes until it gets CRLF (or EOF), then throws a unique

	--- Noel

-----Original Message-----
From: Richard O. Hammer [mailto:ROHammer@EarthLink.net]
Sent: Wednesday, June 04, 2003 4:49
To: James Developers List
Subject: Re: fix for bug 20370

Noel J. Bergman wrote:
> Richard,
> I am looking over the submission with an eye towards incorporating it.
> only question I have is what to do in the event of invalid input.  You
> to basically ignoring the error can keeping the data.  I'm thinking that
> perhaps there ought to be an exception tossed that the handler can use to
> report the invalid input (501 error).
> Thoughts?

As I read section 2.3.7 of RFC 2821, it does not say what we (who are
writing an SMTP receiver) are supposed to do upon receipt of a loner
(a term I will use for a CR or LF which is not part of a CRLF pair).

It does say SMTP senders are not supposed to send loners, which, as
far as James is concerned, seems to lay primary responsibility for
this conformance upon javax.mail.Transport which I believe James uses.
  But secondarily, I suppose, James could and perhaps should assure
that the email addresses and message data which it hands to Transport
contain no loners.

But I believe we are now talking about using this class for reading
only the envelope.  The reading of message data is handled by a
different derivative of the Socket InputStream.

So the question to be decided, upon receipt of a loner, may be whether
we 501, silently remove it, or leave it in.  If we leave it in I
expect it would generate an error later as we parse the envelope, but
in some cases of local delivery I guess it might pass through
harmlessly (though I can't think of how).  The choice to 501 seems a
little aggressive, but it could be a sensible and good choice.
Whoever sends us a loner is breaking a rule, but the RFC does not
appoint us as policeman either.

If we change this I'll need to redraw my finite state machine (circles
and arrows labeled with characters) and change some of the code.


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

View raw message