Re: [Exim] ACL verify=sender

On Mon, 2004-01-05 at 15:28 +0000, Tony Finch wrote:
> Callout verification will help with this. However because you are behind a
> hub any SMTP-time checks that you perform will cause the message to bounce
> (rather than be rejected) which is not so good. In this case it'll cause
> a double bounce so the message will freeze on ppsw which is a bit ugly
> but not a serious problem. SMTP-time content checks cause more difficulties.

This kind of setup, with content checking done by the final recipient
rather than the incoming smarthost, doesn't _need_ to cause a
double-bounce any more than the case of a relay receiving mail for
unknown users at the target domain.

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.

In the case where we're a 'protective' relay for a machine which is
expected to be up and running, and where we are already doing recipient
verification callouts, we could theoretically use the _same_ connection
to actually _deliver_ the mail.

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.


--
dwmw2