Re: [dmarc-ietf] dmarc and forwarding

Roland Turner <roland@rolandturner.com> Fri, 07 February 2014 06:36 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 39EDE1A05B0 for <dmarc@ietfa.amsl.com>; Thu, 6 Feb 2014 22:36:06 -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_16=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 H7wgtSxNCMwB for <dmarc@ietfa.amsl.com>; Thu, 6 Feb 2014 22:36:03 -0800 (PST)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 872941A0034 for <dmarc@ietf.org>; Thu, 6 Feb 2014 22:36: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=TU/dd8DHZWukb1ldr7THojK+gJUTaMWZ10prazr1b1w=; b=bKvKYATAAtFi96NCy+G2dMAluWdwJKkNQUSBrGizrVYb1RVWqZ+jWtMXxRudlulP6s/KJr2Gq71+2UWILu88WGVdsk/2n3eHArfEg9cwgLCLZK/fWQzxM6EvN+a+mPNmtIztAhcGq54AGSjUGEUn6zjhhZ9goWYoRKbWeOmduQE=;
Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133
Received: from [116.12.149.133] (port=59169 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <roland@rolandturner.com>) id 1WBf2c-0007Cz-M0 for dmarc@ietf.org; Fri, 07 Feb 2014 06:36:01 +0000
Message-ID: <52F47ECE.7010806@rolandturner.com>
Date: Fri, 07 Feb 2014 14:35:58 +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: dmarc@ietf.org
References: <20140130220330.GA25608@roeckx.be> <52EB0CBF.9020607@rolandturner.com> <20140201013342.GA24125@roeckx.be> <52EC725B.1050809@rolandturner.com> <20140205005928.GA15734@roeckx.be>
In-Reply-To: <20140205005928.GA15734@roeckx.be>
Content-Type: multipart/alternative; boundary="------------070306070108090508010607"
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, 07 Feb 2014 06:36:06 -0000

On 02/05/2014 08:59 AM, Kurt Roeckx wrote:

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

I do not understand this paragraph or its relevance to the quoted sentence.

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

It would be very helpful for you to share those so the relevant issues 
can be identified and addressed.

> And I think the draft isn't helping in
> making things clear because it just documents the format.

Would you care to propose specific improvements?

> 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 suspect that this conversation would proceed more quickly if you 
provided real examples rather than hypothetical ones but yes, sure.

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

Your guess is incorrect.

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

As my published policy is none, there is no requirement for a reason.

A reason is only required if the published policy is quarantine or 
reject and neither mechanism yields a pass that DMARC can use but the 
receiver has decided to override that (e.g. because the forwarder is 
believed by the receiver to be trustworthy, or because the Domain Owner 
is believed by the receiver to not have control of their legitimate 
message streams).

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

None, obviously: an aligned domain has passed SPF. 
(draft-kucherawy-dmarc-base-02 
<https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1> 
10.2 5)

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

No, that's the policy_published 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.
> I'm not sure I understand what you're saying here.  As I
> understand it, there is a strict and relaxed way for that?

Interesting, a misunderstanding on my part. Thank you.

- Roland