[dmarc-ietf] Aggregate reporting options tag name 'ao'
"Freddie Leeman" <freddie@leemankuiper.nl> Wed, 31 July 2019 14:58 UTC
Return-Path: <freddie@leemankuiper.nl>
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 A8AA312004F for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 07:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leemankuiper.nl
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 7Tb23NifMfap for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 07:58:20 -0700 (PDT)
Received: from srv01.leeman-automatisering.nl (srv01.leeman-automatisering.nl [87.239.9.190]) (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 6C221120170 for <dmarc@ietf.org>; Wed, 31 Jul 2019 07:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=N9/BNmAv86ZBQxDGc+4QpnzibJu9HsvIu1oXnJLHhiE=; b=RZRei6r2hcQt603YYVX2btg/+4 SVTp2KKxmi39QHJ7RxRF09l05l1mPfUyoQuNobxazXlWruDuhACK+qhlwP56rd+JT/P3Rvn7P95Vp ChljkSgPCcRcUyLjVh5I6mAql31j2A2Ap6tJe+TKx92wiWyGyRTwy1S0lW5L+v3K4E23b23WbEKZa buErlCA9zbfWixnD9W9yY2sKrthlkz3GAX5eccYrO+xiVT0f1o+G6RFZq4dQ4cQIY4ZykCZx0BQF8 dsv3v6xf1icsAA2tVEJjUd+4jcqXLEtuj2qQbMsY4+nw78j27Vn/lo0FTtbz9L6f1NLJ/w63eiXA5 /Ez3T+Qg==;
Received: from 83-83-140-171.cable.dynamic.v4.ziggo.nl ([83.83.140.171] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <freddie@leemankuiper.nl>) id 1hsq3W-0005xm-1Q for dmarc@ietf.org; Wed, 31 Jul 2019 16:58:18 +0200
From: Freddie Leeman <freddie@leemankuiper.nl>
To: dmarc@ietf.org
Date: Wed, 31 Jul 2019 16:58:18 +0200
Message-ID: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0101_01D547C1.27454910"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdVHqrg4GLMYKDGbSvOvMop+gTZZAQ==
Content-Language: nl
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-Authenticated-Id: info@leemankuiper.nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/tkAFIj-V9fbprhG7u6pcUyyHxjg>
Subject: [dmarc-ietf] Aggregate reporting options tag name 'ao'
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, 31 Jul 2019 14:58:24 -0000
Would it be useful to add an 'ao' tag name for aggregate reporting options? Something like: ao: Aggregate reporting options (plain-text; OPTIONAL; default is "0"). Provides requested options for generation of aggregate reports. This tag's content MUST be ignored if a "rua" tag is not specified. The value of this tag is a colon-separated list of characters that indicate aggregate reporting options as follows: 0: Generate a DMARC aggregate report for every message, regardless of its alignment. 1: Generate a DMARC aggregate report if any underlying authentication mechanism produced something other than an aligned "pass" result. d: Generate a DMARC aggregate report if the message had a signature that failed evaluation, regardless of its alignment. s: Generate a DMARC aggregate report if the message failed SPF evaluation, regardless of its alignment. This would allow domain owners to save on tons of reports to be handled and processing that are useless in most scenarios. For instance, when I've deployed my SPF/DKIM/DMARC policy and I'm pleased with my policie's results, I would still want to use the reporting to detect and fix changes in my email environment. If a million mails a day are nicely processed with DKIM and SPF aligned, I do not need those entries in my aggregate reports. I'm only interested in the reports where either DKIM or SPF fails. In most scenario's this will cut data transfer and report processing with more than 99 percent. Whenever there is a bump in the number of reports received, I can detect that something is wrong and I might need to add a host to my SPF policy or need to fix my DKIM signing. I was amazed that these options weren't in the current RFC, as these do exist for failure reports. Am I missing something? Is there a reason why this would be a bad idea? Kind regards, Freddie
- [dmarc-ietf] Aggregate reporting options tag name… Freddie Leeman
- Re: [dmarc-ietf] Aggregate reporting options tag … Дилян Палаузов
- Re: [dmarc-ietf] Aggregate reporting options tag … Freddie Leeman
- Re: [dmarc-ietf] Aggregate reporting options tag … Дилян Палаузов
- Re: [dmarc-ietf] Aggregate reporting options tag … Dotzero
- Re: [dmarc-ietf] Aggregate reporting options tag … Murray S. Kucherawy
- Re: [dmarc-ietf] Aggregate reporting options tag … Freddie Leeman
- Re: [dmarc-ietf] Aggregate reporting options tag … Alessandro Vesely
- Re: [dmarc-ietf] Aggregate reporting options tag … Freddie Leeman