Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language

Douglas Foster <dougfoster.emailstandards@gmail.com> Mon, 14 June 2021 23:19 UTC

Return-Path: <dougfoster.emailstandards@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 F3D303A12BD for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 16:19:21 -0700 (PDT)
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 KKoW34TqQMyd for <dmarc@ietfa.amsl.com>; Mon, 14 Jun 2021 16:19:16 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 217193A12BC for <dmarc@ietf.org>; Mon, 14 Jun 2021 16:19:16 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id s23so16172227oiw.9 for <dmarc@ietf.org>; Mon, 14 Jun 2021 16:19:15 -0700 (PDT)
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; bh=SNh5Z4OSjvV4hdBmXVqHV8BRhQYRqY6GtyARRhJ6OgY=; b=CSu8t5OOsVMCuuX3zjtg5Q+aIcZioBVSbWDeBYkK+VvA61N/lOzp42w+lq5IIdCJK+ Pc2v6sN4x1B0paJEhWEOVPGm8u5RX4kuFuNokI6/cC0qIfe1mv+pO+DtBjGXpTAVaElm HhcxeHp1ApSQMfUb0RKfMRe54kGoTy1LhpJ6MyjrEVSlEfcQvBDrATTNqxf/xgvI1Xzh mud/HX+e1t7XvQtMLPVoM494Vhv+jIhbqEg8wxuKtrNjuX/WDmm4X50/EUW1e64YSYvB 5pe05U55TBJ9g+LpAxMHt3ZqkKOn6pRVJvMg0E782i/akVU5ZL1wNhV0mFA1FqjFswN0 Ff5g==
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; bh=SNh5Z4OSjvV4hdBmXVqHV8BRhQYRqY6GtyARRhJ6OgY=; b=plpk98Kg3x8nAg+oeyinFXa4W1Ors6TGTM0+2jtGb3WfQC/RRiQMuIfVGd6ZFxmtTC BHm/a27T+kciXyyxSZGwMtTvBbPpq1TXib2b4TfsH+lvj2EBxw3AlfLmIuE5uVmbynlw SDIpqFojYzSWGMfZdfRQNUGp9+iPzFP5ZHsqRUgZ9ER1s4cU9Gvfvx1LstXNWNp7KA63 VagdPeW5ozX3T++QroiMWpPXpm+SzTJg058QbzpQa4VEWYvwuWkZ5Uyhu/cnS9StJBmm 5ydNEIkl4WGC3+IY7o1p0droXiqO4kMx2vFQvXtt1GY1dw2+wcJRShs4V3POjSQsyCrj HRKw==
X-Gm-Message-State: AOAM533gT9Ifbw3zDqjJlKAXd5MSbx4zoIxBett7uhQPF9iHsrefRwlL GQNod83fNbQf1iR9wp+0SwpcKd7wMpozIoimY1maJlj+uWA=
X-Google-Smtp-Source: ABdhPJw1hDJINPKCfvAytQwORgNwlGlU99wuoJirWX0xU0BJ1UOyxpzhxFW5eOd+oddPa2LSlAKcGbzAVP8FAfV2faY=
X-Received: by 2002:aca:c492:: with SMTP id u140mr1048030oif.20.1623712754265; Mon, 14 Jun 2021 16:19:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAH48ZfzuM298fkmhoZtH1ZbK=9Ne9EYtyTYNV27PSsPBW=Gq-w@mail.gmail.com> <1a666b47-d556-e758-f4ce-05de79c449d1@tana.it>
In-Reply-To: <1a666b47-d556-e758-f4ce-05de79c449d1@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 14 Jun 2021 19:19:03 -0400
Message-ID: <CAH48ZfxxUjvfHsd0QKwXbOqZLyeqhVmzORPekJBoPcwAb8tiiA@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ef709805c4c21556"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/H6MiB54jnkZPxSMoWi1GYEjOUe4>
Subject: Re: [dmarc-ietf] Ticket #11 (and #112) - Proposed language
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, 14 Jun 2021 23:19:22 -0000

Thank you for asking.

OK.,  I will use the term "email suffix" for the part of an email address
that follows the @ character,  and "DNS domain" for a name that appears in
DNS as a domain object.

An email suffix can legitimately be associated with an A/AAAA
resource record that is not a DNS domain.   For example, an alarm
monitoring system might send alarms using the server's host name as the
email suffix (e.g. Alarms@MonitorE.xample.Com).   MX and SPF can also be
configured for Monitor.Example.Com even though it is not a  DNS domain.
This is specifically authorized by RFC 5321.

A spoofed email address could use any email suffix, such as
NotSpam@TrickedYou.Example.Com.   Our interest must extend beyond names
that are in DNS.

In my mailstream, most messages sent from mailing services use the mailing
service domain for the SMTP address.  This insures that the message
produces SPF PASS.  It also means that the FROM domain name has no
necessary dependence on any DNS entry.   It took me only one day to find
examples of this;,non-existent subdomains used on legitimate messages sent
by mailing services.  The FROM suffix correctly reflects the parent
organization, but the full email suffix does not appear in DNS.   This
situation means that we cannot distinguish between valid and invalid email
suffixes using DNS alone, we must require domain owner signalling.

How does a domain owner signal that @bounce.e.example.com is valid as a
FROM domain, even though the name is only used for mailing service
messages?    Under the current draft, the domain owner must associate the
name with an IP address using an MX, A, or SPF record, even though the name
has no legitimate connection to the chosen IP address.  I do not consider
this acceptable.   In the real world, I fear that implementing such a
requirement will have unexpected consequences, and network administrators
who share my fear will be reluctant to comply with our draft.

I focused on SP and NP because it is the SP or NP policy which provides
inheritance,  Inheritance has to be the primary way that we defend against
abuse of unused and non-existent email suffixes

You asked a lot of questions.   I think I should stop there and give you a
chance to respond before going further.

Doug Foster


On Mon, Jun 14, 2021 at 7:12 AM Alessandro Vesely <vesely@tana.it> wrote:

> Doug,
>
> maybe it's me, but I have problems understanding your proposal.  Let me
> quote
> what seems to hamper my comprehension.
>
> Besides, #11 in the Subject: is obviously a typo.
>
>
> On Sat 12/Jun/2021 14:55:33 +0200 Douglas Foster wrote:
> > ties the design directly to the mailing list problem.
>
>
> I couldn't see where mailing lists are taken into account.
>
>
> >    However,this authentication can be lost in transit if message
> modification
> > occurs in transit, as discussed in RFC 7960.  This possibility can make
> domain
> > owners reluctant to move beyond sp=none.
>
>
> Why do you consider SP irrespective of P?  Actually, SP could be used by
> "simple" mail sites, those which make no use of subdomains for email.  In
> such
> cases, setting sp=reject can safely prevent generic abuses even for
> domains
> having p=none.  It sounds similar to null SPF records for non-mail hosts.
>
>
> > x.1 Implement mail domains as DNS domains with domain-level DMARC
> policies.
> >
> > Mail domains are often implemented as DNS domains, but this is not
> required.
>
>
> Please, stick to well established jargon.  Tim made a good synthesis in
> section
> 2.2 and ensuing ones.  A /DNS domain/ is defined by RFC 1034:
>
>      A domain is identified by a domain name, and consists of that part of
>      the domain name space that is at or below the domain name which
>      specifies the domain.
>
> In this sense, the concept of non-existing domain names that are
> legitimately
> used sounds like a contradiction in terms.
>
>
> > Once all used mail domain names are configured as DNS domains, they can
> be
> > configured with DMARC policies.
>
> AFAICS, a /used mail domain name/ which is not a DNS name is a
> /non-existent
> domain/ found in some (forged) email addresses.  I agree that such
> practice
> should be discouraged.  Yet, that doesn't seem to be the point here...
>
> BTW, are there organizations that use non-existent (sub) domains during
> the
> delivery of legitimate messages?  Years ago I saw sporadic mailing list
> authors
> forged like john.doe@NOSPAMexample.com.  Is that what you're talking
> about?
>
>
> > - For mail domain names that are not used with SMTP, a new TXT record is
> > defined, with content "DMARCFROMv1".   The presence of this TXT record
> > indicates that the associated DNS domain, named DNS resource record, or
> > wildcard DNS record should be considered as potentially in use as an
> > RFC5322.From domain name.
>
>
> Ok, that is clear, but, IMHO, won't work.  Working MXes or IP addresses
> are a
> necessary condition to receive mail.  Thus, a purist receiver has to
> accept
> such domains as valid.  Therefore traditionalist domain operators will not
> see
> a compelling need to define any auxiliary TXT records.  A new RR type of
> this
> kind would most probably be going to characterize mass mailers who hasten
> to
> adopt any new trick that seems to offer a chance to increase
> deliverability.
> Undoubtedly, someone would be tempted to discard senders based on that (as
> it
> happened to DKIM...)
>
> An organization which wants to say sp=reject but does use some email
> subdomains
> had better define plain DMARC records for them.  Records can be easily
> duplicated by CNAMEs.  If we needed to vary some parts but not others, for
> example a different policy but the same aggregate reporting address, we
> should
> define something equivalent to SPF's include.
>
>
> > - For used domain names that are not in DNS at all, a DMARCFROMv1 TXT
> record
> > is needed to indicate that the name is used for mail.
>
> Actually, /any/ record definition will turn a domain into an existing one.
> However, by Section 2.7 of PSD, which defines the MX/A/AAAA test, such
> domain
> would still be non-existing.  In that sense, DMARCFROMv1 conflicts with
> PSD.
>
>
> > x,3 Implement SPF -ALL policies on unused names.
> >
> > Organizations that have configured SPF to protect their valid
> RFC5321.MailFrom
> > domains may not have taken the extra measure of using SPF to obstruct
> names
> > that are not used for mail.  While not directly part of DMARC, an
> > authentication result of "DMARC=NONE SPF=FAIL" is a more meaningful
> result than
> > "DMARC=NONE, SPF=NONE".  Consequently, it is desirable to  ensure
> SPF=FAIL for
> > any names that are never used as RFC5321.MailFrom domain names.   Since
> SPF has
> > no inheritance, this requires many entries.
>
>
> That's a well known SPF issue:
> http://www.open-spf.org/FAQ/Common_mistakes/#all-domains
>
> There used to circulate scripts to generate null SPF records.  It would
> help if
> DNS hosting services implemented a checkbox to carry out such task.  But
> this
> if far OT.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>