Re: slow email validation problems (was reject vs bounce)

At 12:55 14/09/2005, Hector Santos wrote:

> > 1xx responses should be followed by another command from the client saying
> > whether to continue or abort the command, so what you SHOULD have to have
> a
> > 1xx response properly, is:
> >
> > C: DATAWITHCHECK
> > S: 354
> > C: lots of stuff
> > S: 150-please wait
> > S: 150-please wait
> > S: 150 Thanks for your patience
> > C: WASTHATMESSAGEOK
> > S: 550 message rejected  or S: 250 Message OK
>
> True, this would be a natural expectation, but as you are aware, it does not
> specifically state that it *must* be the same reply code.
>
> |   1yz   Positive Preliminary reply
> |     The command has been accepted, but the requested action is being
> |     held in abeyance, pending confirmation of the information in this
> |     reply.  The SMTP client should send another command specifying
> |     whether to continue or abort the action.  Note: unextended SMTP
> |     does not have any commands that allow this type of reply, and so
> |     does not have continue or abort commands.
> I guess it is assumed to be the same but that is only because the original
> usage is to display some lengthy "information" response where the final
> response code is already predetermined.
Hector, I'm not really disagreeing with you here as I think the choice of 
intermediate reply code is pretty academic - either the client will try to 
interpret it, in which case a 1yz response code might give an 'unexpected' 
error (eg if the client is hard coded to expect a 2, 4, or 5 as the first 
digit after a DATA command - which is acceptable based on the standard), 
and a 4yz and 5yz might cause a premature failure (hence my choice of 2yz), 
or the client will ignore it, in which case it doesn't matter what it was.
The description of the 1yz reply you quote above is for that being the 
FINAL reply code. It's not a 'please wait' response, it's a 'please confirm 
what to do' response. (Note the "The SMTP client should send another 
command specifying whether to continue or abort the action." sentence).
Really, the issue is, do the intermediate reply codes need to be the same 
as the final reply code (from my reading of 2821, this could be said to be 
implied by the examples, but it's certainly not explicit), and, in the case 
where they are different, which one do you use (from my reading of 2821, 
you should use the last one).
I expect that most people who have read RFC2821 and coded accordingly would 
work as you expect, with intermediate reply lines essentially being 
ignored. That's what we do here (except for EHLO responses), and it seems 
pretty clear from RFC 2821 that it's the sensible thing to. The problem is, 
we all know that people don't always follow the standards..
I think clarification in RFC 2821 bis is what is needed.


BTW, the only solution to the 'keepalive' problem that I can think of other 
than having varying reply codes is for the server to receive the message 
the first time, reply with 450- until it decides whether to accept it or 
not, then reply '450 ' to temporarily reject the message, but record 
identifying details about the message (message id, envelope details, etc), 
then wait until the sender tries to re-send it and then accept it straight 
away. (This method also sort of merges the idea of 'grey listing', so might 
be even better at stopping spam). However, the obvious drawback is that 
every message has to be sent twice - which isn't good, but I can't see any 
other way to do it.

Paul                            VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk                      http://www.pscs.co.uk/