On 06/11/2012 15:04, Mason Schmitt wrote:
I recently setup a DMARC reject policy for some domains and then did
some testing. I was surprised to find that by simply omitting the
"From: " header, in a spoofed email sent to a gmail address, that the
email was accepted! The email was quarantined, not delivered to the
inbox, but I would have thought it would be rejected because I do have
a DMARC reject policy.
As others have pointed out, the issue is that DMARC is exclusively about
the email address contained in the From: header. The focus is
intentionally narrow, but the reason for this narrow focus is not so
obvious:
* A Mail Receiver can do a great many things by itself to deal with
spoofed messages with cousin domains or with malformed
(missing/multiple/deceptive) From: headers, none of which require
coordination with the relevant Domain Owner.
* The same is not true for spoofs which assert the correct domain name
of the organisation which is being impersonated. If a spoofer sends
a message "From: [email protected]", there is no way for a Mail
Receiver to work this out _*without the Domain Owner's help*_
(PayPal in this case). DMARC exists to specify an interoperable
means for Domain Owners and Mail Receivers to address _*this
specific*_ - and otherwise intractable - problem.
There are a great many other things that a Mail Receiver can and should
do (MUA UI design in particular) which don't require co-ordination with
Domain Owners (or any other form of interoperability) and which are
therefore out of scope for an interoperability spec, like DMARC.
This does give rise to a seemingly odd situation: that many Mail
Receivers - including some very big ones - have not implemented some of
the relevant best practices around preventing spoofing, which then means
that instead of DMARC filling one of the last major gaps it gains the
appearance of an incomplete solution. This is best understood by
recognising:
* Any organisation's adoption of best practices is likely to be
incomplete at any point in time - possibly for perfectly good
reasons[1], and
* DMARC is not like a security-vendor's product that attempts to close
as many related holes as possible, it is instead an interoperability
specification that minimally specifies a useful (and otherwise
unavailable) interoperability mechanism that should be integrated as
part of a security system. That is to say, DMARC is not intended to
be (and should not attempt to be) a complete solution.
Ok, so here's what I don't understand about DMARC. DMARC appears to
require both DKIM and SPF checks to return some kind of result or else
the DMARC policy is not followed. Why? It would seem to me that if
someone is setting up DMARC, they are aware that they need both a DKIM
policy and an SPF policy. Thus, shouldn't the spec state that if a
query for either policy returns no result, this is treated as a
failure for that test?
DMARC requires that either mechanism pass, not both. There would be no
good reason for requiring that both pass. Note also that neither
mechanism would be enough for DMARC to depend upon on its own (SPF never
survives forwarding, DKIM requires key management and - therefore - is
frequently not implemented).
- Roland
1: The big one is: if a hole isn't being actively exploited then closing
it isn't the highest possible priority. The internal engineering
trade-offs for dealing with lower priority practices are far out of
scope for an interoperability specification.
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
[email protected] | http://www.trustsphere.com/
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
