Subject: "refuse" - wording from a MARID post.

From: Matthew Elvey <[email-masked]>
Date: Mon, 04 Oct 2004 12:43:43 -0700

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.
>
>=====================================================================
>
)