[dmarc-ietf] Domains

Joseph Brennan <brennan@columbia.edu> Wed, 02 December 2020 01:43 UTC

Return-Path: <jb51@columbia.edu>
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 299C93A0E0E for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 17:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=columbia.edu
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 Y1Xt_hqAt1b2 for <dmarc@ietfa.amsl.com>; Tue, 1 Dec 2020 17:43:15 -0800 (PST)
Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 0F34B3A0EA8 for <dmarc@ietf.org>; Tue, 1 Dec 2020 17:43:12 -0800 (PST)
Received: from pps.filterd (m0167072.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B21gnlE026211 for <dmarc@ietf.org>; Tue, 1 Dec 2020 20:43:12 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : from : date : message-id : subject : to : content-type; s=pps01; bh=b1hyf60wMe6iDGaavnK7dI/Ab05t1pLzBNHXdchzmBE=; b=jrZ5uktMcIZ+Ye+GYG3h+r/Wst6OsaWPos+PQMfjFzCE/LVVun1LR0afBKP3XwURvhwO aYPHgrqE1SxFBZGSNLKVZvcnO4Md3dC1z4/0oLKJfg1bX8QLVCVy/jRNt06zrie1Saw3 aU7E86ecT9VBoAmXzNOX5OEsIND58lzu9PkhH/uJX95YCbUW3d9dTugTukvw4YOsHmAn XaEETUi+pr56SJwNbUx4MLXEm+RD80zyZY4WCvECARpO6C2GSAHCyh6/dYaq3m5zg9/C 7pYv+VqwuXazvBJbHalXxY1UHcNcLXxlk381OWGcNkDV+xSePTITCdlF3kIT6GygKzD6 Fg==
Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0a-00364e01.pphosted.com with ESMTP id 353km0ev4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dmarc@ietf.org>; Tue, 01 Dec 2020 20:43:12 -0500
Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0B21hABw012225 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <dmarc@ietf.org>; Tue, 1 Dec 2020 20:43:11 -0500
Received: by mail-il1-f197.google.com with SMTP id l2so175303ilj.2 for <dmarc@ietf.org>; Tue, 01 Dec 2020 17:43:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b1hyf60wMe6iDGaavnK7dI/Ab05t1pLzBNHXdchzmBE=; b=q7KcoEOzQKQJ6Sch5jLVef8Y30oHUtCU4Wfkw/+vNhyBa62jmjPU220CfWKr2SCd2b q7KK98X9K267VdRyn7SWDXH944ZGjqR5WOz470bUF9e4QERZpYGqa6ZObz7AQBHIATMh 0OGFubQ2fiM9DMnli7FtDIKdAe/Viy902qt/0Sfbeir6RVxAsH2gAGPGz0XK9PToyuX6 KJEoFC8G7bLM2UXwS5lIYIfUvsJn94Bw3pevdEdurp4KhfRLgFX20YFvQmBaDB0wP8BF +oQO+rXe0qIL2SM3TBW8x6Yx2uYbpQE03S+ml2ZozDJAh8rJylV9x99h6e9aaJmYYy/u YSGQ==
X-Gm-Message-State: AOAM532vctTJ2EX12UxKvn69Ncf0uYS751bqI0G1X4v5sCd+u8LiuOl8 Hfy6/ajDhXAqETsyEMUvFsvy2irlsYsAway/ZPM+vuG60mg9SHbHK6vmLUgxeZljOpvWZzhX3f5 jStglYuyTZ17xKZs5LvysdwgcY8LmoA==
X-Received: by 2002:a02:6a59:: with SMTP id m25mr146294jaf.132.1606873389810; Tue, 01 Dec 2020 17:43:09 -0800 (PST)
X-Google-Smtp-Source: ABdhPJyQ3uNi7/4kimgPZTdIXI7TXwqny0I79mJoDYhpexhZlXlNLG44prq0Hd0/xxaXM8awf8aHXNaU7JIu2r3LKII=
X-Received: by 2002:a02:6a59:: with SMTP id m25mr146281jaf.132.1606873389386; Tue, 01 Dec 2020 17:43:09 -0800 (PST)
MIME-Version: 1.0
From: Joseph Brennan <brennan@columbia.edu>
Date: Tue, 1 Dec 2020 20:42:58 -0500
Message-ID: <CAMSGcLDDQfKPgQDECy-SiRDuJ2s5LmO665V28Y0VrXUvokrKMw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-CU-OB: Yes
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-01_12:2020-11-30, 2020-12-01 signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 priorityscore=1501 bulkscore=10 adultscore=0 malwarescore=0 phishscore=0 mlxlogscore=695 suspectscore=2 spamscore=0 mlxscore=0 impostorscore=10 lowpriorityscore=10 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012020006
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/TO1sYP0dYih9hdjxqLienae2hqU>
Subject: [dmarc-ietf] Domains
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: Wed, 02 Dec 2020 01:43:16 -0000

I want to ask again why DMARC should consider any domain other than
the one in the Header From. The purpose of DMARC should be stated
right at the top of the proposed standard. It is intended to control
use of a domain in the Header From. If the Header From has
blabla@example.com, the DMARC record for _dmarc.example.com should
apply.

It does not make sense to me to say that if the Header From is
user@alpha.example.com, and there is no _dmarc.alpha.example.com
record, then recipient systems should continue to look for
_dmarc.example.com and apply the dmarc rule there. I know of no other
standard that requires this type of relationship. This is something
new. It will require administrators to continually check what their
sub- and supra-domains are doing in order to escape interference by
DMARC records they did not create. I think this is unreasonable. Only
domains interested in applying DMARC should be involved with DMARC.
Others should be able to do what they want. I know that otherwise will
out rule out DMARC for the "columbia.edu" domain that I administer.


-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology