Re: [exim] sender callout mail_from change

Top Page
Delete this message
Reply to this message
Author: Mike Cardwell
Date:  
To: exim-users
Subject: Re: [exim] sender callout mail_from change
* on the Wed, Jan 31, 2007 at 09:43:45AM +0000, Chris Lightfoot wrote:

>> No one has mentioned why sender callouts without a null sender are "bad"
>> yet. As far as I can see the worse that can happen is, a remote mail
>> server connects to yours, and sends a "MAIL FROM" and a "RCPT TO". You
>> then connect to the MX for the domain in the MAIL FROM, and do the same,
>> using the value of the "RCPT TO" in the mail from of the callout. They
>> then connect back to you to do a sender callout themselves. Then it
>> stops due to the cache... And this would only happen in the rare
>> circumstances that both servers are using sender callouts...
>> What part of the puzzle am I missing?
> you might hit a server that doesn't use cached results;


That one doesn't seem much of an issue. If I'm caching on the sender
address callout, then I will only be causing them to do a callout each
time my own cache expires. To me, that's cheap. Also, they can't
complain about me "stealing" resources, because they are performing
callouts themselves so obviously don't consider it in that way.

Note: I only do callouts on suspicious looking sending attempts, and only
then if they pass several other filters first, and only then if the null
sender callout fails, or dns.rfc-ignorant.org suggests they don't
accept null senders.

> there might be machines that do sender verification with
> random return paths or something else mad (probably rare).


I never thought of that. Does anyone have any evidence of this occuring
ever? Still, worse case scenario is an extra 2 connections for each
mail. That *is* bad, but if the callouts are performed as rarely as
mine, I don't see it as an issue.

Perhaps sender callouts without a null sender are not *always* bad, but
are bad if used inappropriately.

> if you use a null return-path then these cases can't
> happen because there is nowhere the remote side can make a
> verification callout to. in practice it may well usually
> be safe to use non-null senders.


>From what I've experienced so far, that appears to be the case. I'll

leave them turned on until something happens to change my mind.

Thanks,
Mike