[Top] [All Lists]

"refuse" - wording from a MARID post.

2004-10-04 12:41:49

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,


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



<Prev in Thread] Current Thread [Next in Thread>
  • "refuse" - wording from a MARID post., Matthew Elvey <=