On Mon, Apr 05, 2004 at 12:56:57PM +0100, Bruce Richardson wrote:
> On Mon, Apr 05, 2004 at 12:25:57PM +0100, Matthew Byng-Maddick wrote:
> > 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 <>.
> Well, that might be a nice extra feature but it is quite clearly not how
> Exim callout verification is intended to work.
You might be wanting to read the changelog for 4.31
> > There are legitimate reasons
> > for not accepting bounces to addresses that exist (ie. they should never
> > send mail, eg lists and forwarding-expanders etc).
> You are not doing yourself any credit, here. How can you reject "MAIL
> FROM <>" based on the recipient, when you haven't had the bloody
> recipient yet? If somebody rejects a "MAIL FROM: <>", "RCPT TO: XXX"
> pair, I don't care. The point is that they should never reject the
> "MAIL FROM: <>" line. Please read carefully and think.
I think we're talking cross-purposes here. I'm saying that the callout
shouldn't use <> because the recipient of the callout may know something
that you don't about why <>/<receiver-return-path> may not verify. Your
system rejected on the MAIL (which, by the way *MUST NOT* have a space
between the : and the < (according to both 0821 and 2821)), which is
very possibly broken behaviour anyway (because then that person can never
mail postmaster to tell you your system is broken), but what exim *should*
have done, IMO, is to cache the sender/recipient tuple (as it would have
sent them) with whatever it should have done, so that it is cacheing the
fact that *that* sender can never mail *that* recipient.
> Once again, with subtitles for the hard of thinking: Exim has changed
> its behaviour to pass on the original sender in the MAIL verb. This is
Once again, with subtitles for the hard of thinking: this is in the
changelog.
> clearly a bug. If the recipient server rejects the sender, Exim treats
No it's not.
> the server as broken and blackists it entirely, because it thinks it
> used '<>' as a sender. It is wrong and wrongfully blacklisting a
> perfectly functioning mail system.
This bit is just plain wrong. Where exim appears to be going wrong is in
not cacheing the tuple under that situation.
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
