On Sat, 25 Jun 2005, Greg A. Woods wrote:
> However if those addresses do exist then they _MUST_ accept valid
> messages, from valid sources, especially when those messages are sent
> with a null return path.
"MUST" in the RFC sense, perhaps yes. But "MUST" in the sense of "You
may not have your own policy about these things", no.
If I were to follow your rule, I would have to manually look at about
100 bounces per day that are nowadays sent to those of my addresses from
which I never send email. I am not prepared to waste my time doing this.
(Admittedly, in my case the messages are accepted by the MTA; my filter
junks them, but the principle is the same.)
> Delivery error notifications are far from the only kind of message which
> might (and in some cases "SHOULD") be sent with a null return path, as a
> quick grep through the current RFC corpus will reveal, never mind all
> the other non-standardized uses.
So what? I might have an address that is used only for triggering some
special action (it rings my cellphone, or it collects some statistics,
or whatever). It is never used as a sender in outgoing mail. It only
accepts messages from certain hosts and senders (probably using some
kind of authentication). All other messages, including null-sender
messages, are rejected. That's my policy for that address. I don't see
any problem with that.
> That doesn't quite make sense -- even in the context of the silliness of
> "signed sender addresses".
> Legitimate sources of legitimate e-mail will still have valid reasons
> for sending messages to any valid addresses, and for using the null
> return path when doing so.
And there's the rub. What is "legitimate"?
> > in order to block
> > collateral spam (aka Joe Jobs).
>
> There are lots of ways to do that.
Such as? Such messages are legitimate bounces from legitimate sources -
the problem is that they are bounces to messages you did not send.
> Blocking such junk because it uses a null return path is the most
> incorrect solution,
Nobody in this thread, IIRC, has advocated blocking messages just
because they use a null return path, without looking at other
conditions.
> but to not allow the likes of this to ever have any actual effect:
>
> IF $sender IS "<>" OR "" AND $recipient is "<Data>" THEN
> reject_recipient("Data doesn't like error notifications.")
>
> i.e. Data would get his error notifications, vacation messages and
> whatnot regardless of his desire (assuming they passed all the other
> access controls that did not depend on $sender).
If Data is a customer, I suspect he would take his custom elsewhere. I
certainly would, because you are stopping what my filter currently does,
which is
IF $sender is "" and $recipient is NOT <my sending address> THEN
discard message
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
