Re: [dmarc-ietf] dmarc and forwarding

[Roland Turner <[e-mail]>]

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

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

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

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.

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

OK.

> All I'm saying is that if
> you don't do it you might break someone else's SPF.

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.

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

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.

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

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.

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

Re-read the spec?

> But the result I get back say that SPF failed while there
> is no "-all" SPF record.  I think it is at least misleading.

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