On 31/01/07, Mike Cardwell <[EMAIL PROTECTED]> 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. Peter -- Peter Bowyer Email: [EMAIL PROTECTED] -- ## 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/
