[dmarc-ietf] DMARC and Redirecting Messages

Дилян Палаузов <dilyan.palauzov@aegee.org> Fri, 02 August 2019 16:24 UTC

Return-Path: <dilyan.palauzov@aegee.org>
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 0C19412016E for <dmarc@ietfa.amsl.com>; Fri, 2 Aug 2019 09:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
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 0RUTcbBZYt0t for <dmarc@ietfa.amsl.com>; Fri, 2 Aug 2019 09:24:47 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 DF64712015E for <dmarc@ietf.org>; Fri, 2 Aug 2019 09:24:46 -0700 (PDT)
Authentication-Results: mail.aegee.org/x72GOhkr029799; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564763084; i=dkim+MSA-tls@aegee.org; r=y; bh=L5RJaWiPCw1MJKUzxo2pyzOorQf33TViYpSdHcTqIww=; h=Subject:From:To:Date; b=noYEmbGwd3Bo81BJ8Zt90vafMnDt85W3YeYe1JDT6lDiLJNbOiD7LKJjaMFijXh+7 D3B6AHKUGzMrXzgJszUIhovhSJn8TLpA/G6e4V0INGmCm71BrEKZ3KG23CqMAocXwz U8M/xs2j6PKl/3GnB9X2syM+heevbZRwEEYRCvvpc+nHBTrzMv3z5SApVQzAk8UhLy PFUYhNK1uZnr0mqru0zV9DaJUlGBqtdeAmwYMv+o2nWCqCfPaAdFVKjqohG13yatml AYJBzMgC5cZxPyTP4QiM1KRlV+c/Oi9EObWPYlsqeHewxP0KA3DKRQruWv5Mmacm0L S7bInJuW3BCoFzmryOY3vKzAqS58P9hKoAaFpCHxYK0NEDHtDj5gZZHoNgpOF2abi4 xvNJaYdHZ44hPWjNlYWeDkF0Ez0YXSju95QYVh8/NEcr64v0g9Xq7aepk6tptJwkxP OVDmGP1p4M1A7bwUucqZ4rCoJUFezpj18zodLIncIk7PDY1W+XhrBYPUxJ4l+ReLjI Urgz28qg6hER7OEFrt/ArJbe+1AW+A3BxjoHw+qdxAALFv6AC6z01qZOqcJJWKNUzq m5EY/YFdECcKhtVo7ZlhHOix5uFMne+LcnhzUVmxgLc19tIJlz6kNkX8OFs9qpds/g Sl2PFubwTZ1/2DdL+a25JPZw=
Authentication-Results: mail.aegee.org/x72GOhkr029799; dkim=none
Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x72GOhkr029799 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Fri, 2 Aug 2019 16:24:44 GMT
Message-ID: <e86f384b3892cac2f41d68761f82ee51541d5870.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: dmarc <dmarc@ietf.org>
Date: Fri, 02 Aug 2019 16:24:43 +0000
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.33.90
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1pM8SK0sQTagSd5p4aK8ROfeSbk>
Subject: [dmarc-ietf] DMARC and Redirecting Messages
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, 02 Aug 2019 16:24:49 -0000

Hello,

current text in https://tools.ietf.org/html/rfc7489#section-6 (DMARC Policy):

   Since email streams can
   be complicated (due to forwarding, existing RFC5322.From
   domain-spoofing services, etc.), Mail Receivers MAY deviate from a
   Domain Owner's published policy during message processing [... and SHOULD
   make available the fact of and reason for the deviation to the Domain
   Owner via feedback reporting, specifically using the "PolicyOverride"
   feature of the aggregate report (see Section 7.2).]

I propose this amendment to the first part of the sentance, (writen in a more abstract way, where the receiving site
decides on the policy.  The wording is subject to further adjustments):

* * * DMARC and Redirecting Messages

For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the
policy is 100 the recommendation is not to redirect the message but reject it at SMTP level.  The rationale is, that
this message might be evaluated by the next hop site as Spam, while this hop does not consider the message as spam.  In
turn, the next hop can conclude, that this hop is sending spam.  If the next hop decides to apply DMARC policy reject
for the domain of the message, this hop will have to generate a bounce for the message, risking to be blacklisted by
some backscatters IP reputation lists.

For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the
policy is between 1 and 99, the recommendation is to reject the message at SMTP level and not forward it further.  For
redirected messages, the PCT sampling is applied at least twice, thus there is a probabily that the next hop rejects the
message based on the PCT parameter, even if this hop has calculated not to reject the message.

It is in unknown, whether the next hop will reject or quarantine messages failing DMARC validation and from the sender's
perspective there is no difference, whether this hop or the next hop will reject the message.

The recommendations above do not fully apply, when the current hop changes the From: address, as if the recipient on the
next hop were a mailing list with one recipient, doing From: mungling.

It is not recommended to tell the sender that the message was delivered in the Junk folder of the recipient, and to
forward the message further, as the sender can get two rejections for the same message, from two different hops, which
is confusing.  This can happen, even if the From: address is mungled.