Re: [dmarc-ietf] p=reject

Hector Santos <hsantos@isdg.net> Tue, 19 March 2019 13:24 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7634B131270 for <dmarc@ietfa.amsl.com>; Tue, 19 Mar 2019 06:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Y7P4dOX1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=bdzZ26qA
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 lZ-65cmhlCit for <dmarc@ietfa.amsl.com>; Tue, 19 Mar 2019 06:24:14 -0700 (PDT)
Received: from mail.winserver.com (mail.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5277A130F05 for <dmarc@ietf.org>; Tue, 19 Mar 2019 06:24:14 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3299; t=1553001846; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=9vhMgPmPLmGHYcIbmENmAaoau4Y=; b=Y7P4dOX17pvutHHhPsnhl52ieUlF9pU5R74fc8gmRhTBSAe14UKRHemf89Bq5j YFtwPk+XcbM2vVL2WOH1AuSuyyUY+uit8jcCWVFxHOXenm6F4CP2AHcQBTqtJcEE pwUrAYIngx0Hs5MxtiKBhjTrgqtrsErqG3sHnQP4bsMV4=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Tue, 19 Mar 2019 08:24:06 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3408734996.1.1556; Tue, 19 Mar 2019 08:24:06 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3299; t=1553001818; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=08AuAZn tenQ6xyiiuhypdU9ufqPTvhMPcmXb3ZPnPUI=; b=bdzZ26qAxldok3VAtCnKVy6 Tm/hCHTqsZ31C10rlnISqzmc1tKhpAs5uPlhTWvSAELJxNq2GtRsYFwe1VvdzaLi 107ZCTt+A8WXeKnddNPdbwPVD6QWGBDbhKOXneedrcgjpKW50ynldY7KIhlMnLGh UfJ9z22XEb6JsvA73v28=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dmarc@ietf.org; Tue, 19 Mar 2019 09:23:38 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3956607846.9.303152; Tue, 19 Mar 2019 09:23:37 -0400
Message-ID: <5C90ED74.6070409@isdg.net>
Date: Tue, 19 Mar 2019 09:24:04 -0400
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Michael Davis <mikedup84@gmail.com>, dmarc@ietf.org
References: <CAOXFXsuLdsZgA-uJEDApRgW6bmzx5cORbiy=2KM9tNxHjqBxNA@mail.gmail.com>
In-Reply-To: <CAOXFXsuLdsZgA-uJEDApRgW6bmzx5cORbiy=2KM9tNxHjqBxNA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/nxEK_Sa3AjC-kpQTeYJ9HYRcE7o>
Subject: Re: [dmarc-ietf] p=reject
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 19 Mar 2019 13:24:18 -0000

On 3/18/2019 3:48 PM, Michael Davis wrote:
> If a sender's IP is in SPF, so SPF passes; and the applied DKIM signature
> is successfully decrypted, so DKIM passes; what good is checking alignment
> and rejecting a message? I have had Adobe and Cloudflare automated system
> emails rejected based on those senders' DMARC policy, after SPF and DKIM
> pass. These emails were regarding password resets and come from servers
> that do not equal the spoofed address domain. It would seem that if the
> sender is approved according to SPF and verified according to DKIM that
> alignment being a reason for rejection post authenticas is an exercise of
> absurdity.
>
> Please help me understand otherwise.

Hi Michel,

I'll take a stab at this.  My opinion.

I do agree with one vital (optimization) idea.

If a domain is 100% exclusive and restrictive and the domain's 
DNS-exposed policies indicate this exclusivity for all parties 
involved, then, in my opinion, DMARC is redundant. SPF should be good 
enough as long as all all identities are aligned.

That said, there a few points here.

First, this is all about having "trust."

Second, we don't have a 3rd party authorization/trust system for 
email, not like we do with HTTPS and the browsers relationship with 
3rd party CA vendors.

Third, without the first and second thing, it becomes questionable 
(almost to the level of absurdity) to use 3rd party services for high 
value transactions where one might suggest a "password reset" would be 
considered high value.

With DKIM, we have a self-signing 1st party signature system and a 
DKIM Policy framework for a 1st party authorization system.   It lacks 
a 3rd party authorization framework like we have with HTTPS.

It is important to keep this in mind because this dearth has been the 
"thorn on the dkim side" since the early days of DKIM-SSP (Sender 
Signature Policy) where it did offer policies for the 3rd party.

    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=?  WEAK (signature optional, no third party)
    o=.  NEVER  (no mail expected)
    o=^  USER

Over the years, because of the complexity and the failure to work out 
a 3rd party authorization protocol, ADSP and eventually DMARC reduced 
this to only supporting the more powerful, more narrow, more 
restrictive exclusive 1st party only signing protection policy.

But overall, what they all (SSP, ADSP, DMARC) lacked was a 3rd party 
signature authorization protocol. Ideas like TPA and ATPS were 
proposed as DKIM Policy extensions to fill in this big gap but 
unfortunately, not much traction.

Note: By 3rd party, this means the RPID, SDID and AUID domains don't 
align with ADID where:

    ADID   Author Domain Identity (5322.From.domain)
    RPID   Return Path Identity (5321.MailFrom.domain)
    SDID   Signer Domain Identity (5322.DKIM-Signature s= tag)
    AUID   Agent User Identity (5322.DKIM-Signature i= tag)

Honestly, I see your point, but vendors really do need to watch out 
using a 3rd party sending ADID, RPID, SDID and AUID scenarios for 
sensitive transactions.  We simply do not have an automated 3rd party 
authorization/trust and assessment system in place.


-- 
HLS