Re: [dmarc-ietf] Two new fields in aggregate reports

[Дилян Палаузов <[e-mail]>]

Hello Alessandro,

I do not see how this helps for DMARC.  An email either validates DMARC, or fails DMARC and the aggregate repors say per
sending IP server (only direct mail flow is reported), whether DMARC validates or fails.  With this information it is
sufficient to determine, if the DMARC/DKIM implementations on sender and receiver are either both bug-free,  or both
have the same bugs.

I do not see, how the information you ask to add, while interesting, does help DMARC.

What is the purposes of the aggregate and non-aggregate reports?  What are non-goals?  I asked several times here,
nobody answered.  Perhaps a discussion on the goals and non-goal would help.

If it is a goal to reuse the dmarc-reporting mechanism to report also about perceived spam probability, then it can be
discussed in more details how this can be achieved.  My experience is, that asking a provider, why an obviously non-spam 
mail was evaluated as spam, virtually never leads to a useful answer.  So nobody wants to reveal how its spam system
weigths factors and if there is lack of such interest, extending the report format will not help, as nobody will be
willing the report the data.

Exchanging information on hard-coded rules in Spam-Assassing (IP reputation, HTML mime part without text/plain, the
“Nigeria money” phrase), that is not based on filter training, does not help neither, as sender can run the tests on its
own and predict how the recipient will evaluate these set of criteria.

Regards
 Дилян

On Thu, 2019-10-24 at 19:53 +0200, Alessandro Vesely wrote:
> Hi all,
> 
> it is difficult to tell what is each aggregate report's record.  It is easier
> if the source IP is known.  Mailing lists can be told by their (unaligned) SPF
> domain.  Otherwise, it is difficult to tell abuse from legitimate users using
> the wrong server.
> 
> Getting a failure report for each source IP is not easy, because few mailbox
> providers send failure reports.
> 
> In order to ease the understanding of aggregate reports, I propose two
> additional per-record fields:
> 
> 
> *score*:  The average score of the messages in the row; let's say an SA-like
> number (< 0 good, > 10 bad, values in between may be worth human inspection).
> 
> *list*:  An enumerated type, for example "none", "black", "white", "both",
> indicating if the source IP is listed in some public or private DNSxL that the
> reporting MTA uses.
> 
> 
> They're obviously subjective stuff.  However, most MTAs deploy at least one of
> them, and summing up per-IP results every day can bring useful indications.
> 
> I haven't added those fields to http://bit.ly/dmarc-rpt-schema, yet.  Let's
> discuss.  I hope they will make it to rfc7489bis.
> 
> 
> Best
> Ale