Hi Kurt,
On 01/31/2014 06:03 AM, Kurt Roeckx wrote:
Hi,
I'm pretty new to DMARC, and I'm really confused about this
alignment thing. Can someone explain to me why this is needed?
Loosely speaking, DMARC's objective is to frustrate spoofing. The
relevant domain is therefore the one in the email address that end-users
see, which is almost always the 5322.From address rather than the
5321.MailFrom address.
On the face of it, this is therefore a job for DKIM rather than SPF,
however at the time that DMARC was developed DKIM coverage was minimal
(somewhere under 5% of legitimate email) while SPF already covered the
majority of legitimate email (somewhere above 60%, depending whose
numbers you look at). Consequently, it was sensible to look into ways to
make use of the existing SPF deployment to progress DMARC's objective.
The obvious problem was that SPF doesn't test the 5322.From domain,
however in direct delivery cases it is common for SPF to pass and for
the 5321.MailFrom domain and the 5322.From domain to "match" (either be
the same, or obviously belong to the same organisation), in which case
an SPF pass could reasonably be considered sufficient basis for treating
the message as authentic.
To understand why an alignment rule was required in the first place,
consider what could happen without one: a spoofer could send the
following and arrange appropriate DNS records for SPF to pass:
MAIL FROM: <[email protected]>
...
From: PayPal <[email protected]>
however this should not be considered authentic: the end-user would see
it as a message from PayPal when, clearly, it's not.
To understand why an alignment rule rather than an exact match, consider
this case:
MAIL FROM: <[email protected]>
...
From: Good Guy <[email protected]>
An SPF pass for marketing.goodguy.example is ordinarily sufficient
reason for considering this message authentic for goodguy.example. That
said, some Domain Owners don't want to operate this way, so DMARC
includes the means for them to use different policies for different
sub-domains.
SPF is not designed to do anything with the headers. SPF is known
to break forwarding if you don't change the mail from in the
envelope. So if you properly implement forwarding to work with
SPF you change the envelope sender.
I'd suggest being careful with the use words that impart a judgemental
slant: forwarders who aren't changing the return path in order to help
SPF work aren't doing anything "improper", they're simply doing what
they're doing. It is in the interests of Domain Owners and receivers who
want to tackle the spoofing problem to deal with the world as it as,
rather than pretend a simplified form that would make their lives
easier; forwarders who don't point return paths to themselves are part
of the real world.
(It is not usually sensible to respond to tone, I'm addressing it in
this case it appears to be affecting your understanding of the facts.)
At the time the SPF was developed, it was assumed that it was reasonable
to "require" each forwarder in a forwarding path to take responsibility
for what they forwarded by pointing return paths at themselves. This
fell down for two reasons:
* Depending upon every forwarder in the world to implement your
experiment in order for it to succeed turns out to be foolishly
impractical.
* Formalising a way to do this (SRS) that didn't itself create a new
abuse vector ended up failing to achieve what was intended because
of the impracticality of return paths containing the entire reverse
path (count the Received: headers in messages in your archive
sometime...) so it fell to just two hops (SRS0 and SRS1) anyway.
Consequently, the approach that you're describing as "proper" is
impractical, dangerous, or both. For this reason, almost no-one does it.
But now DMARC seems check that
the envelope sender matches the header's From, and then claim the
SPF check failed because they don't align, while the SPF check
could have any other result.
DMARC makes no claim about whether SPF passes or fails. SPF's passing or
failing is an _*input*_ to DMARC, not an output. For the reasons
explained above, an SPF pass for a domain not aligned to the 5322.From
domain is simply treated by DMARC as not being evidence of message
authenticity.
This doesn't make any sense to me.
Why is this check needed? Why do you want to break forwarding
even more?
Nothing about this breaks - nor even affects - forwarding.
(Note that this observation holds true even in a hypothetical
environment in which changing the return path is considered a normal
part of forwarding: a receiver who privileges a forwarded message simply
because SPF passes as a result of the return path changing is inviting
spoofers to pretend to forward their attacks, per the spoofer.example
example above.)
It seems to me that the only thing DMARC is useful for is the
reporting part, I can't imagine anybody wanting to run with
something other than p=none that cares that about the mails
actually reaching their destination.
As a Domain Owner, if you're not being heavily spoofed then you should
not use p=(quarantine|reject). These two policies carry a non-zero risk
of message loss - albeit a far smaller risk than you appear to assume -
so it needs to be the case that the benefit that you're gaining in
frustrating spoofing exceeds the cost in having a tiny fraction of your
messages go away. DMARC is not the FUSSP, it is a pragmatic tool that
solves a very large, very expensive problem for a small class of Domain
Owners and - eventually - a large class of receivers. Like many useful
tools it has side-effects, so there are trade-offs to consider in
deciding whether and how to use it.
For the rest of us, the reporting provided by p=none is a useful
monitoring tool for a range of other uses.
Please don't say that DKIM is a fallback.
It is SPF that is the fallback, not DKIM.
SPF is only used by DMARC at all because of the limited adoption of DKIM
and broad adoption of SPF at the time that DMARC was developed. The
complexity that using SPF introduces would otherwise not have been
warranted.
90% of the e-mails
with DKIM that I receive have a bad DKIM signature.
This suggests one (or more) of the following:
* You are including spoofed email in that number. If so, this is
hardly a critique of DKIM!
* You are including email forwarded by "non-participating" MLMs (RFC
6377) or other forwarders which alter messages in transit in ways
which break DKIM. The need to special-case these is well-understood;
look for a ReasonCode of mailing-list (or similar) in aggregate
reports. Fortunately these are small in number, not moving much and
are not an effective vector for spoofers.
* Per Frank's suggestion, the problem may be at your own MX. If so,
note that the relevant question for DMARC is whether DKIM passes at
the point where it reaches the MX. This is part of the reason for
Authentication-Results headers; subject to various trust and
security constraints, they can be used to perform decision making
downstream.
* Your DKIM deployment is broken. (Possible, particularly if you're
(a) evaluating downstream of your MX and (b) your MX is altering
messages in such a way as to invalidate many DKIM signatures.
Another possibility is a DNS resolver issue.)
* Your DKIM implementation is broken. This is improbable but worth
checking.
On 01/31/2014 08:17 AM, Kurt Roeckx wrote:
It's my understanding that in general about 90% of the DKIM mails
have a bad signature.
Give or take the points above, your understanding is simply not correct.
See
http://googleonlinesecurity.blogspot.sg/2013/12/internet-wide-efforts-to-fight-email.html
for recent real-world data.
In fact just over three quarters of legitimate email has a valid DKIM
signature on it.
It's also my understanding that were DKIM
tends to fail, SPF tends to work and the other way around. But
DMARC seems to combining the two in such a way it's more than
likely to have a failure as result instead of a pass.
As above, that's not correct:
* DMARC doesn't affect SPF and DKIM results.
* What it does do is apply SPF passes wherever they can reasonably be
applied in determining that a message is from whom it tells the
end-user it's from (i.e. 5322.From).
Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant.
Fair enough.
Note that the reason that people are addressing what you are seeing is
that you specifically raised what you're seeing ("90% of the e-mails
with DKIM that I receive have a bad DKIM signature") as though it were,
in fact, relevant.
On 01/31/2014 08:23 AM, Kurt Roeckx wrote:
I a question that might be related. If I send a mail from domain A to
B, and B forwards it to C after rewriting the enveloppe, and both A
and B have DMARC set up to receive reports, should C send a report to
both A and B?
No, DMARC reports are sent to the address specified by the Domain Owner
of the domain appearing in the 5322.From address. A forwarder who is
rewriting the envelope isn't affecting this.
I hope that this makes things a little clearer?
- Roland
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
