#105 closed enhancement (out-of-scope)

An additional type of forensic reports?

Reported by: dougfoster.emailstandards@… Owned by:
Priority: minor Milestone: Deliverable #2 (DMARC improvements to better support indirect email flows)
Component: dmarc-bis Version:
Severity: - Keywords:
Cc:

Description

Suppose I detect spam from an otherwise legitimate source, such as a gmail.com mailbox that has been compromised, or an ESP client account that is sending messages with malicious links.

Would it be desirable to define a type of forensic report that says, "Hey Google, I know you have a hard time keeping tabs on a 1000 million mailboxes, so I wanted to let you know that I think this one is being misused."

Surprisingly, this problem seems rare with gmail. But I certainly need a better way to send complaints to certain ESPs about the volume of criminal content coming from them.

In both cases, the reporting should go to the server domain rather than either the SMTP address domain or the From address domain. The DNS domain would need to be forward-confirmed to the Source IP, and the reporting destination would have to be published in the DNS for the server domain.

Known obstacles:

1) These reports would have the same potential for privacy concerns as the existing forensic reports The concern is partly mitigated because the feedback is being sent to the source. Additionally, because the feedback is going to the source, the content could be redacted and summarized.

I would suggest that the report could be limited to four attributes: SMTP domain, From Domain, message ID, and timestamp. For systems that keep an audit trail of outbound messages, this data should be usable as a primary key to retrieve the message from local logs without risking privacy violations within the report itself.

2) These reports would have the same rate-limiting concerns as other feedback. A compromised account could quickly send a lot of messages to a lot of domains, and the feedback could be overwhelming if every spam message produce a feedback message.

3) These reports would be subject to false positives, since "this account is behaving badly" is very much subject to the opinion of the system making the interpretation. Classification errors by a single anti-virus product could create a flood of false positives from all users of that product.

Despite all of those obstacles, would any of the large mailbox providers or ESPs find this of interest?

Change History (2)

comment:1 Changed 22 months ago by alex_brotman@…

This is out of the scope of DMARC. We have FBL/ARF/X-ARF reports and other mechanisms (i.e.,RFC8600) for exchanging information between entities. While I understand the concern, if this is truly a goal, it should create its own RFC and spec.

Last edited 22 months ago by alex_brotman@… (previous) (diff)

comment:2 Changed 21 months ago by todd.herr@…

  • Resolution set to out-of-scope
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.