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

Dotzero <dotzero@gmail.com> Mon, 22 July 2019 11:45 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 1B75E120233 for <dmarc@ietfa.amsl.com>; Mon, 22 Jul 2019 04:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qvCMuD9G_JKw for <dmarc@ietfa.amsl.com>; Mon, 22 Jul 2019 04:45:43 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 9312512006F for <dmarc@ietf.org>; Mon, 22 Jul 2019 04:45:43 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id l2so34996040wmg.0 for <dmarc@ietf.org>; Mon, 22 Jul 2019 04:45:43 -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 :cc; bh=YKM+9vspnp4ZBLi1yVVOpD9oRbQ2Ahnrp4OB+A3oUNI=; b=D6Z2D9s+oTNcasvE7WILnShYUSUU7psEpavw/kg4FiaIht5G+EoVQX6q71ZheEzZKg D0YOeWNgn5FR3A8hsH81+ny9wBIdBrjfLVOJTPNIoFtIoaD06tPZRinJVTrm1Y2tG1fQ 8WIhmWW+TZAKygdx4b+rDm2s8L7hlXQFuY+MR6JPxfk7up5j1z+YFHwN/ltj7LLBVLBj 0tFCv1O8H29jj7HjkEEa7kA4mbh22McUt5ZB1M7eboD3mPRmpS2wjkUb0+4ESq8KBni/ NcnwXa8Ud+pJCqfVciUDeai4O0iLj7W+E5Fx9TF5DXiYtcwI9InqB2DpeNAY/bC9XSS7 H6qA==
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=YKM+9vspnp4ZBLi1yVVOpD9oRbQ2Ahnrp4OB+A3oUNI=; b=p5V6243zgvzPReT0uoz9qrbOtcsLsfF1W2NDlhyYIVBnDE3am4iys2QE8ul36yOSrl M2ImqqeLldHnnG9SrUXdqIJTZI9mfGxNPeZMlrAa/ZfBoz4xXxjRxC2hOfJoG7vWGdl6 leMk3cXroM1kpELiyBoVAN1moxqTd6U7uV6X+zxIFMyzo6VepGw1Mq1/usrFfCb3ogTh hWaK/ey2K86llQqUvSgMrOv+QDosMaxLqvn1mGX+dBZrtktGsoVr1+xQb3LB6s4sdrEr xNgBj+yda5OjKla3Rn6NN9RGXdcXAEYFPlCCNyI649Yl73+68hM5YbSW3tBgWrGo7esQ 7L2g==
X-Gm-Message-State: APjAAAWW0CHBnvx8wBQHcQApSmXcbI48F64dxn9ZOFK39WxGSEl+GhdF bFSgCswZ3mksyOJ1JE6NJ97TD1ziHcr2mRv2wEoJOw==
X-Google-Smtp-Source: APXvYqwoVTfb/y/tiGycC1AoJ8qyp1rav6eU3Mvi6K39rd5UZh/twx0SEzT4+kPTMEtI/Q0PVR92mcgNG/1lurfw/T8=
X-Received: by 2002:a1c:35c2:: with SMTP id c185mr62614505wma.58.1563795942064; Mon, 22 Jul 2019 04:45:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <1808303.aIhlromXIS@l5580> <CAD2i3WN42v0RHzu+2=+_mjX5kmxw6B-0F3-=bY-bTEsJM1qLvA@mail.gmail.com> <1692123.ljdY5SVR4M@l5580> <CAD2i3WPGWe8Z3av1Jua6sazsoStc7VTOLBve7psVo=K4VGTgig@mail.gmail.com> <D42C419C-F02E-4B5A-BB10-E8D49000349B@kitterman.com> <659dfb1f-dcb2-86ca-55a1-b3af6ce7ed1c@tana.it> <83f0b1ffbf0c466eb3bc66e3510738f0@bayviewphysicians.com> <5A081736-B654-4CFB-9551-6F750A1120A5@kitterman.com>
In-Reply-To: <5A081736-B654-4CFB-9551-6F750A1120A5@kitterman.com>
From: Dotzero <dotzero@gmail.com>
Date: Mon, 22 Jul 2019 07:45:31 -0400
Message-ID: <CAJ4XoYe_+PFTjJd8AckdL8gkPR5vXuq9QwH=EhhBzAE+Jpqr7Q@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a0c6a8058e439de0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-YeZ_rGkOgJx8mruT37wAZ7aZK0>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working GroupLast 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: Mon, 22 Jul 2019 11:45:46 -0000

+1 on Scott's comment.

Michael Hammer

On Mon, Jul 22, 2019 at 6:44 AM Scott Kitterman <sklist@kitterman.com>;
wrote:

>
>
> On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" <
> fosterd@bayviewphysicians.com>; wrote:
> >About this paragraph:
> >
> >>> The original pre-standardization version of this protocol included a
> >  >> mandatory check of this nature. It was ultimately removed, as the
> >>> method's error rate was too high without substantial manual tuning
> >>> and heuristic work. There are indeed use cases this work needs to
> >>> address where such a method would return a negative result about a
> >>> domain for which reporting is desired, such as a registered domain
> >>> name that never sends legitimate mail and thus has none of these
> >>> records present in the DNS.
> >
> >This section seems to give a free pass to senders who use non-existent
> >domains, as if such behavior had no impact on the risk posture of the
> >recipient.
> >It seems to say, "You can keep doing this, because so is everyone
> >else."
> >
> > I would think better language would be along the following lines:
> >
> >
> >
> >"Senders SHOULD register all domains in DNS, as MTA operators MAY block
> >
> >messages that appear to come from non-existent domains.
> >Developers of MTA filtering software SHOULD provide MTA operators with
> >the
> >ability to block non-existent domains.
> > If such ability is provided, the MTA filtering system MUST provide a
> >mechanism for overriding the filter rule for messages that are
> >acceptable
> >to the recipient organization."
> >
> >In short, the evaluation of whether manual tuning is worthwhile should
> >be
> >left to the discretion of the MTA operator, based on his organization's
> >risk tolerance and message characteristics.
>
> I think that it is well outside the scope of this document to impose such
> a requirement.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>