Συντάκτης: Dave C. Ημερομηνία: Προς: Alan J. Flavell Υ/ο: Exim users list Αντικείμενο: Re: [Exim] Wish list (I think) regarding sender verify callout.
On Thu, 3 Oct 2002, Alan J. Flavell wrote:
> On Wed, 2 Oct 2002, Dave C. wrote:
>
> > On Wed, 2 Oct 2002, Alan J. Flavell wrote:
> >
> > > Excuse me, but it's not the callbacks that are getting in the way of
> > > otherwise legitimate mail, it's those badly-configured servers.
> > > You're saying that under pressure from your users, you're willing to
> > > break specified procedures. We can't stop anyone from making that
> >
> > Well, technically the callbacks dont fall under specified procedures
> > either.
>
> OK, but the callbacks themselves aren't the problem. The underlying
> problem is there, whether we use callbacks or not. It just so happens
> that using callbacks reveals their defect at an earlier point in the
> procedure, _before_ we get into a situation where we need to send them
> a non-delivery report and only then find that they won't accept it.
Agreed.
So if we werent using callbacks, and we didnt need to send a bounce
(which is like 100% of the cases for most non-spam email at the site I
run, since I dont accept mail for nonexistand RCPT TO: addresses in the
first place), then we accept the mail, and the recipient is happy
becuase they got their mail.
But when you turn callbacks on, it rejects all mail, regardless of
wether it needs to bounce anyway.
Someone on the list posted something about 'the death of bounces', eg,
suggesting that due to spam and other problems he thinks perhaps they
are obsolete. At first I was quick to reject his idea, but now I have a
better one - nondelivery reports should remain internal. If User A at
ISP A tries to send a message to nonexistant User B at ISP B, ISP B
should refuse the message at SMTP time, and ISP A should be responsible
for reporting the failure to its own user. ("ISP" and "User" used as
generally as possible here, to include company mail servers, etc)
One should seek to avoid having nondelivery reports being sent from
servers under one organizations control to servers under another's
control.
