Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Ian Levy <ian.levy@ncsc.gov.uk> Tue, 16 July 2019 17:34 UTC

Return-Path: <ian.levy@ncsc.gov.uk>
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 32E2B120A90 for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 10:34:17 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk
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 OHRH79GHaPCT for <dmarc@ietfa.amsl.com>; Tue, 16 Jul 2019 10:34:14 -0700 (PDT)
Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110122.outbound.protection.outlook.com [40.107.11.122]) (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 0FE35120ABF for <dmarc@ietf.org>; Tue, 16 Jul 2019 10:34:12 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AXs7Yu4zRAi8lFb1zroSwNyxaob1eiebjBprfEGuS7rWbPmG5D84BPgHXgtZmh87eFzMopttTOSWv5udcJeKCEexyWbl6uLz5jk70snYm9i0hP/5obrF0vcXN7R9qrxEuX0IInYN5gRBdhC63vM9U8s7T8xbKWZA0SwYfehVUO7GkoLSLwfhaj7vKS+qK/IckwnPMpx08eSXKYHASejfQq1bLFqLvQ+nKlpe+EYsSoLUt15I2rjrLlfnraoSZ5x9sLzE8Dzc96llYH+HyzkrHQSkDWKL2jHchKF1gncKK7ypoEKjNEQSmPwV6w7s1IshIBk/yqktX05YRyVDwUON7A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Iy7du59A47RpVdstudFK5+z0jDdYOQSqOQsWkcjcP/Q=; b=BJhGDSIEdKdwZe2n2KfwVyVw4Kwvg2qKzfOOKwrXoZXCRNEWU+o3zO4+5rYUQRlTY5ehGc9LYgYFCqpPvTj7/JdHhiuS15ZHL1kavztpW6AtwK3bXCBQEVMVOFxQ1JAyYWHomee/1EGafDuZAzA9j35J8WpLftTqQNNyQzHuCALlrcKnPoxBP3uLcI+WNhAe5vje8gEzZkR8M1DglNcjjJjXD0VaF3xMoqQ0ofSFYKV/9MpU3cugiLNIG0XqKFvdizhHJ/+CUeZyQbUKS39RkzAncAxb4FNCHFUFjKfDAryBC/CuM5CWil8P1d+jIIutwjwWH8nWN5FZVOfqRP0OxQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ncsc.gov.uk;dmarc=pass action=none header.from=ncsc.gov.uk;dkim=pass header.d=ncsc.gov.uk;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Iy7du59A47RpVdstudFK5+z0jDdYOQSqOQsWkcjcP/Q=; b=B6PtvudnN0UknUO6RZQUbkmkYqZnBQQXj09SES3pYYuNwXT/jK5XqotLjD0H1q95bQFL7YT0RpG1j/yKXaciarvYpnX6LjEnn9eaA/fLOArQZ7RU1uOMQfRkAkiZjsSPndV7Zd2HYQ63kDq19/3Utxv7mip2V0Kvpav/gDRmZfs=
Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM (20.176.157.151) by LO2P123MB2462.GBRP123.PROD.OUTLOOK.COM (20.176.157.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Tue, 16 Jul 2019 17:34:10 +0000
Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0%5]) with mapi id 15.20.2073.012; Tue, 16 Jul 2019 17:34:10 +0000
From: Ian Levy <ian.levy@ncsc.gov.uk>
To: Alessandro Vesely <vesely@tana.it>, "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
Thread-Index: AQHVONo/47N98C6WmEulUndQgJsxhKbHRCGAgAAF1oCAABAxAIAAFoEAgACGD4CAABkfAIACPhxAgAMMsYCAACoh8A==
Date: Tue, 16 Jul 2019 17:34:10 +0000
Message-ID: <LO2P123MB2285E4E4A1F18A3F7AFC5FC1C9CE0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
References: <20190713043409.A5EB64A61C0@ary.local> <3017917.gKNyNSpcLf@l5580> <LO2P123MB22851389EC8F8098BD80211CC9CF0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM> <51e6b971-270e-a54f-bfb1-4a5d0ba8a94f@tana.it>
In-Reply-To: <51e6b971-270e-a54f-bfb1-4a5d0ba8a94f@tana.it>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.levy@ncsc.gov.uk;
x-originating-ip: [51.141.26.231]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a5a05338-84c6-4cf8-ea6f-08d70a13d018
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2462;
x-ms-traffictypediagnostic: LO2P123MB2462:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <LO2P123MB2462D07583F9AACB44E10CEAC9CE0@LO2P123MB2462.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0100732B76
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(366004)(346002)(376002)(136003)(39850400004)(189003)(199004)(13464003)(14454004)(7696005)(476003)(66066001)(52536014)(76176011)(305945005)(7736002)(11346002)(446003)(86362001)(2501003)(66476007)(71200400001)(71190400001)(8676002)(66446008)(66556008)(64756008)(76116006)(186003)(81166006)(81156014)(486006)(44832011)(6246003)(8936002)(102836004)(53936002)(9686003)(2906002)(55016002)(6306002)(6436002)(966005)(256004)(3846002)(6116002)(14444005)(6506007)(229853002)(5024004)(26005)(99286004)(5660300002)(316002)(110136005)(66946007)(74316002)(478600001)(33656002)(45080400002)(68736007)(55236004)(4000180100002)(25786009)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2462; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 7UtNC20ovVt97nVLS0FlD/nNxWpszUKPacjY6c37x6XcgJSHe0gxV8GkmFBLJtWeTYYjQjNE2uiXkiV6un5miBcpxrbY6mWk1FwD6cfMtmjO6olN/UVW1HT/k8qKoaqS+XvQom4AGW1ZVsEf2AkIDnDHWi9WWQUJy9vTvPiUAilltO9NuO2ikpVzgFrS+SBvjPyHWPTuDZmJFlNMUeKrDLTyvmz5NG01x0FW7ntzfMwiQkxE5FjKkdhz/Vs2ATosrAK71+iiylkefNXdyXlZ6fzu5EOFaq2gP56Y3qlM8pJtg/qrhzESl2Cd666DOb7EIAZyGuFkHWD/t7Zkjut4ylSdKbfxUqHo7mnHBzLKHEpjc8JK24zVGG5Q/yHOoLBR61kx6bK//rHVYqdiHFtGJLlyHA4wrjPoRU5EU5Nfc/A=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ncsc.gov.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: a5a05338-84c6-4cf8-ea6f-08d70a13d018
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 17:34:10.6135 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ian40919@ncsc.gov.uk
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2462
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/mXdogrSuFKxYXTRn_K2lJgY9q8M>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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: Tue, 16 Jul 2019 17:34:17 -0000

> Mail.ru reports seem to be missing from non-existing domains.  

Yep, that's our experience. We get plenty of DMARC reports from mail.ru in the course of normal business; just not in the non-existent domain case. Interesting that your experience was different, though. 

> It is possible that some cases of non-existent domain are treated as a short-cut

That's certainly my assumption.

I think the point is that the current behaviour is inconsistent (even more inconsistent than 'real DMARC'), hence the need for this experiment. I mentioned the report yesterday. It's now published and linked off here : https://www.ncsc.gov.uk/blog-post/active-cyber-defence--acd---the-second-year

There's a whole section on our experience and work on DMARC that may be interesting to the group, including some of the effects of the specific problem we're talking about here. 

Ta.

I.

--
Dr Ian Levy
Technical Director
National Cyber Security Centre
ian@ncsc.gov.uk

Staff Officer : Kate Atkins, kate.a@ncsc.gov.uk

(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)

-----Original Message-----
From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Alessandro Vesely
Sent: 16 July 2019 15:53
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Mon 15/Jul/2019 09:08:04 +0200 Ian Levy wrote:

> Sorry for not contributing more to this thread - please don't take it as any indication of lack of interest. For UK NCSC specifically, I think we'd prefer NXDOMAIN rather than NODATA, given it's more constrained and this is an experiment. My view would be that if we've published a name under gov.uk, even with no valid (in the eyes of the receiver) associated records, then *someone* is responsible for it and we can go find and educate them. They may even believe they have a valid reason for doing so that may outweigh any email authentication concerns. But there's a conversation to be had. If there's no published name, then there's no-one responsible, so it should default to the top-level policy.


I agree that np should default to p.  The original wording for sp is also simpler than''If absent, the policy specified by the "sp" (if present) and then the "p" tag, if not, MUST be applied for non-existent subdomains.''  (BTW, mind that "sp" instead of "np" in the new tag's definition.)


> [...]
> Here's the volume of reports received on our normal DMARC processing chain in January 2019 (noting Microsoft are one of the bigger providers in the UK and *still* don't generate any reports):
>
> Reporter      Total Reports
> google.com    61,363,605
> Yahoo! Inc.   18,876,201
> Mail.Ru       699,554
> sercoglobal.com 227,587
> AMAZON-SES    178,262


That is at odds with the order reported by dmarcian:

NetEase (163.com, 126.com, yeah.net)
Google *
Yahoo!
Microsoft
AOL
cisco Systems
DHL
Comcast *
Tencent (qq.com)
Mail.ru
.... https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdmarc.org%2Fstats%2Fdmarc-reporting%2F&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7Cb422dd587d5543c6142908d709fd6300%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636988856820114383&amp;sdata=8ikFqwHQDkEaOQVJslti2vYNp8jYWU4C7omM7SJAAuY%3D&amp;reserved=0
(That used to be on dmarcian, but couldn't find it any more)


> And here's the volume for the same month for the synthetic DMARC reports :
> Reporter              Total Reports
> google.com            23,745
> Yahoo! Inc.           1,060
> emailsrvr.com                 64
> dev.johnlewis.co.uk   37
> bridgend.gov.uk       30
>
> Just from that, it's pretty clear that the synthesized DMARC records are not universally processed, which gives weight to completing this work and starting to try things out. Given the level of inconsistency we see in receiver behaviour, I think it'd be easier to start with NXDOMAIN and see what that actually achieves.
>
> I may well be missing something subtle, so please correct me if I've got this wrong.


Hmm...  Mail.ru reports seem to be missing from non-existing domains.  My experience differs slightly.  Yesterday I sent a few messages to mail.ru.  Five of them from a nonext domain (IP 5.170.8.66), all of which were rejected, two of which were reported in the aggregate report attached.  However risible these numbers may sound when compared to yours, it is clear that not all messages are reported.

It is possible that some cases of non-existent domain are treated as a short-cut, skipping message registration and DMARC verification altogether, even if the reject always came after DATA...  Just mumbling.  Considering that most DMARC packages work as mail filters, I'd expect messages filtered out before will never make their way to aggregate reports.  Is that a DMARC violation?


Best
Ale
--












This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright ©