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

[Brandon Long <[e-mail]>]

On Thu, Oct 24, 2019 at 10:55 AM Alessandro Vesely <[e-mail]> 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).
>

This assumes that your spam system is able to make a spamminess score that
approximates
a continuum, I'm not sure that's true.  Also, it's a lot of spamminess
feedback, not sure if that
can be abused or not.

Also, as rejected at smtp time, especially for DMARC, we're unlikely to
have run a full spam
assessment on the message.


> *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.
>

At first I was wondering if you were going to have the values of the
list-id header.

That said, though I've never used any DMARC aggregator services, I would
think that
one of the values they're likely to provide is IP address identification,
useful so you can
hunt down what things aren't sending DMARC compliant email yet (ie, looks
like you're sending
mail from ESP A and ESP B, fix those)... they can just as easily use the
various public IP reputation
sources.

Anyways, I doubt we'd expose anything internally... also, this is kind of
the opposite of the
spamminess score, in that it expects that things are black & white, and we
virtually never
classify things as such.

Brandon