On Mon, 5 Jan 2004, David Woodhouse wrote:
> The latter is fixed with recipient verification callouts, where the
> relay doesn't respond happily to 'RCPT TO:' until the target machine has
> actually accepted the same RCPT TO: command. So we're not lumbered with
> mail we then have to bounce.
>
> We could in theory do just the same for DATA -- if the real target is up
> and running we can attempt to deliver the mail immediately, and if it's
> rejected the relay can _also_ reject it immediately, rather than storing
> it and then being expected to (attempt to) bounce it.
"Protectively relaying" DATA is a little more complicated that RCPT:
the usual twist "multiple recipients" applies.
While you can give a different answer for each RCPT, you have to
combine the answers from all recipients into one reply.
> Admittedly RFC2821 says we SHOULD respond to the end of data as fast as
> possible, but if we're being pedantic you could assert that running
> content checks at that time is _also_ in violation of that.
Protectively verifying DATA for mailing lists (including expanding
aliases) and .forwards would get slow fast.
I'm not sure that it would be worth doing in except in situations
where the machines know each other very well.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Aitchison@??? http://www.dpmms.cam.ac.uk/~werdna
