Re: [Exim] Wish list (I think) regarding sender verify callo…

Top Page
Delete this message
Reply to this message
Author: Dave C.
Date:  
To: Exim users list
CC: Alan J. Flavell
Subject: Re: [Exim] Wish list (I think) regarding sender verify callout.
On Thu, 3 Oct 2002, Philip Hazel wrote:

> On Wed, 2 Oct 2002, Dave C. wrote:
>
> > I'm not arguing where the fault lies, but to paying customers, it doesnt
> > matter. If their (relatives/friends/customer/etc) cant mail them, while
> > they can mail everyone else, then they consider it our fault. They dont
> > want to hear about RFC's, they want us to get them their mail.
>
> ... and presumably they don't care about the fact that their
> relatives/friends/customers/etc are living in an impoverished email
> world where they cannot receive bounces. THAT is the crucial point. The
> callout stuff is a distraction.


Indeed, they dont, and absent the callouts, it would never have come to
light. But they still dont care. They see it as us doing something that
prevents them getting their mail.

From my perspective, callouts can serve two purposes, and the way they
are implemented you either get both or neither:

1. Detect mail for which the MX host for the sender domain does not
accept null sender - if not, then it cannot receive bounces, so reject
all mail from that domain.

2. _if_ the MX host for the sender domain accepts null sender, and it
does RCPT-time address checking, the callout can detect if a sender
address is nonexistant or cancelled, which is a very strong indication
that the incoming message is a spam, virus, or something else
undesirable, so reject the message.

I can't imagine anyone debating the usefulness of #2, but (obviously) #1
is controversial because it can easily end up blocking lots of mail that
is not spam, not viruses, and is otherwise fully desired to be received
by the recipients.

Inseperably tying #2 to #1 effectively prevents the deployment of either
in cases where #1 is not politically acceptable, no matter how well
taken #2 would be.