Subject: RE: DEPLOY: Legal liability for creating bounces from forgedmessages

From: "Jim Lyon" <[email-masked]>
Date: Thu, 26 Aug 2004 14:25:21 -0700

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).

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.

He then goes on to argue that if we validated the bounce address instead
of the PRA, he wouldn't need to generate a bounce.  He's right again.

But I don't see this minor virtue of checking bounce addresses
outweighing the fact that checking bounce addresses too often gives the
wrong answer.

-- Jim Lyon

---

From: <[email-masked]>
Date: Thu, 26 Aug 2004 19:20:15 -0400

> should be a very small fraction of the mail, and won't generate very

In my experience (which might not be typical, as I'm in a computer
science department), this case is actually fairly common.  In all of
the university environments I'm familiar with, different people have
very different opinions about how they want spam filtered.  It's also
the case that mail to certain addresses--especially mailing lists--is
filtered more stringently, and mail to other addresses--particularly
addresses to which users report bugs--is filtered far less
aggressively if at all (so as not to reject bug reports about mail).

Now two things:

  1. A significant fraction of the spam I get seems to have been sent
to more than one user at the same host.

  2. I don't think it's immoral to discard mail silently, but I think
it's highly problematic (having on occasion lost a very important
piece of mail).  It might be immoral to bounce mail to a forged
address, but a lot of people do it anyway because they fear losing one
important message silently.  In fact, I have to say I am guilty of
this, though I try to reject most of my mail in response to the SMTP
RCPT command, not after the fact.  SPFv1 is one tool that allows me to
do this.

That said, I actually don't agree that you need to generate a bounce
when your cases 1-7 exist.  The alternative, when you have multiple
recipients with different policies, is to reject all but the first
RCPT command with a 4xx error code,  With typical SMTP clients, this
has the unfortunate side effect of delaying mail for some recipients
for (typically) tens of minutes.  But, if we are talking about
extending RFC2821 anyway with things like SUBMITTER, one might
consider some kind of error code that means "send a separate copy of
message to this recipient immediately."

David

P.S., On a related note, I sent a detailed message from my nyu.edu
address to the list with some questions/concerns about the
implications of the MS license for projects in academia.  That message
appears to have been silently discarded!  Is this possible?  This is
exactly why I hate silently discarded mail... I don't know whether to
try re-sending from my gmail account or not.

---

From: Mark Shewmaker <[email-masked]>
Date: Thu, 26 Aug 2004 19:19:43 -0400

> then you need to generate a bounce (instead of rejecting a message).

You restated that really, really well.

> should be a very small fraction of the mail, and won't generate very

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
[email-masked]