Re: [dmarc-ietf] dmarc and forwarding

Roland Turner <roland@rolandturner.com> Fri, 31 January 2014 02:39 UTC

Return-Path: <roland@rolandturner.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59C31A04F3 for <dmarc@ietfa.amsl.com>; Thu, 30 Jan 2014 18:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Level:
X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PUm_IM6B3r1 for <dmarc@ietfa.amsl.com>; Thu, 30 Jan 2014 18:39:04 -0800 (PST)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id F1D261A04F1 for <dmarc@ietf.org>; Thu, 30 Jan 2014 18:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=peyOIFJiFYvlKGQ8MAb3t8cf24DSM29Tr1EHNsrdAGI=; b=XggcSF6gvXTexfd4l4Kmq/6JVQzJFFjMPvWgFNQvg8CNayGNhEbXCWPiZUZUYJQVlkS21uY8VAc4FWkRGSx6vIe6gk0PZcvM7ePoXuQvg3LoWJLBW9WS1fmkB6DgUlJgWjO7Ib4fbYKo2n0DhBMyUr+ktD0eibayKr/TdC6o0h4=;
Authentication-Results: sg.rolandturner.com; none; iprev=permerror (no ptr) policy.iprev=222.165.46.240; iprev=pass policy.iprev=222.165.46.240 (cm240.theta46.maxonline.com.sg)
Received: from [222.165.46.240] (port=39040 helo=[10.1.132.102]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <roland@rolandturner.com>) id 1W940O-00021G-83; Fri, 31 Jan 2014 02:38:58 +0000
Message-ID: <52EB0CBF.9020607@rolandturner.com>
Date: Fri, 31 Jan 2014 10:38:55 +0800
From: Roland Turner <roland@rolandturner.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Kurt Roeckx <kurt@roeckx.be>, dmarc@ietf.org
References: <20140130220330.GA25608@roeckx.be>
In-Reply-To: <20140130220330.GA25608@roeckx.be>
Content-Type: multipart/alternative; boundary="------------030908000101020004000406"
Subject: Re: [dmarc-ietf] dmarc and forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 02:39:08 -0000

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: <noreply@spoofer.example>
    ...
    From: PayPal <someone@paypal.com>


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: <noreply@marketing.goodguy.example>
    ...
    From: Good Guy <someone@goodguy.example>


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