[Top] [All Lists]

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

2005-09-14 05:42:33

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
> 1xx response properly, is:
> S: 354
> C: lots of stuff
> S: 150-please wait
> S: 150-please wait
> S: 150 Thanks for your patience
> 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

<Prev in Thread] Current Thread [Next in Thread>