On Mon, 2004-08-30 at 20:35, mazieres(_at_)gmail(_dot_)com wrote:
I just have a couple of comments.
Great!
On Mon, 30 Aug 2004 18:51:53 -0400, Mark Shewmaker
<mark(_at_)primefactor(_dot_)com> wrote:
This vulnerability exists if local policy settings allow for a situation
in which all of the following are true:
- An incoming message was sent to multiple recipients,
- The message will ultimately be considered deliverable to some
subset of its intended recipients,
- The message will also be ultimately be considered undeliverable
to some other subset of the initial recipients, and
- 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.
Thus, I would recommend some wording along the lines of,
"The ultimate determination as to per-recipient deliverability cannot
be made before the SMTP DATA command."
I'm under the impression that those two wordings are currently
equivalent, in that giving a 250 response to the end of SMTP data means
that you've accepted the message for delivery.
The reason I went with more convoluted wording that probably comes to
the same thing at the moment was merely to be compatible with any future
SMTP extension that allows for something I've long wanted--a way to do
post-DATA per-recipient rejects.
So it's sort of a personal bias that was at the root of the convoluted
wording.
Begin Minor rant: (I hope I'm not stepping too far out of bounds
----------------- by posting this skim-able rant here.)
If there had been a requirement back in RFC821 for both the client and
server MTAs to support pre- and post-DATA per-recipient rejects, then
we'd not have this vulnerability at all, as MTAs could do separate and
incompatible body checks that differ per recipient, and yet still reject
for individual recipients depending on their individual settings of
acceptable body content.
Unfortunately, not only do we not currently have such an extension at
all, we especially don't have one that can be considered from a
practical point of view as fundamental requirement for SMTP servers.
So for the time being, in order to avoid this security vulnerability,
IMHO MTA's will need to implement this sort of bothersome, burdensome
workaround.
But were an extension supporting post-data per-recipient rejects to come
into being, I would imagine that the larger volume MTAs would put it in
deployment within a couple years, meaning that from a practical point of
view the workaround would become much less burdensome, only needing to
be used when communicating with MTAs that have not (yet) been upgraded,
or MTAs that are trying to perform an active attack, the latter
presumably learning to give up upon getting an EHLO response showing
support of such an extension.
End minor rant:
---------------
So while the implementation of such an extension is beyond the scope of
Sender ID, (though perhaps there are interested parties here that would
want to more appropriately push for such an extension), I was wanting to
use wording that was generic enough to still "fit" were such an
extension ever to come about and be put into use.
Although I don't see much talk of such an extension anywhere, I tend to
think it will come about at some point, and so I wanted to workaround's
wording to be compatible with the sort of thing I expect to later exist.
But a less convoluted way of wording it would be great, or, if folks
think I'm being overly picky by wanting compatibility with something
that doesn't yet exist, your wording is fine too.
A clever 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.
How about dropping the word "clever." From the point of view of a
standards document, the attacker's intellect is irrelevant. (Plus, I
would argue this attack isn't really all that clever, particularly
once it's already been described in a standards document.)
Absolutely agreed.
Thanks.
An MTA can completely avoid becoming a participant in a 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 a per-recipient final determination of delivery
cannot be made until after the message has been fully accepted.
- The MTA has not positively validated the MAIL FROM address,
What exactly does positively validated the MAIL FROM address mean,
unless you have something like SPF classic?
It means whatever the admin of the MTA wants it to mean. :-)
Or even more vaguely, it means whatever that admin wants to use as a
"good enough" algorithm for bouncability. :-)
I don't think it's a good idea to specify any particular algorithm.
While an SPF pass, an SES CBV verification, and a BATV CBV verification
would presumably all work well, as would a full set of Unified-SPF tests
that included MAIL FROM tests, and as would your excellent idea of a
close-enough test of SenderID testing the MAIL FROM, I'd still rather
not suggest any specific test--we don't now know what the "winning"
methods of bouncability verification will turn out to be, and there's no
need to tie anything down to something that may well become obsolete in
six months.
Testing the validity of a bounce address is a problem that's
theoretically uncoupled with the problem of testing the validity of the
PRA, so I don't want a document that's concerned with PRA tests to have
a security workaround to reference or require specific bounce address
tests.
It's a separate issue that the admin will have to handle, well,
separately. I just want to mention that for any SMTP transaction where
they think they've validated the bounce address, that this workaround
isn't necessary.
Also, I would argue that you don't need to positively validate the
MAIL FROM address. All you really need to know is that whoever would
get a DSN is somehow involved in the sending of the message.
Thus, one valid test would be to run a tentative check under the
assumption that the MAIL FROM address is actually the PRA. If the
test returns anything other than Pass or None, of course you don't
reject the mail, but instead, proceed as you outlined below, including
returning a 4.7.6 for multiple recipients.
That's an excellent idea.
Even though I'm personally biased towards Unified SPF, thinking the PRA
tests and MAIL FROM tests should be able to be scoped differently if the
domain wants, etc., and even though this wouldn't be using the records
quite as intended, from a practical point of view I'd be fine with doing
that test as a "good enough" test myself.
I'm just still not sure if the warning/workaround mentioned should refer
to any specific way of testing the MAIL FROM address.
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. (Or perhaps the outsourced company might want to
do that--having a bounce-handling machine that is set up to handle
bounces for a week after the mail is sent, which might be long after the
originating machine knows anything about the bulk mail sending session.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com