Author: Dave C. Date: To: Alan J. Flavell CC: Exim users list Subject: Re: [Exim] Wish list (I think) regarding sender verify callout.
On Thu, 3 Oct 2002, Alan J. Flavell wrote:
> On Thu, 3 Oct 2002, Dave C. wrote:
>
> > Inseperably tying #2 to #1 effectively prevents the deployment of either
>
> I don't necessarily agree. As I said before, we only do callbacks on
> domains which our experience has told us are commonly associated with
> counterfeit sender addresses.
Hrm. That would work, ut does lessen the usefulness. Spammers dont stick
to forging certain domains, they randomize.
>
> In deciding whether to put a domain into that list, one can assess
> 1. whether the MX for the domain responds correctly to callbacks, and
> 2. whether there is any prospect of the MX for the domain actually
> repudiating invalid addresses in a callback.
>
> Your objection seems to be based on the consequences of doing
> callbacks on _all_ domains, without regard to their behaviour. As I
> said before - there seems to be no point in wasting effort on callback
> to a domain which invariably responds "recipient syntactically ok"
> or "ok, will relay" etc. to whatever nonsense RCPT TO one feeds it.
>
> Equally, there's no point in trying callback to a domain which never
> responds to SMTP, or one which is known to misbehave in response to
> bounces.
>
> You might argue that you can't or won't expend the effort on managing
> this list of callback domains. That's fine too. I'm just trying to
> say that there are options - it's not as black/white as you make it
> out to be.
Well, when some of this management could be handled automatically, eg,
'if this server doesnt accept MAIL FROM: <>', then just dont bother
verifing senders from that domain - yes, I could determine that by hand
on a 500,000+ messages per day server by expending quite a bit of time
poking through logs and doing manual checks, but why doesnt it make
sense to have exim be capable of doing it on the fly? It could even be
incorporated into the callback caching patch, and in this case it would
cache to not bother trying callbacks for that particular sender
domain...
>
> all the best
>
>
Perhaps it would be nice to have a callback option that would:
Issue:
HELO
MAIL FROM:<>
RCPT TO:<sender@sender_domain>
RCPT TO:<completely-random-string-that-couldnt-possibly-exist-as-an-account-on-the-destination-server@sender_domain>
RSET
QUIT
If MAIL FROM:<> is not accepted, accept the inbound message. then
Cache the sender domain for no callbacks.
If MAIL FROM:<> is accepted, then
(
If RCPT TO:<sender> is not accepted, then
reject/cache as appropriate
If RCPT TO:<sender> is accepted, then
accept/cache as appropriate
If RCPT TO:<random-crap...> is accepted, then
accept/cache sender domain for no callbacks
)
Actually, to tell the truth, I think calbacks would be FAR more flexible
and powerful if you added a way to determine when to do a callback
(based on whatever ACL conditions you wanted), but then set (true/false)
variables such as:
