Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles

Dave Crocker <dhc@dcrocker.net> Wed, 26 May 2021 01:14 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B263A16F4 for <ietf-smtp@ietfa.amsl.com>; Tue, 25 May 2021 18:14:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 Fr5RQrWnzx_k for <ietf-smtp@ietfa.amsl.com>; Tue, 25 May 2021 18:14:43 -0700 (PDT)
Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.93]) (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 BC8863A16F0 for <ietf-smtp@ietf.org>; Tue, 25 May 2021 18:14:42 -0700 (PDT)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6A8EE3623D3; Wed, 26 May 2021 01:14:41 +0000 (UTC)
Received: from nl-srv-smtpout4.hostinger.io (100-96-18-80.trex.outbound.svc.cluster.local [100.96.18.80]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id E6FE8362038; Wed, 26 May 2021 01:14:39 +0000 (UTC)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from nl-srv-smtpout4.hostinger.io ([UNAVAILABLE]. [145.14.159.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.18.80 (trex/6.2.1); Wed, 26 May 2021 01:14:41 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net
X-MailChannels-Auth-Id: hostingeremail
X-Snatch-Whistle: 7f35fe0c1811ce68_1621991681128_3535375589
X-MC-Loop-Signature: 1621991681127:2844328018
X-MC-Ingress-Time: 1621991681127
Received: from [192.168.0.111] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout4.hostinger.io (smtp.hostinger.com) with ESMTPSA id BF302319D00D; Wed, 26 May 2021 01:14:36 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1621991678; bh=ZSyidT9qnuYGAXxZMWFrbjoc9+BkcnUGdKA8sdcGGhM=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=eG5is0mrl7fvY6As9aO84bWezv4pIAvNUTk860HN75vzn8Q4dVY/SNN/ABe7PYoD0 +inDUUB1mEim8wAvKY5NjJ0MRh0ne7jxHPpVraE40c2xTBXYBZtbVdAA3vgytJ83z7 Eae9QHXmUonJL3MMApobhtlMVXXGyfY1RTK8AwOKFIxubWN5B2kqzUXwaml0SEGEPX R6QTE3tZ9eiMIW9t0YIiMgoIyTdvJF/AJc2C/OrtYPXcfWXG46Lwg8cSQgpyb3r2Jk 3VQuLqsg57iSKfpt4VxCC8oGvIDOp9a7dvreGx6sK34puKk6LTCm3eEbuR2uREzkCE HNUX2ZK9QcVqw==
Reply-To: dcrocker@bbiw.net
To: Sam Varshavchik <mrsam@courier-mta.com>, ietf-smtp@ietf.org
References: <20210525012345.E42AE8A790D@ary.qy> <cone.1621939932.396187.66265.1004@monster.email-scan.com> <14fa34c7-c6a2-2c2c-3de9-f4f8c7327f9e@dcrocker.net> <cone.1621990228.782113.83228.1004@monster.email-scan.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <5b98b0a0-3545-5370-c8d2-51533b0445f5@dcrocker.net>
Date: Tue, 25 May 2021 18:14:34 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <cone.1621990228.782113.83228.1004@monster.email-scan.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/ietf-smtp/rh3BPea6rNY_7nOBtfuwqXgj7X4>
Subject: Re: [ietf-smtp] DKIM and DMARC, Email explained from first principles
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2021 01:14:48 -0000

On 5/25/2021 5:50 PM, Sam Varshavchik wrote:
> Dave Crocker writes:
> 
>>>> Large mail systems all do this. We hoped that
>>>> there would be shared DKIM reputation lists like there are shared IP
>>>> lists but so far that hasn't happened.
>>>
>>> This is never going to happen. Domains are relatively cheap. If a 
>>> domain acquires negative social credit it'll be discarded and 
>>> replaced by a new one.
>>
>> One of the continuing, strategic challenges in anti-abuse work is that 
>> people who work in it necessarily have a primary focus on bad actors.  
>> A collaborative mechanism -- such as DKIM, where the originating site 
>> literally signs up for identification and assessment -- creates a 
>> challenge, in that evaluating good actors is quite a different job 
>> from evaluating bad actors.  It's not that good actors are perfect, 
>> but that they are less likely to act badly and typically it won't be 
>> intentionally.
> 
> So what you're saying is that usage of DKIM is more indicative of a good 
> actor than a bad actor.

Actually, no, that's not what I said.  Bad actors are always the first 
to adopt the newest anti-spam technologies, to abuse those unfortunates 
who interpret DKIM the way you described.

DKIM establishes a clean (noise-free) channel from the signer, which 
means that any assessment about them really is about them.  If they are 
bad actors, that is a lot easier to assess, as is if they are good actors.


> 
>> Think misdemeanor rather than felony...
>>
>> So the fact that domains are cheap is less relevant than a good actor 
>> wanting to create a clean record of being a good actor.
> 
> I just did a rough search of my mailbox, looking at the proportion of 
> non-spam mail with DKIM-Signature: field versus the spam bin.

cf, above, about bad actors.


> But nearly all other spam, the kind that I do have a major problem with, 
> the specific type that I'm bitching about, nearly all of it carries a 
> DKIM-Siganture: field. I only found very, very few exceptions to that.

For those assessed as bad actors, was any of their mail mixed in with 
mail from a different signer who was assessed to be a good actor?

That differentiation is the value DKIM can provide.  It eliminates or 
reduces noise.


> Now, to John's point, that DKIM alone is not indicative of reputation, 
> that it only serves to ascertain identity, and with that out of the way 
> you can now evaluate the proven identity's reputation. Well, the problem 
> with that is twofold:
> 
> 1) There are no known (at least to me) established reputation providers. 
> And even if there are some that claim to be, history teaches that they 
> don't really accomplish much.

Gosh, you mean that each evaluator needs to formulate their own 
criteria, about a complex, fuzzy topic?  Yup!

> 
> 2) So you're left with building and maintaining your own reputation 
> database.
> 
> That seems like a lot of work to me.

It is.  Sad reality.  Lot of criminals on the streets make safe 
navigation challenging.  Most people need to outsource their safety efforts.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net