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

Dotzero <dotzero@gmail.com> Wed, 31 July 2019 22:22 UTC

Return-Path: <dotzero@gmail.com>
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 1008A120089 for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 15:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cWaVRtwYvX56 for <dmarc@ietfa.amsl.com>; Wed, 31 Jul 2019 15:22:40 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDDC120046 for <dmarc@ietf.org>; Wed, 31 Jul 2019 15:22:40 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id p17so71349665wrf.11 for <dmarc@ietf.org>; Wed, 31 Jul 2019 15:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OROM3Ae9kZE7Th09J14z7aXDyixcVTV2P4BtMh7K3+U=; b=Af1TyteggSo7L49Mp56F5CucIZITFc/dO045Ek5BHivYLNp0jZS9BwPucV3zSqbS8K Aml666Uon6JHgSh8ukY/Y2NzYpP8KA5+uWVU08Z8MKme8CBKRnDpOTPA1HkLkK00UOhK GpJtQDMdoVfaXCxf9GeC+v1UY5xAElOrx9j1Dg7kmkYBKY/Bph3BZbJSA5TM2eDtipuj C4N4VHpxHxaIzRgMX6uZwSp4GrF0kBRffkhHlzg2QvGC0mBU5RGNjvAwMvygK/7qPNd3 6FnCseXfxTfdxNxOuruNk2FGN0+HnhMW5TelWzQoLzgEzHuNM+DvOe2A1ML8KA2QGIpF CgPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OROM3Ae9kZE7Th09J14z7aXDyixcVTV2P4BtMh7K3+U=; b=S5QG7FZ9waDAdmN2bMcb9tIEunRw9ub/BPVOMRBIwEUcztB64mNgIetgJuIasUHcX7 Bc7uQf3eXhz6mDW9eGZXFSen5UmDRBhrgsy1S9ktDphBtvxLHGGrAfyzqU2pwinvkbmY 6KzMdvtxqStjKZqkCXUCVQhbDbpsPL1MIlSNR5pz5Q31uMrJ8E4K5QN2LvfrrbYEjoSc lETN81EYg3dBU1WPvCezuL8Ff0BSCzeOA1+n8tziY2sqGYpwxOp1A9nA6CYFFd5rGR5Q f0RXoWbAoJ6+VkUOyXINjirMYWKVApQfI09zNISgqQmChO5jOqPYGtEaoYEPAC1Mhnrv AsrA==
X-Gm-Message-State: APjAAAVhjHzW5okRx9gvLPt96HwLpvqlsYiVmNSmgkFbRMXgXXYbA2hW NeCA+KUrU+lVUSWSsOw5lWhcuV45t+Hpu89fbOo=
X-Google-Smtp-Source: APXvYqzBO12Nb2kXyZlEoKNQxM2XLywRPyAX9aDiL1f1rhKxFwqtCfEWVYV4ZYR2/GpfsDmMderPB8HLJWJ9z3dA0VM=
X-Received: by 2002:a5d:4484:: with SMTP id j4mr136207823wrq.143.1564611758904; Wed, 31 Jul 2019 15:22:38 -0700 (PDT)
MIME-Version: 1.0
References: <010001d547b0$63bbdcd0$2b339670$@leemankuiper.nl> <CDD3A436-976B-41E4-8A9A-B0C5577D98E0@aegee.org> <016e01d547c5$d4e451c0$7eacf540$@leemankuiper.nl> <dfe8d0bec22e4ad0cd38871d08ac94ae1b1733fc.camel@aegee.org>
In-Reply-To: <dfe8d0bec22e4ad0cd38871d08ac94ae1b1733fc.camel@aegee.org>
From: Dotzero <dotzero@gmail.com>
Date: Wed, 31 Jul 2019 18:22:29 -0400
Message-ID: <CAJ4XoYeY_Fx7Jk9jz93B3fOtP7YMspQz6C+9Jaf6Oeh6EZ8c2Q@mail.gmail.com>
To: Дилян Палаузов <dilyan.palauzov@aegee.org>
Cc: Freddie Leeman <freddie=40leemankuiper.nl@dmarc.ietf.org>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019dbfd058f0190b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/8bPQ57IzWxFFN65RjZ7hBrP2ojw>
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 22:22:44 -0000

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
>