-----Original Message-----
Friday, May 7, 2004, 1:40:56 PM, you wrote:
> On Thu, 6 May 2004, Andy Fletcher wrote: >> Many mailservers are configured (against the RFC guidelines) to refuse
>> mail from "<>". When performing a sender verify callout from exim,
> [..]
>> It seems to myself it would be preferable (though there may be good
>> reasons against this, please educate me) for the verify to only fail
>> if the 5xx error code is generated after the "RCPT TO:" > Despite all the related discussion since, I'm still having a problem
> with your logic here. Either the address will be verified by the
> callout, or it won't. If the peer MTA refuses (in this case, at the
> MAIL FROM:<> stage) to verify the address, then I don't see how the
> address can be verified (in that particular callout). What *do* you
> want the ACL statement to do if this happens?
It would be useful to be able to define different actions based on
which part of the transaction generated the 5xx - i.e. you could
choose to ignore the MAIL TO 5xx error, and continue with the
transaction, only halting on a 5xx at RCPT TO. Admittedly this may not
be of interest to everyone, but it provides some flexibility around
the problem of mail servers rejecting null MAIL FROM when the RCPTO TO
would actually be accepted perfectly fine (if it ever got to that
stage). IMO, running the risk of a bounce being undeliverable is
preferable over completely rejecting a message with a valid sender
just because of the 5xx on null MAIL TO.
>> Primarily I'd like any discussion to focus around my point in
>> paragraph two, regarding the point at which the 5xx error is generated > I thought I did that. The remote MTA is going to do whatever it does.
> You don't have any control over that. If they reject bounces, you
> aren't going to be able to send them any kind of protocol-correct DSN.
> It's up to you to work out whether that's the kind of sender you'd
> want to accept mail from.
Exactly, but we don't have the opportunity to do that to a great
enough level - and that's my point. The ability to handle the MAIL TO
5xx code differently would help the decision of "whether that's the kind of
sender you'd want to accept mail from" - to use your words.
> I don't see what influence you are hoping to have on "the point at
> which the 5xx error is generated", nor what you're hoping to do as a
> consequence of it.
As above, make a decision whether you'd happy to let that 5xx at MAIL
TO time slip by, as you may want to verify sender regardless of the
remote server rejecting/accepting a null MAIL TO. I suppose this is
changing the purpose of what the sender callout was for (I gather it
was to check bounces can be delivered), but as we've seen in responses
to the list, that's not what it seems to be used for so much now.
