ietf-mxcomp
[Top] [All Lists]

RE: TECH-OMISSION: Legal liability for creating bounces fromforgedmessages

2004-08-27 14:48:17

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