Re: [dmarc-ietf] dmarc and forwarding
Kurt Roeckx <kurt@roeckx.be> Wed, 05 February 2014 00:59 UTC
Return-Path: <kurt@roeckx.be>
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 3BD6B1A01B2 for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2014 16:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001] autolearn=no
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 WIkQwZxVBw50 for <dmarc@ietfa.amsl.com>; Tue, 4 Feb 2014 16:59:30 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id E825E1A01BD for <dmarc@ietf.org>; Tue, 4 Feb 2014 16:59:29 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id B53621C2241; Wed, 5 Feb 2014 01:59:28 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 94F981FE025C; Wed, 5 Feb 2014 01:59:28 +0100 (CET)
Date: Wed, 05 Feb 2014 01:59:28 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Roland Turner <roland@rolandturner.com>
Message-ID: <20140205005928.GA15734@roeckx.be>
References: <20140130220330.GA25608@roeckx.be> <52EB0CBF.9020607@rolandturner.com> <20140201013342.GA24125@roeckx.be> <52EC725B.1050809@rolandturner.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <52EC725B.1050809@rolandturner.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: dmarc@ietf.org
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: Wed, 05 Feb 2014 00:59:32 -0000
On Sat, Feb 01, 2014 at 12:04:43PM +0800, Roland Turner wrote: > "Non-participating" MLMs (RFC 6377) are outside DMARC's scope. This draft does not update the RFC 6377 requirements for mailinglists, but I do think it changes the requirements. But it also seems to contain the posibility to override this somehow, but it's all outside the scope of DMARC. > >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). >From what I understand, I have received very few aggregate report that gets all the results correct. There always seems to be something wrong with it. And I think the draft isn't helping in making things clear because it just documents the format. As I understand it, in the case of the mails you send to this list, you should receive the following: <auth_results> <dkim> <domain>ietf.org</domain> <selector>ietf1</selector> <result>pass</result> </dkim> <dkim> <domain>rolandturner.com</domain> <selector>20120325</selector> <result>fail</result> </dkim> <spf> <domain>ietf.org</domain> <scope>mfrom</scope> <result>pass</result> </spf> </auth_results> I'm just going to guess that the results you get back contain all kinds of wrong information, but I hope you at least get some that are more or less correct. I think that because none of those that pass are alligned it should then result in: <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>fail</spf> </policy_evaluated> Possibly it could have an reason there added. What is unclear to me is what happens when either dkim of spf would pass and the policy_published contains p=reject. Should it be: <policy_evaluated> <disposition>reject</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> Or: <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> Please note that the draft seems to indicate that it should contain the value from p or sp, but that if you override it it can contain some other value. So I can read that even if you accept it because dkim says pass that the disposition should be reject. And I have to guess that's not really the intension. > 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. I'm not sure I understand what you're saying here. As I understand it, there is a strict and relaxed way for that? > >So in the end DMARC will say your mail is not authentic, > > Not exactly: DMARC doesn't make determinations about authenticity, DMARC seems to talk a lot about authentication, including in it's name, so I fail to understand that. Kurt
- [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