Re: [dmarc-ietf] dmarc and forwarding

[Kurt Roeckx <[e-mail]>]

On Fri, Jan 31, 2014 at 10:38:55AM +0800, Roland Turner wrote:
> 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.

I do understand what the objective is.  But my current understanding
of it that it will break e-mail in various cases that I care
about, and I think we should try to do everything we can to
minimize mails wrongly getting rejected.

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

I'd like to point out that DKIM just certifies that a mail passed
on a certain domain.  For instance messages send to the IETF list
are signed by the IETF, but that doesn't mean that the IETF wrote
the original mail, just that it passed on their mail server.

They also changed the envelope from, setting it to
[e-mail].  They also set up SPF, and so both SPF and
DKIM could result in a pass.  So I could have every reason to
believe that this really is a mail from an IETF list.

But I'm not sure what DMARC is now saying or supposed to say about
this.  I think it only cares about what is in the header from, it
might see that SPF has a pass, but it's going to say that it
doesn't allign with the header from.  What is unclear to me is
what the result of that should be.  Is it just going to ignore
this SPF result?  Will it result in an SPF fail even though it was
really a pass?  How does this affect the result of DMARC?

You can also forget about DKIM passing.  The mail actually has 2 DKIM
signatures, one from you and one from the IETF.   As far as I
understand it, DMARC should ignore that one from the IETF
because it's not aligned, but could look at yours.  But your mail
was changed by the mailinglist software, and so will say that
that resulted in a failed checked.

(opendkim only seems to have generated 1 Authentication-Results
header, for the IETF,  while it probably should have generated 2,
and I might not even have check that your signaure is valid or
not.)

So in the end DMARC will say your mail is not authentic, and it
failed because DKIM failed to verify when only considering it to
be aligned with the header from.  And as I understand it, there is
no way for you to prevent that.

> 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: <[e-mail]>
>    ...
>    From: PayPal <[e-mail]>
> 
> 
> however this should not be considered authentic: the end-user would
> see it as a message from PayPal when, clearly, it's not.

That more seem to be a reason for DKIM to be aligned with the
header from than SPF to be aligned with it.

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

I'm not claiming that people forwarding mails should do this, and
it was never my intention to say so.  All I'm saying is that if
you don't do it you might break someone else's SPF.

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

So are you saying that you wouldn't add SPF anymore to it now?  Or
maybe differently?

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

Which makes no claim about how many signatures pass or fail.

> In fact just over three quarters of legitimate email has a valid
> DKIM signature on it.

That's not what it's saying.  It says that they have a signature, not
that it's valid or not.

It also makes not claim about reports they get back of how many
checks fail.

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

Maybe a better word would be ignore?  But then I'm not really
sure.  But the result I get back say that SPF failed while there
is no "-all" SPF record.  I think it is at least misleading.


Kurt