Re: RSET command - possible security loophole

[Hector Santos <hsantos@xxxxxxxxxxxxxx>]

Derek J. Balling wrote:

> That interpretation opens up the following situation as problematic:
>
> > Mail from: foo
> > rcpt to: bar
> [blah blah blah]
> > rset
> > mail from baz
> > rcpt to mat
>
> because in that interpretation, 'foo's attempt would never make it 
> into any sort of permanent state.
>
> My reading of the RFC would be much closer to THAT being the special 
> case that needs to be made (that you CAN stash and set aside for 
> later processing some state-data received prior to a RSET). But that's 
> not really all that much of a logistic stretch to make.
>
> Just my $0.02 worth.

In fact, the sender did retry the first 451 rejected transaction 5 
minutes later and it was greylist accepted.

That lead me to think about the idea of having session state point 
rejection information passed to an external process/shim called at 
RSET to clear whatever was externally recording.  An overkill 
solution, but a thought. :)

--
Sincerely

Hector Santos
http://www.santronics.com