Hello. What follows is from a post to the IETF's MARID mailing list.
It seems relevant to the "refuse" I-D.
The "Disallow some message recipients" method is well described and
justified, IMO.
Previous Subject: "Re: TECH-OMISSION: Legal liability for creating
bounces from forged messages."
On 8/31/2004 2:39 AM, Mark Shewmaker <mark primefactor com> sent forth
electrons to convey:
...
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.)
Ok that's what I wanted to post.
(The post continues below, with 2 points that I think may depend on
unwarranted trust assumptions, followed by some good points.
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.
=====================================================================
)