Re: [exim] sender callout mail_from change

John W. Baxter wrote:
> On 1/31/07 1:38 AM, "Mike Cardwell" <exim-users@???> 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...
>
> Or you call out to a server that does greylisting 4xx responses at RCPT time
> for most MAIL_FROM values, but at DATA time for <> (and the few obvious
> other) MAIL_FROM values expecting that the calling-out server will never get
> to DATA. So your callout is greylisted, and ... (what do you do?). (You
> treat 4xx as success and all is well, or you treat it as callout failure,
> then at best, they try again, your callout is accepted, and all is well
> except that you have imposed a greylisting delay even though you don't do
> greylisting.)
>
> I think.
>
> --John
>
>
>

Correct. Observed in tests.

But even other 'delays' can create timeout failures, so it is good to do
<whatever> with traffic from '<>' to postmaster et al 'smartly', even if other
traffic is handled at a more circumspect pace.

Nor is it all *that* rare to have sender callouts at both ends.

ISTR the sesame list server does 'em, (nicely cached, IRRC), so there should be
evidence in most of our logs if/as/when we have imposed inordinate delays,
greylisting on all traffic, etc.

JM2CW

Bill