Re: [Exim] Urgent problem: Blanket rejection problem on upgr…

Top Page
Delete this message
Reply to this message
Author: Matthew Byng-Maddick
Date:  
To: Exim Users
Subject: Re: [Exim] Urgent problem: Blanket rejection problem on upgrade to 4.31
On Mon, Apr 05, 2004 at 12:06:49PM +0100, Bruce Richardson wrote:
> On Mon, Apr 05, 2004 at 11:55:59AM +0100, Matthew Byng-Maddick wrote:
> > On Mon, Apr 05, 2004 at 11:50:56AM +0100, Bruce Richardson wrote:
> > > the RCPT stage, because that's when the callout is happening. The
> > > problem is entirely point a). Which is a big problem.
> > Not doing it is also a big problem, especially with certain addresses
> > configured not to accept bounces (because they should never be sending
> > mail). Really you want to be cacheing the tuple, I think.
> ?? When doing callout verification, exim should always be using the <>
> address. The purpose is to verify the address that exim places in the


No. Not true, please go back and read what I wrote.

> RCPT verb. When exim is doing recipient verification, as here, that
> address is the rcpt address from the original connection. When doing
> sender verification, it's the original sender address. But exim should
> always use <> in the MAIl verb because that should never be rejected
> (broken mail setups that do reject it only have themselves to blame).


Wrong way round.

If you're verifying a sender then the reason you're doing it is to check
that you could send them a bounce later, so you check the address with a
return-path of <> because that's what you would be sending them.

If on the other hand, you're checking a recipient, then you're checking
that the recipient will receive mail from this sender, so you *SHOULD*
use the address you were given and not <>. There are legitimate reasons
for not accepting bounces to addresses that exist (ie. they should never
send mail, eg lists and forwarding-expanders etc). I would claim that
you're wrong to say that if they must accept mail they must accept a bounce.
(any bounce that went to them *has* been forged)

MBM

--
Matthew Byng-Maddick         <mbm@???>           http://colondot.net/