Subject: [dmarc-ietf] dmarc and forwarding

From: Kurt Roeckx <[email-masked]>
Date: Thu, 30 Jan 2014 23:03:30 +0100

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?

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.  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.  This doesn't make any sense to me.
Why is this check needed?  Why do you want to break forwarding
even more?

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.

Please don't say that DKIM is a fallback.  90% of the e-mails
with DKIM that I receive have a bad DKIM signature.

Kurt

---

From: Jim Fenton <[email-masked]>
Date: Thu, 30 Jan 2014 14:10:07 -0800

> with DKIM that I receive have a bad DKIM signature.
Wow, that seems really high.  These are legitimate messages?

If spoofed messages are failing verification, that's a feature.

-Jim

---

From: Andreas Schulze <[email-masked]>
Date: Thu, 30 Jan 2014 23:21:26 +0100

> Wow, that seems really high.  These are legitimate messages?

I guess, he's simply receiving many mailing-lists :-/

Andreas

---

From: Matt Simerson <[email-masked]>
Date: Thu, 30 Jan 2014 14:22:31 -0800

> with DKIM that I receive have a bad DKIM signature.

Interesting. My experience is just the opposite.

I should also note that 90% of emails get rejected long before I try to validate the DKIM signature. 

Matt

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 30 Jan 2014 23:23:20 +0100

> Wow, that seems really high.  These are legitimate messages?

Yes, those are real messages.

Kurt

---

From: Franck Martin <[email-masked]>
Date: Thu, 30 Jan 2014 16:39:48 -0600 (CST)

----- Original Message -----
> From: "Kurt Roeckx" <[email-masked]>
> To: "Jim Fenton" <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, January 30, 2014 2:23:20 PM
> Subject: Re: [dmarc-ietf] dmarc and forwarding
> 

It seems to me that all the emails sent to you go via first an email gateway before landing on your mail server

Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140])
 by ietfa.amsl.com (Postfix) with ESMTP id 3E2D21A04CC for <[email-masked]>;
 Thu, 30 Jan 2014 14:23:24 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by
 defiant.e-webshops.eu (Postfix) with ESMTP id 5E2791C215E; Thu, 30 Jan 2014
 23:23:20 +0100 (CET)

And the MX for your domain seems to confirm that

It is not uncommon to find gateways that rewrite the message therefore breaking DKIM.

Please request defiant.e-webshops.eu to not modify the email while in transit (likely just changing the encoding)

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 30 Jan 2014 23:51:52 +0100

> It seems to me that all the emails sent to you go via first an email gateway before landing on your mail server

It seems to me that this part of the discussion is not useful at
all, and doesn't answer any of the questions I had.  It's also not
important where or why it breaks, since I suspect this nothing
that is new.  But I'm also pretty sure it's none of my hosts that
break it.  If you really feel like discussing this I suggest we
take that to somewhere else.

PS: I strongly suggest you all stop using anything lower than 2048
bit to do DKIM.

Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Jan 2014 15:53:51 -0800

> take that to somewhere else.
I don't agree, since DMARC is predicated in part on the notion that DKIM
has become sufficiently reliable in general as to be a viable building
block upon which to build things like DMARC.  Your question is based on the
idea that your experience is the opposite.  Naturally, we're curious.

I believe the questions you're getting are actually attempts to help.  Are
you sure swatting their hands is the right response?

-MSK

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 31 Jan 2014 01:17:32 +0100

> you sure swatting their hands is the right response?

It's my understanding that in general about 90% of the DKIM mails
have a bad signature.  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.

Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 31 Jan 2014 01:23:20 +0100

> alignment thing.  Can someone explain to me why this is needed?

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?

Kurt

---

From: Roland Turner <[email-masked]>
Date: Fri, 31 Jan 2014 10:38:55 +0800

Hi Kurt,

> 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-masked]>
    ...
    From: PayPal <[email-masked]>

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-masked]>
    ...
    From: Good Guy <[email-masked]>

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

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

> 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

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Jan 2014 19:17:46 -0800

> It's my understanding that in general about 90% of the DKIM mails

This seems to contradict the experience of most other operators.  I'm at a
loss to understand why this is out of bounds for this conversation.

> tends to fail, SPF tends to work and the other way around.
>
>
This part is consistent with most operator experience as I understand it.

>   But

In what way?  Specifically, why "more than likely"?  That's certainly true
in your particular case where DKIM has such a low success rate, but there
is ample anecdotal evidence that it is a sound premise most everywhere else.

> Why I'm seeing 90% failure in DKIM instead of 10% is irrelevant.
I find that rather an unfortunate position, especially since it interferes
with our ability to answer your questions.

-MSK

---

From: Mike Jones <[email-masked]>
Date: Thu, 30 Jan 2014 22:38:18 -0800

Kurt and all,

Here are some statistics my company has on DKIM over the last 30 days.
(Note: We are a DMARC report aggregator and analytics company so these
stats cover all of the DMARC reports received for thousands of domains.)

% of all messages signed by DKIM = 97.79%
% of signed messages which pass DKIM = 99.57%
sample size = over 100 billion messages

Of course we are aggregating reports for organizations implementing DMARC,
so the percentage of messages signed may be skewed.  But it is clear that
of the messages which are signed, the percentage which pass is drastically
different than the numbers you see.  I think the data supports some issue
on your side with the DKIM evaluation, whether it be an email gateway
modifying signed message content before your server or something else.

We also see that domains with a good implementations of SPF and DKIM
consistently see DMARC pass rates in excess of 99.99% of their legitimate
messages.

Roland gave an excellent explanation of the reason for the alignment
requirement the DMARC specifies.  One point in his reply I will disagree on
though is that domains without a current spoofing problem should not
implement a DMARC quarantine or reject policy.  This thing about spoofing
is that one never knows when one will become a victim.  We often see
domains that go periods of time without a spoofing issue and then are hit
hard on one day.  If the your domain has excellent SPF and DKIM with a high
overall DMARC pass rate, you have fully analyzed your DMARC reports to
understand the risk of failures due to mailing lists or forwarding, and
everything looks good then why not protect yourself from future attacks
with a DMARC quarantine or reject?

Thanks,
Mike

On Thu, Jan 30, 2014 at 7:17 PM, Murray S. Kucherawy <[email-masked]>wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Matt Simerson <[email-masked]>
Date: Thu, 30 Jan 2014 22:52:07 -0800

On Jan 30, 2014, at 10:38 PM, Mike Jones <[email-masked]> wrote:

> One point in his reply I will disagree on though is that domains without a current spoofing problem should not implement a DMARC quarantine or reject policy.  This thing about spoofing is that one never knows when one will become a victim.  We often see domains that go periods of time without a spoofing issue and then are hit hard on one day.  If the your domain has excellent SPF and DKIM with a high overall DMARC pass rate, you have fully analyzed your DMARC reports to understand the risk of failures due to mailing lists or forwarding, and everything looks good then why not protect yourself from future attacks with a DMARC quarantine or reject?  

+1

Matt

---

From: Steven M Jones <[email-masked]>
Date: Fri, 31 Jan 2014 00:00:59 -0800

On 01/30/2014 10:38 PM, Mike Jones wrote:
>
> [The] thing about spoofing is that one never knows when one will 
> become a victim.  We often see domains that go periods of time without 
> a spoofing issue and then are hit hard on one day.

I'd like to reinforce this point from experience as a domain owner. At a 
major financial institution, we put SPF "-all" and DMARC "p=reject" 
records on some domains that had been retired a several years earlier. 
These domains seldom saw more than 1,000 messages per month - again, 
none from or authorized by the owning organization - but they were 
prominent names you would recognize, and this seemed like a prudent 
precaution.

Sure enough, one holiday weekend somebody tried to send over 1.75 
million messages using one of these domains. While we surely weren't 
receiving reports from every domain receiving the spoofed messages, from 
the receivers that did report - including Microsoft, AOL, Google, and 
Yahoo - over 99.5% of those messages never reached an inbox. And I can 
tell you, we did not see blocking rates that high from similar domains 
where we had not put DMARC policies in place, no matter how lame the 
fraudulent messages were.

--Steve.

---

From: Andreas Schulze <[email-masked]>
Date: Fri, 31 Jan 2014 19:38:20 +0100

> sample size = over 100 billion messages

Mike,

my "real life" looks a little more unsigned.
On 300k messages per day I have only 30% signed.
But from these 100k ~90% pass DKIM.

Andreas

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Jan 2014 11:50:05 -0800

OpenDKIM stats, last six months:

http://www.opendkim.org/stats/report.html

Pass rate is pretty high across all of our reporting sites as well.

-MSK

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 1 Feb 2014 02:33:42 +0100

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

> 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
[email-masked].  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.

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

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

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

> 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

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.

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

---

From: Roland Turner <[email-masked]>
Date: Sat, 01 Feb 2014 12:04:43 +0800

On 02/01/2014 09:33 AM, Kurt Roeckx wrote:

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

It might help if you were to provide concrete examples of the cases 
which are concerning you. (If you mean the dmarc-ietf list case then 
your concern is unwarranted: DMARC doesn't address lists of this type.)

Your concern is widely shared, so much so that mechanism for providing 
Domain Owners with visibility of [potential] message loss is arguably 
DMARC's primary contribution, the absence of a practical comparable 
mechanism in SPF or any comparable mechanism in DomainKeys and ADSP 
being why -all, o=- and dkim=discardable are rarely asserted and widely 
ignored.

> 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 [email-masked]. 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.

"Non-participating" MLMs (RFC 6377) are outside DMARC's scope.

> I think it only cares about what is in the header from,

A few of your comments - and this one in particular - suggest that 
you've forgotten some of the details of the specification 
<https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1> 
which spells this stuff out very clearly; may I suggest re-reading it?

(Yes, DMARC deals exclusively with the domain in the 5322.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?

DMARC is going to ignore it, yes.

> Will it result in an SPF fail even though it was really a pass?

No, DMARC does not alter SPF. If SPF passes, it does so with or without 
DMARC being present. What DMARC does do is decide when to make use of an 
SPF pass; in particular it only does so when the SPF domain and 
5322.From domain are aligned. Note that a DMARC implementation therefore 
has to deal with two separate interpretations of an SPF result:

  * The domain name and result from the authentication mechanism itself;
    this is the auth_results section of an aggregate report.
  * The relevance of the underlying results to a DMARC policy
    evaluation; this is the policy_evaluated section of an aggregate
    report. Any time the SPF domain is unaligned a fail will appear
    here, even if SPF passed (and therefore shows a pass in the
    auth_results section).

Note further that DMARC is also selective about its use of DKIM, except 
that the DKIM d= must match from 5322.From domain exactly (merely being 
aligned isn't enough). The same two interpretations must therefore be 
understood and they appear in the same two places in the aggregate 
report as above.

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

Right. As above, this is all outside DMARC's scope.

> So in the end DMARC will say your mail is not authentic,

Not exactly: DMARC doesn't make determinations about authenticity, it 
merely proposes dispositions. The Domain Owner may request a specific 
disposition for messages which don't pass either of DMARC's 
authentication approaches, it is up to receivers to make a call about 
what they want to do when they reach this point. In general they'll 
honour it unless one of the following applies:

  * The message was forwarded by a mailing list or other forwarder that
    is known by the receiver to not be a useful vector for spoofers. In
    this case the policy_evaluated section will contain a disposition of
    none and a reason section, typically of type trusted_forwarder or
    mailing_list.
  * The Domain Owner is one that the receiver believes to be incompetent
    (or doesn't believe to be competent).
  * Some other local override to deal with some local issue (e.g. DMARC
    evaluation happening a second time in a situation known to break DKIM.)

How these decisions work are specifically outside DMARC's scope, they 
are local operational choices.

> header from than SPF to be aligned with it.

I'm not sure how that's relevant. All that I'm saying that in this 
situation, DMARC should not (and indeed does not) treat an SPF pass as a 
pass for DMARC's purposes.

> it was never my intention to say so.

OK.

> All I'm saying is that if

Sure. This has been well understood since SPF was devised and was the 
reason for SRS which - as I pointed out earlier - turned into an 
exercise in demonstrating that SPF and forwarding are probably 
infeasible to combine.

Per my earlier comments, SPF is only relevant to DMARC in the 
direct-delivery case.

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

It's an interesting question. Technology development tends to be 
path-dependent, so we don't generally get to answer this sort of 
question meaningfully. I'd suggest that even if we'd gotten to the 
current levels of SPF and DKIM penetration with DMARC's feedback 
(improbable) there is still enough additional value in SPF at present to 
warrant its inclusion if DMARC were designed today. If DKIM penetration 
continues its present growth this value may diminish to the point of 
being irrelevant. Whether this leads to pressure to remove SPF from 
DMARC's inputs is an open question.

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

Your dedication to the idea that there's some problem with DKIM signing 
and verification is admirable, but misplaced. It might help to note that 
DMARC is not a hypothetical system that's being offered for discussion, 
it's already had several years of use doing what it was designed to 
achieve (disrupting spoofing without disrupting legitimate email), and 
doing so reliably.

In the particular case of Google's numbers, the bit you missed was 
"91.4% of non-spam emails sent to Gmail users come from authenticated 
senders". This is not just a DKIM signature or SPF record being present, 
this is one or both actually passing for more than 90% of the legitimate 
email received by Gmail. The numbers that you are seeing in your 
environment are nowhere near typical. I proposed earlier a list of 
likely causes, all of them in your control.

> sure.

Re-read the spec?

> But the result I get back say that SPF failed while there

That's not misleading, it's broken. If you'd share the example, the 
relevant people are likely to want to fix it (assuming of course that 
you're not confusing auth_results with policy_evaluted).

- Roland