A few more detailed comments:
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,
Okay, better. I still think it could be clearer because of the
dependence between some of these things. Also, that the message has
multiple recipients is less important than emphasizing that the
*transaction* has multiple recipients. How about saying:
1. The Return Path is forged.
2. Per-recipient non-deliverability status cannot be communicated
to the client during the SMTP transaction because
A. The transaction has multiple recipients,
B. The recipients have differing local policy settings, some
allowing and some rejecting delivery of the message, and
C. The policies are based on message headers or contents
transmitted to the server during the SMTP DATA command, and
the SMTP protocol only allows a single success or failure code
for all recipients in response to the DATA command.
3. Local policy requires the sending of a DSN for rejected
recipients of successful SMTP transactions.
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.
The term "forged DSN" may be misleading here, because the DSNs
themselves are in a sense genuine, just the message for which they are
generated are forged. So maybe substitute "maliciously-induced DSN"
for "forged DSN."
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.
Instead of "Disallow some message recipients", how about:
- Disallow combinations of recipients with different local policies
in the same SMTP transaction
Each option has downsides. The first option would require addition
addition -> additional
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.
How about: "and the third could make email less reliable by hiding
legitimate problems, and would in any case violate section 4.2.5 of
RFC 2821." (done with appropriate citation)
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.)
My only potential quibble here is that it might be clearer to describe
this from the point of view of the MTA receiving the message. For
example, the fact that the message is addressed to multiple recipients
isn't exactly the concern, because the messages might be in separate
transactions. (For example, I think qmail always uses a separate
transaction for each recipient.)
Something along the lines of: A server has already accepted one RCPT
TO: command in the current transaction. The server receives a
subsequent RCPT TO: command. The mailbox in the second RCPT command
has a different policy from the mailbox in the first command, and at
least one of the policies cannot be resolved until the server has
received the message contents with the DATA command.
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.
But this seems entirely compatible with the MAIL-FROM scenario I
proposed. If you have:
sender.bank.com IN MX 10 bounces.sender.com
sender.bank.com IN TXT "v=spf1 redirect=spf.sender.com"
And you send out mail:
Mail-From: notification-1234(_at_)sender(_dot_)bank(_dot_)com
From: eft-notifications(_at_)sender(_dot_)bank(_dot_)com
Nothing says that the mail has to come from bounces.sender.com.
sender.com can put whatever they want in spf.sender.com, and
bounces.sender.com should map to the IP address (or addresses) of
machines doing bounce processing.
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.
But I still don't get it. I understand that people might want to do
what you are describing. What I don't understand is why PRA-based
authentication is more amenable to the task than MAIL-FROM
authentication.
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.
Well, then maybe I'm asking the wrong person. But at this point I'm
thinking there must be something big I'm missing (or else it was
unfortunate to move from SPF to Sender ID). On the other hand, since
the big advantage of SPF over Sender ID is virus (and joe job)
prevention, and since Microsoft is both one of the big proponents of
PRA and one of the biggest targets of virus writers, I'm thinking
there's probably a pretty good reason for wanting Sender ID over
SPF-classic. I'd just like to understand that reason myself...
David