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
- [dmarc-ietf] dmarc and forwarding Kurt Roeckx
- Re: [dmarc-ietf] dmarc and forwarding Jim Fenton
- Re: [dmarc-ietf] dmarc and forwarding Andreas Schulze
- Re: [dmarc-ietf] dmarc and forwarding Matt Simerson
- Re: [dmarc-ietf] dmarc and forwarding Kurt Roeckx
- Re: [dmarc-ietf] dmarc and forwarding Franck Martin
- Re: [dmarc-ietf] dmarc and forwarding Kurt Roeckx
- Re: [dmarc-ietf] dmarc and forwarding Murray S. Kucherawy
- Re: [dmarc-ietf] dmarc and forwarding Kurt Roeckx
- Re: [dmarc-ietf] dmarc and forwarding Kurt Roeckx
- Re: [dmarc-ietf] dmarc and forwarding Roland Turner
- Re: [dmarc-ietf] dmarc and forwarding Murray S. Kucherawy
- Re: [dmarc-ietf] dmarc and forwarding Mike Jones
- Re: [dmarc-ietf] dmarc and forwarding Matt Simerson
- Re: [dmarc-ietf] dmarc and forwarding Steven M Jones
- Re: [dmarc-ietf] dmarc and forwarding Andreas Schulze
- Re: [dmarc-ietf] dmarc and forwarding Murray S. Kucherawy
- Re: [dmarc-ietf] dmarc and forwarding Kurt Roeckx
- Re: [dmarc-ietf] dmarc and forwarding Roland Turner
- Re: [dmarc-ietf] dmarc and forwarding Kurt Roeckx
- Re: [dmarc-ietf] dmarc and forwarding Murray S. Kucherawy
- Re: [dmarc-ietf] dmarc and forwarding Roland Turner
- Re: [dmarc-ietf] dmarc and forwarding Roland Turner