Re: [dmarc-ietf] Rethinking DMARC for PSDs

Scott Kitterman <sklist@kitterman.com> Mon, 08 April 2019 01:59 UTC

Return-Path: <sklist@kitterman.com>
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 C2B0512039A for <dmarc@ietfa.amsl.com>; Sun, 7 Apr 2019 18:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ThvfQRRT; dkim=pass (2048-bit key) header.d=kitterman.com header.b=mdtuABMV
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 FB3q5oi2x55v for <dmarc@ietfa.amsl.com>; Sun, 7 Apr 2019 18:59:36 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B512120636 for <dmarc@ietf.org>; Sun, 7 Apr 2019 18:59:36 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 09E11F807DE for <dmarc@ietf.org>; Sun, 7 Apr 2019 21:59:35 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1554688774; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=vsKZJkeDAX4tvbgENb6Nhy8gh2Cg5700mJf6HzNHOTk=; b=ThvfQRRT+XWv2gE05U3Gk1/XLqZhn/MbwdJ2w7oF6yiNbHavsyvItr6Y qFD6qIE5MVYxrUJHIqP1OuXCf10eAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1554688774; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=vsKZJkeDAX4tvbgENb6Nhy8gh2Cg5700mJf6HzNHOTk=; b=mdtuABMVDxNucw1XTM3/AcitVoMyNLQyNBndyEFzz0ngj4Z5fMUH+QkZ PJNmD7tUCAUj0UaoJOvFRfoux3p9DRWAFTbfdqRfoPDFxca+ASC98d1Bz4 Ooy/T5feNBElrTdiguDMIEk//0Ysr5RpCvr1aHqUyZMqJBEaW34I+MJqIL FisOj2tonb1A/tPHGmyHnY0XchVJeGV4p/ZfaBYnoYk76oYs7VNt4Kk81q zpwwjjGNAsXFyi3HeAw7XzOVRA4SHhmX9GFxU2hxLoOre+sH1/j1DEEJOQ aL+Veguu88QZoipVTSDYuKUfxZU2jhmrV73VUSM7kQNkhRZ4gy/nWA==
Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id CB27CF807D4 for <dmarc@ietf.org>; Sun, 7 Apr 2019 21:59:34 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Sun, 07 Apr 2019 21:59:33 -0400
Message-ID: <2380056.rpXNijDuEj@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-164-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <20190408005045.5EC462011B2BFE@ary.qy>
References: <20190408005045.5EC462011B2BFE@ary.qy>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/cI8wWJX1TbJ8eN8xYQ3AgXllhuY>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs
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: Mon, 08 Apr 2019 01:59:44 -0000

On Sunday, April 07, 2019 08:50:44 PM John Levine wrote:
> In article <c588c5eeec224162bffd080693c703e1@bayviewphysicians.com> you 
write:
> > The problem:
> >  	Spammers use non-existent domains to achieve identity spoofing, such as
> >
> >tax.example.gov.uk
> >
> > This is primarily a reception problem, because many recipient mail filters
> >
> >are not equipped to block this type of fraud. ..
> 
> Right, and we can stop right there.
> 
> A decent spam filter will treat a nonexistent From: domain or envelope
> bounce address as extremely suspicious and send the message into spam
> folder purgatory.  If someone's filters aren't doing that, it is
> unlikely that they're paying much if any attention to DMARC, and no
> amount of fiddling with DMARC will make any difference.
> 
> My mail server rejects anything with a non-existent bounce address at
> SMTP time and I don't think it's ever rejected anything my users would
> want.
> 
> The solution to this problem is for mail systems to fix their filters,
> not to invent yet another mail-breaking hack that they won't use
> anyway.

Which mail breaking hack is that?  Since PSD DMARC almost entirely applies to 
domains that don't send mail, I don't think it breaks anything.  It is in part 
a tool to make hard rejects easier for receivers that don't typically reject 
solely due to non-existence and in part a tool to provide feedback to PSD 
operators so they can understand patters of abuse in their namespace.

As I understand it, rejecting mail from non-existent domains is a long 
standing, well-known tool for receivers.  I hear you saying it works for you 
in your circumstances, but that doesn't mean it scales.  Given that rejecting 
non-existent domains is a well established option, but not everyone does it, 
what basis for optimism do you have  that 'fix their filters' will change 
anything?

If fixing filters was enough, would anyone bothered to have published:

$ dig txt _dmarc.gov.uk +short
"v=DMARC1\;p=reject\;sp=none\;adkim=s\;aspf=s\;fo=1\;rua=mailto:dmarc-
rua@dmarc.service.gov.uk\;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk"

All PSD DMARC would do is make that record apply to domains lower in the tree 
without their own DMARC record.  It's not that complicated.

Fielding of DMARC did a huge amount of damage to the e-mail ecosystem that I'm 
not convinced it will ever fully recover from, but PSD DMARC doesn't add to 
it.

Scott K