Re: [dmarc-ietf] Aggregate reporting options tag name 'ao'

Дилян Палаузов <dilyan.palauzov@aegee.org> Wed, 31 July 2019 15:29 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 2A20C1201E3 for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 08:29:47 -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, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, 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 CylcHGTMF4LI for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 08:29:44 -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 BA1D51202F5 for <dmarc@ietf.org>; Wed, 31 Jul 2019 08:29:39 -0700 (PDT)
Authentication-Results: mail.aegee.org/x6VFTYPP031006; auth=pass (PLAIN) smtp.auth=didopalauzov@aegee.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564586977; i=dkim+MSA-tls@aegee.org; r=y; bh=WIudU7nCe1rR4HIrv9BVF7453KW8lXEcTlIpnXp8MUc=; h=Date:In-Reply-To:References:Subject:To:From; b=CMHppFFbaEI7+fSSRK0C+HZ5P0wwIBFVIjlgb1vVznYZd1zivHRloup9Qc/Mj4i6+ VKJoMe3wa81/aceoTTkAGIax2gNBiMQ1EIjmAg/Ll66Kq3CpFkR7KmK4K6rvl2o5X6 ZJhqFAj7EX/b9cR2wmV3cMHvdWcsXxlD1zb22rT0uGGZtFmPinrihE5HoC5tLkQuEV TDjtq7k3xeWxlEN/naaltGQCN17oNkqedfGppNcOD9Vyugv+n751TK5qcKhXIAFsg8 gu2cgNdNdvuyWh9dyfDdbnCFBgO8O8DRn3easVmqREmO3vVFfMOxNZLd5WetHigI5p T74iQ3Jq638+H2KI19vYihf7KO/ZMYz/CVoAg2+2XOf/MIiPxWzsAK2deqsbfBMOyD S7iVvwTiWn7MMjAhBenUdPO1Eyq33J5OGK/TM2d0TEiqCpLi1q3YAp6YjiNmvY78Aq qOXkx9amrdlahgCcxnaNMIPMofn05y++gsOyBoLhznV0i2laEnRKzMxJ6P8wio/Lha O1ZSBUboi0MKLsS7nEYqj1dKgtGf5gA7DkefBTAXR8GDe5kK3CfklOVLwMRsdp+Wix tb1vfQM51n+0J/nn4Yt1Wd+xCc9mDTUITBRWVpUzw1OAcTuEj7YZn1vsorGMvmkE8G 0cr9e6SM7w/+3IxX1Gp6EKh8=
Authentication-Results: mail.aegee.org/x6VFTYPP031006; dkim=none
Received: from [10.43.253.208] (208.121.113.82.net.de.o2.com [82.113.121.208]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6VFTYPP031006 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Wed, 31 Jul 2019 15:29:36 GMT
Date: Wed, 31 Jul 2019 18:29:28 +0300
User-Agent: K-9 Mail for Android
In-Reply-To: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl>
References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----WZW52Z90RIN7X7ZVCFWPH93C3Q7FYB"
Content-Transfer-Encoding: 7bit
To: dmarc@ietf.org
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
Message-ID: <CDD3A436-976B-41E4-8A9A-B0C5577D98E0@aegee.org>
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/QURiMq2D-OGZTEaGXflz7jy-3rU>
Subject: Re: [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 15:29:47 -0000

Hello Freddie,

if a message has 5 DKIM-Signatures, some of them fail DKIM validation and some of them do not align, irrespective of validation status, you want to receive a report for the failed DKIM signatures.  The proposed option d is in the DKIM domain.  DMARC without alignment is DKIM or SPF.  To get a report for failed DKIM signature you put in the DKIM-Signature header r=y. After the mail passes over a mailing list, the signature is invalidated and you get a useless report.  Your intension is to limit the amount of useless reports, but this particular option goes in the opposite direction.

If you remove the SPF records and ensure that each leaving message is signed, you do not need the ao=1 option, as each report on failure will be about DKIM.

With ao=s whenever a mail is sent to an alias and redirected to another server, you will get a useless report.  I am not exactly sure, but I think SPF contained some reporting mechanisms, so this option might duplicate them.

Perhaps you want to propose a mechanism, that hides the successful deliveries (useless report) and only reports problematic cases?

Regards
  Дилян


On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman <freddie=40leemankuiper.nl@dmarc.ietf.org> wrote:
>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