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

Dave Crocker <dhc@dcrocker.net> Tue, 25 May 2021 23:18 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 E82AF3A1265 for <ietf-smtp@ietfa.amsl.com>; Tue, 25 May 2021 16:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_H4=0.001, RCVD_IN_MSPIKE_WL=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 riBHyOLP--3d for <ietf-smtp@ietfa.amsl.com>; Tue, 25 May 2021 16:18:32 -0700 (PDT)
Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (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 77B0F3A1262 for <ietf-smtp@ietf.org>; Tue, 25 May 2021 16:18:32 -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 449EF341BB2; Tue, 25 May 2021 23:18:31 +0000 (UTC)
Received: from nl-srv-smtpout4.hostinger.io (100-98-55-237.trex.outbound.svc.cluster.local [100.98.55.237]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 2F5DF34198C; Tue, 25 May 2021 23:18:29 +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.98.55.237 (trex/6.2.1); Tue, 25 May 2021 23:18:31 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net
X-MailChannels-Auth-Id: hostingeremail
X-Decisive-Bored: 62574d851aebeb24_1621984710880_881917753
X-MC-Loop-Signature: 1621984710880:2513204705
X-MC-Ingress-Time: 1621984710880
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 122FA31EB0D4; Tue, 25 May 2021 23:18:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1621984707; bh=2eAw10SYbW1hQiVuQR693pqcKWerwgGZO4V2AQvoj7M=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=qXNdf3Hfoz/1sMMKLqCz89P5kLdSwvBozH0D8mSoCGobz4oS6m9G7RLoRAAqudI9l agKB316/LxUp6HSXjemo8MUDyKmZiNiNiMZtB/QvKOEbZjNbn3xbEQfu6P8mILnjGh Dv+A2/AlsJRhzW9VBHNYoS+9SPj20joyaaY7psjPyjuImGN5Ww5Og93Rwhdyo/6Y9T JFwfp3kYKax+BhXdtPWY1ra/+u5K/lvk2HI9Yq5d63CCX/OrupDDaujjETzLdV/75N cMbSRC5X6hGzSYqD52D+rdQUALT+pUkk0KKkul2ZGcWGsYJ1ly0S/1wkl/VVTS3+RY N4jDHbAf6VRdA==
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>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <14fa34c7-c6a2-2c2c-3de9-f4f8c7327f9e@dcrocker.net>
Date: Tue, 25 May 2021 16:18:23 -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.1621939932.396187.66265.1004@monster.email-scan.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/8ujle4lQQkHf5gtKJVL47gJeehc>
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: Tue, 25 May 2021 23:18:38 -0000

On 5/25/2021 3:52 AM, Sam Varshavchik wrote
> To me that's not fundamentally different from filtering based on the 
> sending IP address.

In its simplest terms, it isn't.  But then, simplest is not enough here.

First, IP breaks after one MTA hop and DKIM doesn't.

Second, IP mixes all sorts of traffic and DKIM doesn't (or, at least, it 
doesn't have to).  That is, DKIM can be used to highly partition and 
identify content streams.  This allows clean, accurate narrow-band 
reputation analysis.  IP allows only a very coarse reputation grain.

How signers actually use DKIM might well be different from how they 
/could/ use it, of course...


>> 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.

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.


>> The original point of DMARC was for B2C or B2B mail from heavily
>> phished domains like Paypal, that could say please discard anything
>> from us that fails DMARC and we understand that might be some real
>> mail. (All of Paypal's mail just says "something happened, look at our
>> web site".) It still works pretty well for that.
> 
> Eh, no. A large majority of user-facing mail clients are now hiding the 
> sending mail address, and showing only the name, up front.

Users are pretty much irrelevant to DMARC.  DMARC is for use by the 
receiving filtering engine.  It doesn't matter what From: field data is 
displayed to users.  (Really.  It.  Does.  Not.  Matter.)

> From: "Paypal Customer Service" <kjsdfjklk@934iowero.us>
> 
> Most people will see "Paypal Customer Service". Valid domain signature 
> for 934iowero.us, and straight it goes into your Inbox.

Noting that operators continue to claim benefit in supporting DMARC, the 
fact that it is easy to circumvent means that its utility is tactical 
rather than strategic.  I'm not a fan of tactical (ie, limited) benefit 
in standards work, but I didn't have a vote...  More importantly, they 
claim they /do/ see real filtering benefit.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net