Re: [dmarc-ietf] non-mailing list use case for differing header domains

Ken O'Driscoll <ken@wemonitoremail.com> Mon, 03 August 2020 12:56 UTC

Return-Path: <ken@wemonitoremail.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 6E22C3A08E1 for <dmarc@ietfa.amsl.com>; Mon, 3 Aug 2020 05:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=wemonitoremail.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 vCgTKCWTjj48 for <dmarc@ietfa.amsl.com>; Mon, 3 Aug 2020 05:56:57 -0700 (PDT)
Received: from email.wemonitoremail.com (email.wemonitoremail.com [78.47.26.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573143A08DB for <dmarc@ietf.org>; Mon, 3 Aug 2020 05:56:57 -0700 (PDT)
Received: from localhost [127.0.0.1]
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=mail; t=1596459414; bh=8Ignnwm16YqCJ2+tOmlWTHOtBhevNBWm6KOoxWsYfiE=; h=Subject:To:References:From:Date:In-Reply-To; b=qxbauhpW1IxjtNVFkmbcLvL8YuKY3hfs/SG2FXBh+NHBbFFBRAv1V0XGUg4xZFfxw IIfX65mzLh/+QVdgzhb623woOMrwRyxsmmTVCzrldsynxcy3DjVvNtCgUagJB27hR9 372BcTWykDMZ/xg039pnX6Ukm9D3GGjGJjl3Ag08=
To: dmarc@ietf.org
References: <20200802165756.3892C1DC82FD@ary.qy> <719dce3edbc54b25b6ebf248170e7eb2@bayviewphysicians.com> <CAL0qLwYFoGHL13tLOnbgf97qtgLFDo4AmutZdQvMVsuX56Vz0Q@mail.gmail.com> <fa39426a-c14b-493c-85f2-58a682461c2d@dcrocker.net> <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com>
From: Ken O'Driscoll <ken@wemonitoremail.com>
Organization: We Monitor Email
Message-ID: <8360ceb4-d70e-9071-a8ca-21976210551a@wemonitoremail.com>
Date: Mon, 03 Aug 2020 13:56:52 +0100
MIME-Version: 1.0
In-Reply-To: <0bc56bf161c54870b4655e98d7297f64@bayviewphysicians.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fgsQtBqwzGBV40glU8M6WyW-Vlk>
Subject: Re: [dmarc-ietf] non-mailing list use case for differing header 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: Mon, 03 Aug 2020 12:56:58 -0000

On 03/08/2020 01:43, Douglas E. Foster wrote:
>
> I am not sure what "Internet Scale" means to you.   Most of the major
> recipients have bulk mailer registration systems.   It does not
> guarantee whitelisting, but it tends to produce that effect.   I have
> had occasion to register with most of them.   So "does not scale" is
> not obvious to me.

This is not correct. In the past some large providers did offer such
lists but these days most have moved away from that model for various
reasons. You'll still find someone offering such as service, and
pay-to-play is a thing too but none of this is a) widespread and b)
based on any type of standard - it's all proprietary. The same goes for
sender certification services such as ReturnPath.

"Internet Scale" means being able to scale to internet level of usage
and platform interoperability.  TCP/IP and DNS are good examples. Data
(e.g. lists of approved senders) maintained internally by individual
organisations can't scale to that level for the same reason that
organisations siloing their own DNS and routing information wouldn't
work. Interoperability.

Organisations publishing information (e.g. an SPF record) in their DNS
zone works because it's based on an existing internet scale
interoperable platform. While the "heavy lifting" of interpreting the
SPF record might be undertaken by a variety of different software and
system platforms, the mechanism is standardised based on the RFC. Again,
interoperability.

Ken.