Re: [dmarc-ietf] Email security beyond DMARC?

Grant Taylor <> Sat, 16 March 2019 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E13EE1200D7 for <>; Sat, 16 Mar 2019 09:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mQP0u4LqqtoR for <>; Sat, 16 Mar 2019 09:59:18 -0700 (PDT)
Received: from ( [IPv6:2600:3c00:e000:1e9::8849]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8E00126DFA for <>; Sat, 16 Mar 2019 09:59:17 -0700 (PDT)
Received: from Contact-TNet-Consulting-Abuse-for-assistance by (8.15.2/8.15.2/Debian-3) with ESMTPSA id x2GGxFYI004194 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <>; Sat, 16 Mar 2019 11:59:17 -0500
ARC-Filter: OpenARC Filter v0.1.0 x2GGxFYI004194
Authentication-Results:; arc=none
ARC-Seal: i=1; a=rsa-sha256;; s=2015; t=1552755557; cv=none; b=14M9kw6mxPqcUquIXRdPdn2TWWSk75AxMQYVUAM7gcA2SZOKDcd7hOG5oNQk0lTUQVocRBkcEUHA8cjbna+2duLmYnIvHAv1mzXcbMLsRSX67D4FUoX06im9bzD1gNwLGtbLWFx7rB3iHULBprOz60AqSvTA5iqTYocha2YgdnQ=
ARC-Message-Signature: i=1; a=rsa-sha256;; s=2015; t=1552755557; c=relaxed/simple; bh=u8OF9cgaxJWFOWCsw3NV61XV6oMwUCyYQT8zxKKqBM4=; h=DKIM-Signature:Subject:To:From:Message-ID:Date:User-Agent: MIME-Version:Content-Type; b=uVD2erzN/1uV8q9ACHYEAV/S7WhqYt2m0DojfkL2VCDsjvHK8IKXKn6Y2KR8ZOmbi2YHy1cJfibtVKv/hhIdZ47quZY8VgotHMQIBXvAk1xUSZgP91LWWAL8rTVE/6U3fK7Cr6T1LOctFIAdfJD5rsXckgE0DFYTP4VNL2C4TWA=
ARC-Authentication-Results: i=1;; none
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=2019; t=1552755557; bh=u8OF9cgaxJWFOWCsw3NV61XV6oMwUCyYQT8zxKKqBM4=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Cc:Content-Disposition: Content-Language:Content-Transfer-Encoding:Content-Type:Date:From: In-Reply-To:Message-ID:MIME-Version:References:Reply-To: Resent-Date:Resent-From:Resent-To:Resent-Cc:Sender:Subject:To: User-Agent; b=WgZd4InxhCKnc3/SEkK36ExtuxPP8muuBf1JP+MlM3lIRNNAw3/VZu7PWbWLKkF96 OryCvUIzwQma4nkwsoiz2IPG8ZlUvpe5ZmOwD1LPiHvH2Xl4iDZIXdpnjTiyoVkEp8 PjCSRpqCdk5MtyQ+avWFqfxYYEK5kHi7E2p1FT7o=
References: <>
From: Grant Taylor <>
Organization: TNet Consulting
Message-ID: <>
Date: Sat, 16 Mar 2019 10:59:26 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050703040800090306070805"
Archived-At: <>
Subject: Re: [dmarc-ietf] Email security beyond DMARC?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Mar 2019 16:59:20 -0000

On 3/16/19 6:56 AM, Douglas E. Foster wrote:
> I tried to understand what IETF is doing about email security, and this 
> working group seems to be the only surviving effort.   Based on the 
> index, the groups attention is focused on polishing the existing DMARC 
> implementaton rather than plowing new territory.   Given the devastating 
> effect of WannaCry and the success of other email-based attacks, I think 
> our work is far from finished.

I can understand why you think there is more work to be done about email 
security.  However I don't know that this, DMARC, group is the best 
location to push for it.

I don't know what is left to do with DMARC, other than refining—or 
polishing as you said—needs to be done.  I'm not saying that there isn't 
anything left to do, just that I'm ignorant of what that might be. 
Please share suggestions if you have any.

I also think it's somewhat unfair to imply that DMARC, and other email 
protection technologies, don't protect email to the desired level, 
*especially* when people don't /properly/ utilize said technology.  I am 
willing to accept that said technologies may be too difficult for mass 

I do believe that SPF, DKIM, and DMARC are capable of protecting email 
when they are used /properly/.

There a numerous other technologies that have been developed in the last 
100 years that help protect against one form of problem or another.  Yet 
these technologies, some simple to use, don't get utilized like they 
should.  Some examples that come to mind are the seat belt in cars, 
HTTPS encryption on web servers, IPsec, even S/MIME encryption for email 
comes to mind.  Sure, some of these technologies need some help 
initially configuring.  But almost all of them are simple to use /after/ 
they have been configured.  Yet, all of them are under utilized.

I think that this pattern says something about humans choosing to not 
use technology, even when a viable solution for the problem at hand exists.

> DMARC / DKIM / SPF rely entirely on sender participation.   Too few 
> legitimate senders are implementing these measures in the manner that 
> was envisioned, and too few , and too many spam filters fail to use 
> these tools fully.

IMHO, the execution of a technology is independent of the viability of 
said technology.  Unless it is an indication of a symptomatic problem 
with said technology.

> DMARC represents a powerful concept which can be applied by the 
> receiver, with adjustments, in ways that liberates the receiver from 
> dependency on legitimate senders becoming fearless.

I am curious to learn what you are talking about.

> I can articulate how that could be done, but I do not know how to start 
> that discussion appropriately.

I don't know what the proper process is.  But given how you are 
referencing DMARC, I'm guessing that you're not completely out of the 
ball park by bringing it up on this mailing list.

Grant. . . .
unix || die