Thursday 11 May 2006 14:57 skrev listrcv:
> Magnus Holmgren wrote:
> >   require  verify = recipient/callout=10s,defer_ok
> >
> > defer_ok ensures that mail will be accepted when the primary really *is*
> > down.
>
> The section in the docs on 'Callout verification' says:
>
> "Note that for a sender address, the
> callback is not to the client host that is trying to deliver the
> message, but to one of the hosts that accepts incoming mail for the
> sender's domain.
> [...]
> For a sender callout check, Exim makes SMTP connections to the
> remote hosts, to test whether a bounce message could be delivered to
> the sender address. The following SMTP commands are sent:
> [...]
> If the response to the RCPT command is a 2_xx_ code, the verification
> succeeds. If it is 5_xx_, the verification fails. For any other
> condition, Exim tries the next host, if any. If there is a problem with
> all the remote hosts, the ACL yields "defer", unless the `defer_ok'
> parameter of the `callout' option is given, in which case the condition
> is forced to succeed."
>
> Considering that, what's the actual benefit of using the defer_ok option?

Now you're quoting two sections relating to sender (callback) checks, but from 
my mail you quote the recipient (call-forward) check. I'm confused, but I'll 
cover both ways.

Using a call-forward without defer_ok would render the secondary effectively 
meaningless (except in the rare cases where a sending MTA can reach the 
secondary but not the primary for some reason, even though the latter is up). 
If the primary MX is down, the callout will return defer, and the sending MTA 
will have to retain the mail. The secondary's job is (normally) to accept 
mail when the primary is down. In the other hand, when the primary is up, 
there's really no reason to contact the secondary, but if anyone does, we ask 
the primary whether the recipient exists.

> If a SPAMer has set up MXs that point to non-accepting hosts, he will
> get the SPAM through because you set defer_ok.

The reasoning behind defer_ok on the sender verification is that it might 
cause too many false positives. That could be wrong, YMMV, try for yourself. 
Anyway, if the spammer bothers to set up a sender address that causes 
verification to defer, they could as easily set up a sender address that 
verifies OK.

-- 
Magnus Holmgren
[EMAIL PROTECTED]

Attachment: pgpqCNMIZi0Mo.pgp
Description: PGP signature

-- 
## List details at http://www.exim.org/mailman/listinfo/exim-users 
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/

Reply via email to