Re: [dmarc-ietf] Mandatory Sender Authentication
Dave Crocker <dhc@dcrocker.net> Sat, 08 June 2019 16:49 UTC
Return-Path: <dhc@dcrocker.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 23648120123 for <dmarc@ietfa.amsl.com>; Sat, 8 Jun 2019 09:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 TNJgr5YkRtDb for <dmarc@ietfa.amsl.com>; Sat, 8 Jun 2019 09:49:12 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F2412011B for <dmarc@ietf.org>; Sat, 8 Jun 2019 09:49:12 -0700 (PDT)
Received: from [10.97.137.43] ([149.137.255.211]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x58GpJT4006023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 8 Jun 2019 09:51:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1560012679; bh=Z2diibYa5SvmTLJI1m1ZWqnaRV2cl2mXRwb3X7R0kro=; h=From:Subject:To:References:Cc:Reply-To:Date:In-Reply-To:From; b=fMmYvIScJSTNuHuHXgmTkCKvPr53ZCJjg/AiXAxtmtCLM7RL0gpdXlW+iE5g4l7Bs Qb7qdZq3nP4a4Mz9gfOnbBfDwOZY9EuVm1I3t86La73LTLAwk/DsdZ7LfjoKNioubb SCsUKV1xhGqw6QBl2JG23hrbJdSk+0WrIQ5SGe5Y=
From: Dave Crocker <dhc@dcrocker.net>
To: fosterd@bayviewphysicians.com
References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com>
Cc: dmarc@ietf.org
Reply-To: dcrocker@bbiw.net
Message-ID: <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net>
Date: Sat, 08 Jun 2019 09:49:03 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <941abdbf28684283b972f69f25876220@bayviewphysicians.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/B1PZti495yQvg_NCcJ96ir_IJS0>
Subject: Re: [dmarc-ietf] Mandatory Sender Authentication
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: Sat, 08 Jun 2019 16:49:15 -0000
On 6/6/2019 7:09 PM, Douglas E. Foster wrote: >>> 1. By 'sender', which actor in the sequence do you mean? The term is > highly ambiguous. > By Sender Authentication, I mean message "From Address" authentication. > This involves two rules: > > * The sending IP address is known to be authorized to send for the > SMTP Sender-Address because of MX or SPF, and MX does not 'authorize' sending by an IP address, although some receivers do check for MX as a heuristic. But a heuristic is outside of any 'standard'. SPF does register IP to domain name for sending. > * the SMTP Sender-Address is known to be authorized to send for the Sorry, but the term "SMTP Sender-Address" does not have any specified or reliable meaning. > message from Address because of either > o domain alignment or > o a verifiable DKIM signature for the domain of the message > From-Address. > > The message From-Address is what the user sees, so it seems important to > know that the user is not being deceived by an impersonator. I assume you mean the RFC5322-level From: field, as opposed to the RFC5321-level Mail From command. Except that most users don't actually see that address because these days most MUAs only display the display address. As for end users being deceived, there's quite a bit of experience that showing users indicators doesn't alter their behavior. >>> 2. Your certitude presumes an empirical foundation, given how often good > theory does not make good practice. People have been working in this > space for a very long time and one might have expected the industry to > have latched on such a simple requirement were it that clear it was > /the/ essential requirement. Please document the basis for your certitude. > What I actually intend is that "a recipient has a viable option to > implement mandatory sender authentication." I don't understand what it means to have an option to implement something that is mandatory. It's mandatory. Also by saying 'recipient' rather than 'receiver' you appear to be indicating the end users will do meaningful filtering based on this kind of information. They won't. > This i equivalent to enforcing basic DMARC rules whether the sender has > a DMARC policy or not. This requires: That means you are seeking to alter fundamental email semantics by fiat, globally. Surely you jest. >>> 4. Consider the limitations to 'sender' authentication. > > I am spending a lot of time thinking about the limitations of sender > authentication. For a spammer domain, SPF / DKIM / DMARC are easy. What do you mean? > For impersonation, Friendly Name and embedded logo images can be > pretty effective without violating SPF / DKIM / DMARC. That's correct. And there has been extensive discussions looking to do something about that but there are no proposals on the table, because so far none has looked viable. > This means that Sender Authentication may produce more false positives No it doesn't. The existing authentication mechanisms do a good job of authenticating what they are authenticating. It appears that you are seeking to use the information far beyond what is valid. > To minimize false positives, I would like to see: > > * Pressure on list forwarders to either not break signatures, or > follow the IETF example of replacing the original from with the list > domain and signing the new message with the list domain. You want to bring pressure on list processing developers and/or operators. Good luck with that. > * Advice to senders to reduce signature complexity. In the general What does that mean? What specific proposal do you have? > mail stream, the purpose of the DKIM signature is to authenticate You appear to misunderstand the semantics of DKIM. Please re-read its specification and supporting document, because they have simple, concise language about what it does. > But I have already been told that IETF is not interested in Recipient > product problems, and is not concerned with security, which has left me > very disappointed. I suspect you have been told nothing of the sort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net
- [dmarc-ietf] Mandatory Sender Authentication Douglas E. Foster
- Re: [dmarc-ietf] Mandatory Sender Authentication Seth Blank
- Re: [dmarc-ietf] Mandatory Sender Authentication Douglas E. Foster
- Re: [dmarc-ietf] Mandatory Sender Authentication John R. Levine
- Re: [dmarc-ietf] Mandatory Sender Authentication Hector Santos
- Re: [dmarc-ietf] Mandatory Sender Authentication Dave Crocker
- Re: [dmarc-ietf] Mandatory Sender Authentication Douglas E. Foster
- Re: [dmarc-ietf] Mandatory Sender Authentication Dotzero
- Re: [dmarc-ietf] Mandatory Sender Authentication Dave Crocker
- [dmarc-ietf] Display address, was Mandatory Sende… Alessandro Vesely
- Re: [dmarc-ietf] Display address, was Mandatory S… Hector Santos
- Re: [dmarc-ietf] Display address, was Mandatory S… Dave Crocker
- Re: [dmarc-ietf] Display address, was Mandatory S… Alessandro Vesely
- Re: [dmarc-ietf] Display address, was Mandatory S… Alessandro Vesely
- Re: [dmarc-ietf] Display address, was Mandatory S… Дилян Палаузов
- Re: [dmarc-ietf] Display address, was Mandatory S… Hector Santos
- Re: [dmarc-ietf] Display address, was Mandatory S… Dave Crocker
- Re: [dmarc-ietf] Display address, was Mandatory S… Hector Santos
- Re: [dmarc-ietf] Display address, was Mandatory S… Stan Kalisch
- Re: [dmarc-ietf] Display address, was Mandatory S… Dotzero
- Re: [dmarc-ietf] Display address, was Mandatory S… Alessandro Vesely
- Re: [dmarc-ietf] Display address, was Mandatory S… Alessandro Vesely
- Re: [dmarc-ietf] Display address, was Mandatory S… Alessandro Vesely
- Re: [dmarc-ietf] Display address, was Mandatory S… Kurt Andersen (b)
- Re: [dmarc-ietf] Display address, was Mandatory S… Alessandro Vesely