Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

Dotzero <dotzero@gmail.com> Fri, 13 November 2020 15:04 UTC

Return-Path: <dotzero@gmail.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 640693A0D87 for <dmarc@ietfa.amsl.com>; Fri, 13 Nov 2020 07:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.com
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 B7tT_agK8gDi for <dmarc@ietfa.amsl.com>; Fri, 13 Nov 2020 07:04:27 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11A73A0D7B for <dmarc@ietf.org>; Fri, 13 Nov 2020 07:03:48 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id 199so9004675qkg.9 for <dmarc@ietf.org>; Fri, 13 Nov 2020 07:03:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0fBut46YAg8iVlrif4Qth68/9AKkGsDRSd72EsC6h+A=; b=f1nrQbStYednZOGY/2f8HGplzN3mRzfOi9k7ZAkob/vONheFze1XSRFCqsjDlyt4Qc oi6n6qARk2vlsyUiE1+a+fftq2jNaJkLqqd/t2tuUfxnROZwJtHyqmS9eTiGxT6mNyoF wTVClzIq+G1aLcbb5+ynD9X/5jQ7hWJ/jHcBJ8jtPgPi/TQnVThKe54qAYqx5Eulhbtu 91dGNLQIP5QRPcvTtrPNhoIKZzcmPa/yDGNm9NbV1IH8dfeQoRAu7kkgBSsrl4Tay4+y 9tRq8JCQQ2uFXVjVapkbZfrkQIDQKVuJ4GorogA/pS6QGVuU0XDlMMKSZCSPg7LEb/1j PYoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0fBut46YAg8iVlrif4Qth68/9AKkGsDRSd72EsC6h+A=; b=ohIId6jibdSFjwmFw8AW6PXAcECqmLFp2nbfyuIsyJv9QQoGn5EmuSjJdtjaEh9Kz/ bhEmR4WI7SPkP3U5AgzCcZBqdNcK5JXaMR9YPUX43ZTKvf/sz3N/VgIqoJM5MJE1k1IX t7BixisLBNMtAaK5WShF1tWi0M9327g8ObnRqKGMZwjORFicR1u1jFD2qdja7lzp0pT5 n8o37SGEyVds8WTDH+Av43t9m2iHQ5Y1bFqbY0mrMvURp+3IcAFrAPL4u3F3x4pNyeYC hC66+v/HiWqxHmjFtp59nD5TfYz8i/l35I1bIO1mnrKqHSUR+g0O5X0Z5mzKJzuLZNy6 auyg==
X-Gm-Message-State: AOAM5324Z/BuUso742bcSH5oSZ/BIU/qsmt952BpcQFD3AJfAQ7BQC7J qO2By8g+FnNyVcfBYPjjRw1JyjQwSkyh8j2yeBM=
X-Google-Smtp-Source: ABdhPJxTn80R8xP/FUrDvCg6/dzk90xCiiKu9krXieuzOuN7jadem6LBhQNQnTDpVxDO3edHY5SGuB4w49+/gUnk6eM=
X-Received: by 2002:a37:ef04:: with SMTP id j4mr2525864qkk.368.1605279827729; Fri, 13 Nov 2020 07:03:47 -0800 (PST)
MIME-Version: 1.0
References: <20201111181837.79128262943F@ary.qy> <f1eabf10-0278-a6cc-997b-333e89446c16@dcrocker.net> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> <c18f2987-84d6-9ef4-b57d-912094e3031c@dcrocker.net> <CAMSGcLCOUG_a13kwgU==HdpHG+ZpMO5caO2tXKqk3TH=N7-8XA@mail.gmail.com> <CAJ4XoYc02dB8Ftocus67hV2eM4uHgYFQed2xP1b5RSKgvCz4NA@mail.gmail.com> <CAMSGcLC+n5HJU_pbE9VuMgEFs9BPeB32ZvAmjgSsr8kysdk_Ug@mail.gmail.com>
In-Reply-To: <CAMSGcLC+n5HJU_pbE9VuMgEFs9BPeB32ZvAmjgSsr8kysdk_Ug@mail.gmail.com>
From: Dotzero <dotzero@gmail.com>
Date: Fri, 13 Nov 2020 10:03:35 -0500
Message-ID: <CAJ4XoYeUM07HnZihONo1oreL7UHDq+8+XckDg5KcKm5Abe-E1w@mail.gmail.com>
To: Joseph Brennan <brennan@columbia.edu>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e5a05605b3fe5560"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/nEyFRb-uDx9GF4NAhZmQ4UfkVDE>
Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND
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: Fri, 13 Nov 2020 15:04:29 -0000

On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan <brennan@columbia.edu> wrote:

>
>
>>> As another case, would people be surprised that email for the medical
>>> center cumc.columbia.edu is a separate system managed by a separate IT
>>> group from columbia.edu, and that any authentication for one should not
>>> be applied to the other?  I don't think this is unique in large
>>> decentralized universities. The real email world is a complicated place.
>>>
>>>
>> The simple solution is for  cumc.columbia.eduto publish its own record.
>> Done.
>>
>> Michael Hammer
>>
>
> I don't think I have the right to force the owner of another domain to
> publish dmarc. The owner of the other domain may want to allow users in
> their domain to contribute to lists and groups without having their
> messages rejected, or mangled by well-intentioned workarounds. This is not
> simple. This is a real-world case with the domains ending columbia.edu.
>

If CUMC publishes a DMARC record for cumc.columbia.edu, how is it forcing
another domain to do anything? As far as "owner of a domain", If Columbia
University registered the domain columbia.edu, then CUMC is using the
subdomain because Columbia University is allowing it to, presumably through
some sort of written agreement. A technical standards body cannot address
business and contractual arrangement in the manner you appear to be asking.
If Columbia University stopped delegating the subdomain cumc.columbia.edu,
would you turn to the IETF for redress?

Michael Hammer