On Thursday, August 26, 2004 at 4:20 PM, Mark Shewmaker wrote (regarding
the need to generate a DSN if 7 conditions hold):
Perhaps it's a corner case in legitimate mail, but legitimate mail is
not my main concern; I'm more worried about from the standpoint of it
opening up an exploitable vulnerability, and two problems that can
result from spammers exploiting that vulnerability:
1. Spammers will get their bounce message spams to a bunch of
victims,
using the exploited machine. (Any individual victim's machine
could
of course avoid this threat by implementing SES.)
2. The exploited machine will become known as a source of bounce
spam,
and be added to domain-based blocklists.
(1) is bad in and of itself, but (2) means that if someone doesn't
like
you or your machine, that they'll be able to get you black-listed.
I think that the Internet community (not just the MARID group) needs to
hold a larger discussion on exactly when one should or should not
generate a DSN, and on what culpability one incurs by generating a DSN
for a forged message.
Unless and until that discussion occurs, I would suggest:
1. Employ SES or equivalent at your own site, to avoid suffer from
received bogus bounces.
2. Reputation systems are probably on shaky ground black-listing sites
because of generated DSNs.
3. Sites should use their own judgment in whether to generate a DSN or
silently discard messages
that they believe are forged.
Each of these is (at least arguably) in the self-interest of the party
that makes the decision.
The only way to solve this problem would be to allow for an override
of
the must-accept-100-recipients requirement in RFC 2821.
True. This would help, and is probably a good idea. But it's outside the
scope of MARID.
You can't completely avoid this problem through the addition of
classic-SPF test, and you can't completely avoid it with SES, (though
the recipients could.)
Agreed.
And that was the point of my email that you responded to: The only
way
to completely avoid this blow back vulnerability that shows up in the
no-SUBMITTER case, (other than silently dropping the email), is to
give
a transient "too many recipients" error upon the first recipient with
a
differing PRA white-list, if you haven't verified that the Return Path
is legitimate.
Yes, I understand now. And it demonstrates that SUBMITTER has some
usefulness other than just as an optimization.
-- Jim Lyon