On Tue, 2004-03-09 at 11:39 -0600, wayne wrote:
In
<1078853166(_dot_)867(_dot_)24(_dot_)camel(_at_)hades(_dot_)cambridge(_dot_)redhat(_dot_)com>
David Woodhouse <dwmw2(_at_)infradead(_dot_)org> writes:
On Tue, 2004-03-09 at 11:01 -0600, wayne wrote:
At this time, thanks to spammers, a very large percentage of the MAIL
FROM addresses are bogus. The best current practices is to *NEVER*
use the MAIL FROM address for anything.
/me shudders. That's _so_ wrong it's scary.
I'm not sure what you think is wrong.
Sorry, I was unclear. Of course I agree that a large percentage of MAIL
FROM: addresses are bogus. It was the claim that best current practice
is to '*NEVER* use the MAIL FROM address for anything' to which I
objected.
<...>
While I think there can be a lot of useful discussion about what the
semantics that SPF defines for the MAIL FROM address and the HELO
domain should be, the immediate problem is to enlighten people that
these strings are currently dangerous to use in any way.
You appear to still be advocating using the MAIL FROM address to send
bounces to. As a result, you are advocating abusing innocent third
parties.
We seem to agree that one should do one's best to avoid generating
bounces. As much as possible should be rejected at SMTP time. I take
that to the limit for unauthenticated incoming SMTP, to the extent of
performing recipient verification callouts for domains for which I
provide MX backup services, and ensuring that policies are matched such
that any mail I accept on their behalf will also be acceptable to the
final recipient.
About the only way to get my machines to accept a mail which they only
_later_ decide they cannot deliver is to send a message from an existent
(verified by callout) sender, to an address at a domain for which I run
MX backup but where the primary is _actually_ currently down and cannot
immediately deny the existence of the recipient address. Obviously I
have to accept the mail in the case of temporary failures to contact the
primary -- that's what MX backup is all about, after all.
We seem to disagree on what should be done in _that_ situation. You
presumably would blackhole the mail, giving no indication to a
potentially valid sender that the mail didn't get to its intended
recipient.
I refuse to do that; I prioritise the correct and reliable operation of
_valid_ mail, including the generation of bounces to genuine senders,
over the desire to filter out the noise.
I would claim that my version is also best current practice, unless
we're prepared to admit that the spammers have won to the extent that
we're deliberately deciding to make the system unreliable in a vain
attempt to keep the noise down.
--
dwmw2