Author: Alan J. Flavell Date: To: Exim User's Mailing List Subject: Re: [exim] rfc-ignorant.org - auto reporting those who rejectmailfrom:
<>
On Sat, 23 Oct 2004, David S. Madole wrote:
> From: "Alan J. Flavell" <a.flavell@???>
> >
> > I don't know about you, but one of the reasons for attempting a
> > callout is to get some idea that the offering MTA would accept a
> > "bounce" (non-delivery report, delivery status notification).
>
> Your arguments are excellent and exactly correct. And they reflect
> the reason why you and a few others might wish to use callouts.
>
> But I do not believe that it is why most people choose to use them.
> They are trying to weed out bogus incoming mail.
Oh indeed. So are we. I'm sorry if I now go and disappoint you, but
perhaps I should have said:
to get some idea that the offering MTA would accept a "bounce"
addressed to the (purported) envelope-sender.
And one of the elements in that is that they allow "MAIL FROM:<>".
And another element in that is the ability to discern between a valid
and invalid RCPT TO address. And another element is the ability to
report that at the RCPT phase, rather than (as some MTAs do) only
rejecting at the DATA phase.
> It has nothing to do with their concern over delivering a status
> notification back to the sender.
It's not the primary consideration in their minds at the time, I won't
argue with you there. But it's all part of trying to maintain an
acceptably reliable mail system in the face of hostile attacks
(without being able to know ab initio whether a given transaction is
bona fide or is an attack).
> But maybe the sender chooses that they don't care. Or that it's
> important to them, but less important than some other conflicting
> interest, so they make a choice. Isn't it their loss, not yours?
> Aren't they the one that is hurt by not knowing whether their email
> was delivered or not?
I think that depends not only on their bona fides but also on their
business relationship (using the term in its broad sense) to the other
participant. We (like any other mail admins) have to make rules which
our MTA can apply autonomously, without the ability to verify the
relationship between the would-be communicating parties.
One past case that I recall, we lost (i.e failed to deliver and failed
in our attempt to report nondelivery) a mail from the US House of
Representatives to one of their constituents working on this campus,
due to the house.gov mail servers (at that time, anyway) failing to
comply with RFCs. There have also been embarrassing moments with
certain research funding agencies whose ability to operate a reliable
mail service left, shall I say, something to be desired. In such
cases, it would behove us to be lenient; but if we showed such
leniency to all offering MTAs then we'd be waist-deep in spam.
Let me stress, just in case you haven't been following previous
discussions, that we don't by any means resort to callouts as a first
line of defence. Most spam offerings are blocked by other mechanisms
(public DNSrbls, local blacklists, various other sanity checks
performed up to and including the RCPT TO phase); and most bona fide
mails are accepted without resorting to callouts either. It's a
technique we only resort to in a minority of doubtful situations.
