On Thu, 2004-08-26 at 17:25, Jim Lyon wrote:
Mark Shewmaker point out that if you have an SMTP transaction for which
*all* of the following are true:
1. The sender didn't use SUBMITTER, and
2. There is more than one recipient, and
3. The SenderID test fails, and
4. Your MTA implements a per-user white list for SenderID failures, and
5. At least one recipient white-listed the PRA, and
6. At least one other recipient didn't white-list the PRA, and
7. You feel it's immoral to silently discard forged mail
then you need to generate a bounce (instead of rejecting a message).
You restated that really, really well.
He's right. But it's such a corner case that I'm not worried. This
should be a very small fraction of the mail, and won't generate very
many bounces at all.
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.
The only way to solve this problem would be to allow for an override of
the must-accept-100-recipients requirement in RFC 2821.
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.)
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.
(If you have positively verified the bounce address with Classic-SPF, or
with any other method of positive verification, then obviously you can
safely bounce any messages and thus would have no need to limit the
number of recipients in an attempt to avoid this vulnerability.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com