RE: new InputStream class for mail data

--- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: > > Since we are talking about improving SMTP data > handler > > class I want to draw attention to some performance > > issues I had found earlier while analyzing > > CharTerminatedInputStream class. > > > The point of major concern was the use of

Re: Your Mail has been Quarantined: Re: new InputStream class for mail data]

Thursday, July 17, 2003 12:36 AM Subject: [Fwd: Your Mail has been Quarantined: Re: new InputStream class for mail data] > I am getting a message such as the following each time I post email to > this list of James developers. > > Is this something I should deal with individually? Or i

RE: new InputStream class for mail data

> Thank you again, Noel, for calling my attention to FilterInputStream. You're welcome. > In the particular case with SMTPDataInputStream [...] In the case of SMTPDataInputStream, we would not want to call close(), which is why no one does. :-) > As I describe in the comment at the end of clas

RE: new InputStream class for mail data

> The SMTPDataInputStream class which I have written expresses [my] "a > period alone in a line" interpretation When you start to forward e-mail through JavaMail, let me know what happens. I expect that you will find an extra line being inserted at the end. --- Noel

Re: new InputStream class for mail data

Noel J. Bergman wrote: It all depends upon the RFC compliance. To summarize this question in my view, RFC 2821 clearly offers two interpretations (that the end of data indicator is a period alone in a line; that the end of data indicator is CRLF.CRLF) which lead to two different sets of behavior

Re: new InputStream class for mail data

I attach a revision of the class SMTPDataInputStream which I submit for your consideration. This replaces the version which I mailed to this list on July 2. The external behavior of the code has not changed. It still passes the JUnit tests. This code should run faster. I had arranged the co

RE: [Fwd: Your Mail has been Quarantined: Re: new InputStream class for mail data]

> I am getting a message such as the following each time I post email to > this list of James developers. I've gotten it, too. It appears to be an anti-spam measure that the person installed. At least the code is smart enough to bounce to the individual, and not the list. Basically, it sends yo

Re: new InputStream class for mail data

Noel J. Bergman wrote: FilteredInputStream is the right thing to extend. Thank you again, Noel, for calling my attention to FilterInputStream. I had not previously understood what purpose FilterInputStream serves in the API. But your suggestion, coming after this programming exercise in which

RE: new InputStream class for mail data

I mean March 2002 ! > -Original Message- > From: Steve Short > Sent: Wednesday, July 16, 2003 10:02 AM > To: James Developers List > Subject: RE: new InputStream class for mail data > > > > > In all cases, the filtered data is coming through > >

RE: new InputStream class for mail data

> In all cases, the filtered data is coming through > BufferedInputStream with a 1K buffer. Sandeep first submitted this idea back in March of 2003 and the SMTPHandler didn't use a buffered input stream or reader back then. We did some measurements and found that his modification did give a per

RE: new InputStream class for mail data

> Since we are talking about improving SMTP data handler > class I want to draw attention to some performance > issues I had found earlier while analyzing > CharTerminatedInputStream class. > The point of major concern was the use of read method > to read data from Socket InputStream. for example

RE: new InputStream class for mail data

Richard, > In case you are considering using that class SMTPDataInputStream, you > may want to know that I am now rewriting part of it, making what I > consider to be an improvement, an improvement stimulated by the > discussion of the last few days. It all depends upon the RFC compliance. The I

Re: new InputStream class for mail data

Hi Since we are talking about improving SMTP data handler class I want to draw attention to some performance issues I had found earlier while analyzing CharTerminatedInputStream class. The point of major concern was the use of read method to read data from Socket InputStream. for example if we co

Re: new InputStream class for mail data

In case you are considering using that class SMTPDataInputStream, you may want to know that I am now rewriting part of it, making what I consider to be an improvement, an improvement stimulated by the discussion of the last few days. Rich ---

RE: new InputStream class for mail data

> Based upon my present understanding, I would not throw an exception > (and would not throw an exception in CRLFTerminatedReader either). I > would leave the lone CR in the stream, to be dealt with by whatever > code handles it next. Do as you will, but RFC 2821 4.3.2. says that you should rejec

Re: new InputStream class for mail data

Noel J. Bergman wrote: I disagree. An empty data set can be a valid message. I find support in RFC 2821 Section 4.1.1.4. Not RFC 2821. RFC 2822, section 3.6: The only required header fields are the origination date field and the originator address field(s). All other header fields are

Re: new InputStream class for mail data

Noel J. Bergman wrote: 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 wi

RE: new InputStream class for mail data

> I disagree. An empty data set can be a valid message. I find support > in RFC 2821 Section 4.1.1.4. Not RFC 2821. RFC 2822, section 3.6: The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically opt

Re: new InputStream class for mail data

Noel J. Bergman wrote: ... as both Valdis and Keith pointed out, [ in the thread starting at http://www.imc.org/ietf-smtp/mail-archive/msg00703.html ] an empty data set isn't a valid message. I disagree. An empty data set can be a valid message. I find support in RFC 2821 Section 4.1.1.4. The

RE: new InputStream class for mail data

Richard, The statement that "the character sequence . IS NOT a line containing only a period" is wrong. As you know from your own finite state machine, the required sequence in the stream is precisely CR-LF-.-CR-LF, which would be interpreted as CR need-lf LF newline .

RE: new InputStream class for mail data

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

Re: new InputStream class for mail data

I have described how I believe the recognition of "a period alone in a line" differs from the recognition of "CRLF.CRLF" in a few places, including this list: And I have de

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 cha

RE: new InputStream class for mail data

> > The RFC states that MUST NOT appear except paired with . > > You know this because we addressed that in CRLFTerminatedReader. > But this contingency cannot be discounted, surely? It absolutely MUST be discounted. I don't see that the RFC gives any discretion. > While most people will send

RE: new InputStream class for mail data

> The RFC states that MUST NOT appear except paired with . > You know > this because we addressed that in CRLFTerminatedReader. But this contingency cannot be discounted, surely? While most people will send mail using well behaved clients it is _possible_ for CR to appear on its own, particular

RE: new InputStream class for mail data

> The changes in behavior are arguable. Not really. The RFC is clear enough. RFC 2821, section 3.3: SMTP indicates the end of the mail data by sending a line containing only a "." (period or full stop). > I argue that the right end of data indicator to recognize > is "a period alone in a

RE: new InputStream class for mail data

> My 2c is that I'd like to see RFC compliance tested this way. That would be my first priority. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

RE: new InputStream class for mail data

> I can't remember if this has been reviewed and applied or not Not yet. I haven't had time to test it, and he didn't provide a test case. There are a number of patches that have languished so far because of lack of time to test. Vincenzo is currently integrating and testing Soren's mail attribu

Re: new InputStream class for mail data

Serge Knystautas wrote: ... if you can submit this to bugzilla, it will help us track that it's reviewed. It did not occur to me to use bugzilla since the improvements, which I believe SMTPDataInputStream offers, are not necessarily fixes to bugs. The changes in behavior are arguable. I argue

RE: new InputStream class for mail data

> If you had any you made to test the old vs. new, that'd be great to see > as well. We don't have a framework in CVS yet for running JUnit tests, > but I hope to change this before too long. We do have some junit tests in /tests What we don't have is either a comprehensive set of tests, or an au

Re: new InputStream class for mail data

Richard O. Hammer wrote: Attached you will find a class that I offer for your consideration. It is called SMTPDataInputStream and it would be used in the doDATA() method of SMTPHandler. There it would replace CharTerminatedInputStream, BytesReadResetInputStream, SizeLimitedInputStream, and Dot

Re: new InputStream class for mail data

Richard, I can't remember if this has been reviewed and applied or not, which transitions nicely to what I was going to suggest anyway... if you can submit this to bugzilla, it will help us track that it's reviewed. Thanks for the patch! -- Serge Knystautas President Lokitech >> software . str