On Fri, 28 Jun 2002, Derrick 'dman' Hudson wrote:
> | Yesterday it appears to me that aol.com were trying to send bounces
> | to us, but we were refusing them on the grounds that there was no
> | valid sender in the header lines.
>
> Well, AOL is RFC I :
> http://www.rfc-ignorant.org/tools/lookup.cgi?domain=aol.com
OK, I'm not going to make any excuses for them, but that's a fairly
mixed bag of reports, only one of which actually stuck - and that
wasn't on the technical basis of failing to accept postmaster address,
but on the basis of replying to the postmaster address saying that
abuse reports weren't going to be accepted that way.
It wasn't, however, this issue to which my query related. With
respect, I think you'd be better off in a general email abuse forum if
you want to have a general discussion on AOL's abuse policy.
> | rcpt to:<MAILER-DAEMON@???>
> | 550 MAILBOX NOT FOUND
> AOL claims that that address doesn't exist.
OK, I had already grasped that detail.
> | Should exim be verifying the sender of bounces via callback?
>
> The sender of a bounce is supposed to be <> (the "NULL" sender).
The _envelope_ sender, indeed. Here's a sample (I realise now that
maybe I should have included one in my original mail):
2002-06-27 23:22:44 17Nhf1-0005gG-00 rejected from omr-r03.mx.aol.com
[152.163.225.131]: there is no valid sender in any header line (envelope sender
is <>)
What is being verified here appears to be the header-from.
Here's extracts from another one, after the configuration had been
adjusted and we'd accepted it:
Return-path: <>
[...]
Received: from omr-d06.mx.aol.com ([205.188.156.71])
[...]
From: Mail Delivery Subsystem <MAILER-DAEMON@???>
[...]
The reports were indeed coming with an envelope-sender of '<>'
but with a header From: as shown.
In the exim (v3) configuration we have
sender_verify = true
headers_sender_verify = true
and, for a shortlist of domains (including this one) we had callbacks
enabled.
So is this the result of us having "header_sender_verify = true",
rather than the callback_domains setting (or maybe a combination of
the two)?
> | Ought the other partner to refuse such a callback?
>
> No. The callback should never be refused.
I hear what you say. How should a receiving MTA respond to an attempt
to send a bounce to a non-existent user, then?
> The whole point of
> callbacks is to refuse mail from sites who are badly misconfigured
_Our_ whole point in enabling callbacks, for certain domains, was to
refuse significant amounts of spam coming with counterfeit
envelope-sender addresses - addresses which in practice have nothing
to do with the site that is sending the mail - nor with the site that
is relaying it to us, for that matter - but are, for the most part,
innocent bystanders in this offence of Collateral Spam.
> (and shouldn't be necessary in the first place).
...in an ideal world, sure.
all the best
