ietf-mxcomp
[Top] [All Lists]

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

2004-08-30 17:35:30

I strongly support including something along the lines of what you
wrote, either in core or in some BCP document accepted at the same
time.  (Though I have to say the complexity of the explanation makes
me appreciate plain-old SPF-classic a lot more, but I'll stick to
issues that are in scope...)

I just have a couple of comments.

On Mon, 30 Aug 2004 18:51:53 -0400, Mark Shewmaker 
<mark(_at_)primefactor(_dot_)com> wrote:
This vulnerability exists if local policy settings allow for a situation
in which all of the following are true:

  -  An incoming message was sent to multiple recipients,
  -  The message will ultimately be considered deliverable to some
     subset of its intended recipients,
  -  The message will also be ultimately be considered undeliverable
     to some other subset of the initial recipients, and
  -  The ultimate determination as to per-recipient deliverability
     cannot be made until after the SMTP transaction accepts the
     message for delivery.

The last condition is not quite correct, because you can make the
determination before replying to the "." at the end of the DATA
command.  Thus, I would recommend some wording along the lines of,
"The ultimate determination as to per-recipient deliverability cannot
be made before the SMTP DATA command."

A clever attacker can take advantage of this vulnerability by using any
machine with detectably differing local policy settings as an apparent
source of the attacker's forged DSNs.

How about dropping the word "clever."  From the point of view of a
standards document, the attacker's intellect is irrelevant.  (Plus, I
would argue this attack isn't really all that clever, particularly
once it's already been described in a standards document.)

An MTA can completely avoid becoming a participant in a DSN attack in
all cases by:

  Whenever all of the following is true:

  -  An incoming message is addressed to multiple participants.

  -  Those participants have local policy settings that,
     given the context of the specifics of the MTA transaction,
     mean that a per-recipient final determination of delivery
     cannot be made until after the message has been fully accepted.

  -  The MTA has not positively validated the MAIL FROM address,

What exactly does positively validated the MAIL FROM address mean,
unless you have something like SPF classic?

Also, I would argue that you don't need to positively validate the
MAIL FROM address.  All you really need to know is that whoever would
get a DSN is somehow involved in the sending of the message.

Thus, one valid test would be to run a tentative check under the
assumption that the MAIL FROM address is actually the PRA.  If the
test returns anything other than Pass or None, of course you don't
reject the mail, but instead, proceed as you outlined below, including
returning a 4.7.6 for multiple recipients.

In the case that the MAIL FROM address does Pass the Sender ID check,
then it is probably okay to go ahead and accept the mail, generating
DSNs later on.  Yes, it's still possible for an attacker to mount a
joe job attack and flood you with bounces.  But the attacker would
need to control IP addresses from which he could use your address as a
PRA, which is a lot harder than mounting the generic attack.

In fact, while I don't fully understand the motivation for having
different PRA and MAIL-FROM addresses, I gather from previous messages
that the people who want this the most are large banks that send out
bulk mail.  Bulk mailers would probably benefit the most from being
able to reach multiple recipients in a single SMTP transaction.

David