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

[Alessandro Vesely <[e-mail]>]

On Fri 25/Oct/2019 02:53:32 +0200 Brandon Long wrote:
> On Thu, Oct 24, 2019 at 10:55 AM Alessandro Vesely wrote:
>>
>> 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.

The spam score is a rather common concept.  Of course, an MTA which does not
implement any such thing would omit this field.


> Also, it's a lot of spamminess feedback, not sure if that can be abused or
> not.

Correct.  However, it is an average, so a spammer would have a hard time trying
to work out the detail of how the receiver's score is computed.  Again, a
reporter may compute the std deviation along with the average and omit this
field if all messages have equal score.

OTOH, this is indeed a valuable feedback.  Mail sites could build their own
reputation system based on that.  A community IP database.  Revolutionary,
isn't it?


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

Perhaps we could add a second count.  Or break the record into two rows.


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


Ah, that way we'd get rid of all those "on behalf of"... :-)


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


Exactly.


> they can just as easily use the various public IP reputation sources.

Yes, could do, but it's more difficult.  Here the reporting MTA already has the
datum, and can include it for free.

This datum would be vouched by the reporting MTA.  It can be internal, like a
fail2ban database.  How about also reporting the source, if external?


> Anyways, I doubt we'd expose anything internally...


I always wonder why Google doesn't publish their internal IP database.


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

The aim is to be able to look at an aggregate report and understand it.  For
example, if people can tell an IP is blackish, they'd just smile and be happy
for a good failure case.  What field would you suggest instead?


Best
Ale
--