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

"Freddie Leeman" <freddie@leemankuiper.nl> Thu, 08 August 2019 12:30 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 63EB9120046 for <dmarc@ietfa.amsl.com>; Thu, 8 Aug 2019 05:30:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 GZxXX7F7sxjY for <dmarc@ietfa.amsl.com>; Thu, 8 Aug 2019 05:30:54 -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 A351812001A for <dmarc@ietf.org>; Thu, 8 Aug 2019 05:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=leemankuiper.nl; s=mta1; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6SKRuRZKFkvNfZ4vH4NHlf2Y9BvVn2kfaEiGDkJC5sQ=; b=KqJIgBw7KJ0HoL1jSYfYMv+NM0 829NPb+P7FQ6FMqdJ8rjXZ5DiUSxkR+W26okSj3JP6IQ0USGnXGUS9ynYdsC3XjrlVsPIQSXsB0H7 JVBG8pVxPZh92BpG4PUJRIv7G2+8zP4UMGqbmWEL/kjhBo6d2NQWb8iQMqoWyaztyUUGhMPoD8Nr1 X3R1buZ/icFhW/ffD7R8Mmc6eitF2oR0DvuB7xkNWPRoxDhkasjXMvqzCrlxSzHTmI3kEHSnJC5Yk 5rkSkQVo+F/iGbPCWhzdOTmwW8lxLvLfk+9cNlkCC4uhxanZbhaMDYZTf4hI38wAAK552gjLSV3wa 9ve8JiMQ==;
Received: from 83-85-239-134.cable.dynamic.v4.ziggo.nl ([83.85.239.134] helo=LAPC01) by srv01.leeman-automatisering.nl with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.1) (envelope-from <freddie@leemankuiper.nl>) id 1hvhZE-0002Xb-L4; Thu, 08 Aug 2019 14:30:52 +0200
From: "Freddie Leeman" <freddie@leemankuiper.nl>
To: "'Alessandro Vesely'" <vesely@tana.it>, <dmarc@ietf.org>
References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> <CDD3A436-976B-41E4-8A9A-B0C5577D98E0@aegee.org> <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> <dfe8d0bec22e4ad0cd38871d08ac94ae1b1733fc.camel@aegee.org> <CAJ4XoYeY_Fx7Jk9jz93B3fOtP7YMspQz6C+9Jaf6Oeh6EZ8c2Q@mail.gmail.com> <018e01d54d35$2a603050$7f2090f0$@leemankuiper.nl> <f3ab594c-6670-d660-3e38-5a70fe51f570@tana.it>
In-Reply-To: <f3ab594c-6670-d660-3e38-5a70fe51f570@tana.it>
Date: Thu, 8 Aug 2019 14:30:51 +0200
Message-ID: <121801d54de5$1dfc4820$59f4d860$@leemankuiper.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJIu0T9j5Gm574QYreI9/dffuh59gHbOLplAhC8NysA7c3suQMM09lzAqL6vhAA/DW9h6WuI4vw
Content-Language: nl
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-Authenticated-Id: freeman
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/44PkBeewjVq2fmxXjh7UV0ZENvo>
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: Thu, 08 Aug 2019 12:30:59 -0000

Wait, you are right. I was talking about aggregate reports. But since the reports contains a single record per source IP this shouldn't be much data unless the domain has a huge range of (SPF allowed) sources. In case of a large scale abuse the messages would fail both DKIM and SPF and you want those reports, even if there are thousands. Thank you for clearing this up. I think we can put this threat to rest.

-----Oorspronkelijk bericht-----
Van: Alessandro Vesely [mailto:vesely@tana.it] 
Verzonden: donderdag 8 augustus 2019 12:35
Aan: dmarc@ietf.org
Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao'

No, wait a minute, what are we talking about?

I've re-browsed this thread, and various passages seem to be talking about failure reports.  The Network Error Logging is also similar  to failure reports inasmuch as they talk of logging each instance of a class of events, or a percentage thereof.  *Aggregate* reports arrive once a day, and millions of successful messages from a handful of IP addresses result in a handful of records, reported within a single message, along with any failures.  The bandwidth difference is negligible.  Multiply that by the number of mailbox providers, what is it?

I never experimented frequencies higher than once every 24 hours, neither for the ri= I set, nor for honoring requests —I run the process once a day.  Anyway, I reckon that sending more often increases the total amount of data sent, hence the bandwidth.  If it is problematic to receive all those reports, the protocol should specify a different sending strategy.  IMHO, that's not the case.


Best
Ale
-- 
















On Wed 07/Aug/2019 17:31:21 +0200 Freddie Leeman wrote:

> I agree that messages with both DKIM and SPF pass results can be useful when it comes to validating that everything is (still) in working order. But I come across domains with very high email volumes. So daily reports contain thousands of records that are consuming bandwidth, storage and processing power and in most cases aren't looked at (except for a count maybe). What could be the best of both worlds would be to add a ‘success_fraction’ tag that allows a domain owner to specify a fraction between 0 and 1 (1 being the default) just like https://www.w3.org/TR/network-error-logging/#the-success_fraction-member. I would still receive success reports but a 0.0001 fraction for instance. That will still allow me to detect fluctuation and changes while limiting the amount of records drastically. This would even allow domain owners to block success reports completely by setting a fraction of 0.
> 
> Your thoughts?
>  
> Van: Dotzero [mailto:dotzero@gmail.com]
> Verzonden: donderdag 1 augustus 2019 00:22
> Aan: Дилян Палаузов <dilyan.palauzov@aegee.org>;
> CC: Freddie Leeman <freddie@leemankuiper.nl>;; IETF DMARC WG 
> <dmarc@ietf.org>;
> Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao'
> 
> Having both passes and failures is incredibly useful. The percentage of failures is very useful. Any set of mail streams will always have some failures. Once you know what the baseline rate for a (sub)domain is, simply seeing changes in that rate will help you identify problems.. An increase in the failure rate is generally either 1) someone trying to abuse your domain name; or 2) something has gone wrong with DKIM signing or someone associated with the domain organization has started sending mail from somewhere without appropriate SPF or DKIM.
> 
> Michael Hammer
> 
> On Wed, Jul 31, 2019 at 5:24 PM Дилян Палаузов <dilyan.palauzov@aegee.org>; wrote:
> Hello Fredie,
> 
> DMARC limits the amount of servers that can generate emails for a particular domain.  The aggregate reports show to which extend DMARC does work correctly and when it fails for a domain.  The aggregate reports to not tell you how to fix your DKIM implementation, so that sender and receiver agree on the DKIM signature.  The per message failure reports tell you which messages were not signed correctly, so that you can check the DKIM implementation.
> 
> I thought some hours ago it could be useful to reduce the amount of reports, by not sending a report when things are 100% correct, but now I am not so sure.
> 
> The aggregate reports contain information, if something is not working correctly, but they also prove, if everything is running correctly.  If there is an option to reduce the reports to contain only information about failures, you don’t have a prove, that everything is working correctly.  Let’s say if you write a message to site S and don’t get an aggregate report back, this can mean, that DMARC passed, but it can also mean, that S does not evaluate DMARC or that DMARC failed and S does not send aggregate reports.  Is the lack of success-reports a prove of correctness or not?  I am inclined.
> 
> What do you want to do with the information about failures from the DMARC aggregate reports?
> 
> Regards
>   Дилян
> 
> On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote:
>> Hi Дилян,
>>  
>> Thanks for your input and feedback. Maybe a single tag, that allows the domain owner to avoid receiving aggregate reports for messages that align, would be enough? I personally have little experience with mailing lists which, I understand, can be a real pain when it comes to SPF/DKIM. So would a tag that instructs the receiving party to only send an aggregate report whenever the DMARC policies is applied be a better option?
>>  
>> Kind regards,
>> Freddie
>>  
>> Van: Дилян Палаузов [mailto:dilyan.palauzov@aegee.org]
>> Verzonden: woensdag 31 juli 2019 17:29
>> Aan: dmarc@ietf.org
>> Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao'
>>  
>> 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
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>