Author: Magnus Holmgren Date: To: exim-users Subject: Re: [exim] Am I an open relay or aren't I?
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.
