Re: [Exim] SMTP protocol violation complaint -- false positi…

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Matthew Byng-Maddick
Data:  
Para: exim-users
Assunto: Re: [Exim] SMTP protocol violation complaint -- false positives.
On Sat, Dec 13, 2003 at 02:48:42PM +0000, David Woodhouse wrote:
> On Sat, 2003-12-13 at 13:02 +0000, Matthew Byng-Maddick wrote:
> > I have produced a patch, available at
> > http://colon.colondot.net/~mbm/exim_pipeline.patch
> There's still a possibility of the same false positives, although I'm
> not sure how _likely_ it is.


Gah. You're right. I'm just now looking at re-working smtp_getc() too.

> You can't assume, as you now do at line 520 in smtp_read_command(), that
> if smtp_inptr == smtp_inend, then you've reached the end of a group of
> commands sent by the client. The client could have sent the next command
> in the same write() call, but all kinds of things could have conspired
> to mean you haven't got the second half of that original write() yet. It
> could have just happened to be split into multiple TCP packets on a
> command boundary, it could have been split due to a short write() on the
> client side, due to buffer space shortage, etc...


Yes, actually, I think the most likely is that it hasn't been read yet due
to the 8192-byte boundary in smtp_getc(). The others are, in my opinion,
less likely to happen, especially if you can change smtp_getc() to try more
often to see if there is any data for reading.

> You may feel the likelihood, and the severity, of this false positive
> are sufficiently low that it's not worth bothering to do anything more


Not entirely. Though the current patch is a step in the right direction,
IMO, as already, you're going to reduce the number of false positives.

> -- the alternative would be to assume pipelining in all cases and
> _always_ return the less severe error if EHLO was used and the host is
> in pipelining_advertise_hosts. But it at least wants commenting that
> it's not a perfect test.


Sure. That's absolutely true. The difficulty with PIPELINING is that you
can't tell where the end of packet-data was supposed to be from the Layer
5 stream. I'm not sure any test is going to be perfect, but I'd quite like
to see apparent protocol violations logged a bit better, and I like Exim 4
for that...

Cheers

MBM

--
Matthew Byng-Maddick         <mbm@???>           http://colondot.net/