Author: Peter Bowyer Date: To: Exim users mailing list Subject: Re: [exim] sender callout mail_from change
On 31/01/07, Mike Cardwell <exim-users@???> wrote: > * on the Wed, Jan 31, 2007 at 09:45:59AM +0000, Peter Bowyer 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...
> > If your server is performing a sender callout, it's because the sender
> > isn't in its cache. When the reverse callout comes back, the sender is
> > the same and still isn't in the cache because the first callout hasn't
> > completed, so the loop continues.
>
> Crap. Of course.
>
> This only happens in the circumstances where both servers are using
> callouts without null senders though. I guess that's why I've not seen
> it yet. I need to rethink this now.
Correct. I think Marcus's suggestion of a non-null but
reserved-for-the-purpose sender to use in callouts might work well,
though. Force an 'accept' on it when you see it as a recipient, but
reject after data if anything gets that far.
Of course this is bending the orginal purpose of sender callouts -
which is to find out, before accepting responsibility for a message,
if we would be able to send a DSN back if we needed to.
