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
- [ietf-smtp] Email explained from first principles Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… Bron Gondwana
- Re: [ietf-smtp] Email explained from first princi… Alessandro Vesely
- Re: [ietf-smtp] Email explained from first princi… Viktor Dukhovni
- Re: [ietf-smtp] Email explained from first princi… Viktor Dukhovni
- Re: [ietf-smtp] Email explained from first princi… Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… Peter J. Holzer
- Re: [ietf-smtp] Email explained from first princi… John Levine
- Re: [ietf-smtp] Email explained from first princi… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John Levine
- Re: [ietf-smtp] Email explained from first princi… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Matthias Leisi
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Dave Crocker
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John Levine
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Sam Varshavchik
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… Nathaniel Borenstein
- Re: [ietf-smtp] DKIM and DMARC, Email explained f… John C Klensin
- Re: [ietf-smtp] Email explained from first princi… Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] Email explained from first princi… Kaspar Etter
- Re: [ietf-smtp] Email explained from first princi… John R Levine
- Re: [ietf-smtp] Email explained from first princi… Richard Clayton
- Re: [ietf-smtp] Email explained from first princi… Alessandro Vesely
- Re: [ietf-smtp] Email explained from first princi… John C Klensin
- Re: [ietf-smtp] the point of domain authentication John R Levine
- Re: [ietf-smtp] mailing lists are complicated, wa… John Levine
- Re: [ietf-smtp] the point of domain authentication Sam Varshavchik
- Re: [ietf-smtp] the point of domain authentication John Levine
- Re: [ietf-smtp] mailing lists are complicated, wa… Alessandro Vesely
- Re: [ietf-smtp] mailing lists are complicated, wa… John R Levine
- Re: [ietf-smtp] mailing lists are complicated, wa… Dave Crocker
- Re: [ietf-smtp] Email explained from first princi… Richard Clayton
- Re: [ietf-smtp] mailing lists are complicated, wa… Alessandro Vesely