IETF Logo Mail Archive

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

Alessandro Vesely <vesely@tana.it> Wed, 16 June 2021 11:34 UTC

Return-Path: <vesely@tana.it>
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 41A883A129D for <dmarc@ietfa.amsl.com>; Wed, 16 Jun 2021 04:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 VOpJKEB5Cq09 for <dmarc@ietfa.amsl.com>; Wed, 16 Jun 2021 04:33:59 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 6B89E3A1295 for <dmarc@ietf.org>; Wed, 16 Jun 2021 04:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1623843234; bh=nfHaKFUm0jgg10hEvG/oBuK+bud9J0WJ8XGYJILfnVA=; l=1044; h=To:References:From:Date:In-Reply-To; b=BgXH6XXVUlnGhIWwuERc17CzFdJYB0jWM70B8dqPp265ZLFkBJ2LnekHP0goxMvoD ZcJMMXMqnenvIbETDczQgfiKz2nnO1Fey1RZUlupbH3DOcIy5qtxVYB7j8AJg5hHYd Y/EqylTeM8iKnedOI9HkKdarwhDpWrPiRHcs/Bv7kdt2vopvQ4ny9maFl5vCt
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC03D.0000000060C9E1A2.0000478A; Wed, 16 Jun 2021 13:33:54 +0200
To: Douglas Foster <dougfoster.emailstandards@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
References: <CAH48ZfzuM298fkmhoZtH1ZbK=9Ne9EYtyTYNV27PSsPBW=Gq-w@mail.gmail.com> <1a666b47-d556-e758-f4ce-05de79c449d1@tana.it> <CAH48ZfxxUjvfHsd0QKwXbOqZLyeqhVmzORPekJBoPcwAb8tiiA@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <05352758-3a50-2ba1-e6a9-f31174a32bc4@tana.it>
Date: Wed, 16 Jun 2021 13:33:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CAH48ZfxxUjvfHsd0QKwXbOqZLyeqhVmzORPekJBoPcwAb8tiiA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/N0wvLYfnpgAWP-XVs5YyrkBXpYE>
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: Wed, 16 Jun 2021 11:34:04 -0000

On Tue 15/Jun/2021 01:19:03 +0200 Douglas Foster wrote:
> 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.


Me too.  I reviewed my logs for 2021 and got this:

88 NXDOMAIN found out of 160,473 messages:
35 bounces (empty mailfrom),
26 not found host in an existing suffix,
27 totally astray.

Except for bounces, which just reflect a poorly configured server, I wouldn't 
swear to their legitimacy.  For the few samples of which I still have the 
score, it was high.

However, to reject based just on NXDOMAIN is too harsh.


> This situation means that we cannot distinguish between valid and invalid
> email suffixes using DNS alone, we must require domain owner signalling.

I'd agree, but the idea of suggesting to signal such lack of registration over 
the DNS is to diabolically persist on an error.


Best
Ale
--

v2.23.0 | Report a Bug | By Email