ietf-mxcomp
[Top] [All Lists]

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

2004-08-31 02:37:23

On Tue, 2004-08-31 at 00:49, mazieres(_at_)gmail(_dot_)com wrote:
On Mon, 30 Aug 2004 23:38:01 -0400, Mark Shewmaker 
<mark(_at_)primefactor(_dot_)com> wrote:
  -  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.

Not an ultimate per-recipient determination, unless the answer is
reject-for-everyone.

Ah, I see the confusion.  By "make the determination", I read decide
whether or not each recipient wants to accept the mail.  I think what
you meant is notify the client of whatever that decision is. 

<slapping forehead with hand>

Yes, that's exactly what I meant, even though I insisted on wording
which communicated something else.

The determination
is made before the end of the SMTP transaction.  The problem is there
is no way to notify the client.

Then let me reword:

=====================================================================

6.5 Vulnerability to unintended participation in Forged DSN attacks.

This vulnerability exists if local policy settings allow for a situation
in which all of the following are true:

  -  A message is sent to multiple recipients,

  -  The recipients have differing local policy settings
     with respect to message body requirements,

  -  An ultimate determination of per-recipient nondeliverability
     cannot be communicated within the SMTP session after the receipt
     of message data, and

  -  The Return Path is forged,

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

Not only does this mean the ultimate victims will receive forged DSNs,
but the machine the attacker used to accomplish the forgery may become
known as a source of forged DSNs.

An MTA can completely avoid becoming a participant in this type of DSN
attack by preventing any of the above listed requirements from
occuring.  That is, it could do any of the following:

  -  Disallow some message recipients.
  -  Disallow local policy settings which depend on message contents.
  -  Disable sending of DSNs.

Each option has downsides.  The first option would require addition
message transmission attempts, the second option would limit desirable
functionality, and the third would hide email to become less reliable by
hiding legitimate email problems.

However, the first option is the only one which does not actually limit
mail system functionality, making it the only real option to consider.

To expand upon the first option, an MTA can completely avoid becoming a
participant in this type of 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 per-recipient final determinations of nondeliverability
     cannot be communicated until after the message has been accepted
     for delivery.

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

  Then:

  -  The MTA should give temporary rejections at "RCPT TO:" time
     to all recipients with differing message-body-related local policy 
     settings and where the recipients have not already been temporarily
or permanently rejected for other reasons, thus accepting only a
     compatible subset of  recipients and avoiding the need to create 
     DSNs at all.

     It is suggested that the MTA reject these recipients with a
     return code of 4.7.6.

     (Note that the MTA is not rejecting on the basis of too many
     recipients, rather it is rejecting on the basis of a
     security-related incompatibility in the requested recipient list.)

Given special-case conditions, there are simpler, alternative ways an
MTA can completely avoid becoming a participant in a DSN attack:

-  If the client MTA sends a "SUBMITTER" parameter to the MAIL command,
   then no per-recipient policy that addresses functionality related to
   this standard can trigger this vulnerability.  If per-recipient
   policy settings only extend to functionality related to this 
   standard, then the above recipient-rejection workaround need not be 
   used for that SMTP transaction.

-  If the server MTA obtains positive validation of the MAIL FROM
   address for a particular SMTP transaction, then for that SMTP
   transaction the server MTA need not use the recipient-rejection
   workaround given above.

-  If a future SMTP extension allows for per-recipient after-DATA
   rejects, and an SMTP session makes use of such an extension, then
   the above workaround is not needed for that session.

Avoiding the receipt of forged DSNs is generally outside the scope of
this document, however a domain that signs outgoing messages in a
recognizable way can avoid at least some types of forged DSN attacks.

Note that this workaround will not prevent DSN attacks if your domain
authorizes messages to be received by any other MTA, such as a border or
secondary MTA, and that other MTA does not do the exact set of checks as
the final MTA or checks more stringent than the final MTA.  The reason
is that when the border MTA relays the message to final MTA, even if it
rejects the message, the border MTA will then create a DSN which would
be sent to an inappropriate party if the Return Path is forged.

This second type of forged DSN attack can be avoided by ensuring that
all other MTAs your domain authorizes to receive mail do the same set of
checks.  Border and secondary MTAs can do a more stringent set of checks
than final MTAs, as long as there is never a relay from an MTA with
less-stringent tests to an MTA with more-stringent tests.

=====================================================================

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.

Somewhat off-topic, but here's one reason:  There are some legal
requirements to send some EFT notifications, (and things like those
yearly account-rules-and-conditions-and-information things), that can be
satisfied by emails if you then send paper documents if the email
bounces.  I can see where companies might want to outsource the sending
of notifications like this, trusting the outsourced sender to notify
them of rejects, but yet possibly wanting to handle the bounce
processing separately.


What do you mean by "handling
bounce processing separately"?  Presumably this is the major function
of the outsourced sender, so the sender is getting the bounces.

I was thinking more social (almost dilbertish) reasons as opposed to
reasons borne out of utter technical necessity.

For instance, I was imagining a situation in which one machine is
temporarily set up for a day or so to send semi-secure eft
notifications, after which it is wiped of all the secure-ish info
necessary for the bulk sending, (or the capability to access the
secure-ish info), and then set up for another bulk sending session of
another customer, with the bulk sender or bank or what-have-you making a
big deal about secure wipes or deletions.

And then if you don't need as much secure info to handle bounce
processing, the bounce-handling machine might be another machine
entirely, and thus might be allowed the necessary access longer.

So you might have:

   Mail-From: 
mybank-bounce-1234(_at_)bounces(_dot_)bulksender(_dot_)mybank(_dot_)com
        From: eft-notification(_at_)bulksender(_dot_)mybank(_dot_)com

So if you're the big bank in question, and you want to prove to federal
regulators that you're performing your due diligence for the regs, even
though technically clued in people will understand that having separate
bounce-handling machines isn't necessary and is quite possibly
counterproductive, (and causing you to be more likely to make mistakes),
I'm guessing that big bank folks would like to be able to jump up and
down, point at a machine that's dedicated to only receiving bounce
messages, has been doing that exclusively for xxx amount of time, etc.,
"prove" it by talking about bounce addresses, and thus completely
(hopefully) avoid any question about their behavior in that respect.

It's not really logical, and I admit I'm stretching things, but my guess
is that that's the sort of reason people want that sort of difference.

It's just a guess, and it requires marketing-type interests to override
saner technical decisions.  (Though then again I admit having thought of
doing that sort of separate-domain automated bounce processing myself,
merely out of convenience and, err, laziness.)

In any event, the fact that such requirements are so unusual, in the
only situations I could think of, put me squarely in the "keep spf1
semantics, no spf2 strings" camp.

Maybe what we need is a global modifier "display=domain" that says
what domain to display in the golden padlock.  Obviously domain must
be a suffix of the current domain, but it could be a strict suffix to
avoid confusing users with extra clutter like the "sender" in
"sender.bank.com."

To me sender_agents is a better solution to all that.  :-)

(I still need to write that up again for under a TECH-OMISSION
document.)

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com