Email source data in reports

[ShawnPConroy]

When going over email reports, it would be very helpful to have additional data from the failing record to help be able to dismiss non-issues. Sources should be divided between not aligned, partially aligned and fully aligned, and shown in that order.

For fully aligned sources, include the identifier domain from email_header if present. If not, I doubt it fully aligned. But take any other header_from, envelope_from etc.

For partially aligned sources, and not aligned sources, including the domains listed in the identifiers, DKIM and SPF would be useful:

Identifiers: email_header, header_from, envelope_from, envelope_to
DKIM auth: domain+selector
SPF auth: domain+selector

It's simple to just list each on its own line. It's cleaner to remove duplicates. And except for the selectors, any time the domain matches the FQDN I guess that could be ignored, as it's a given.

This can either be a new Identifiers column next to the source IP, or included below and change the column name to source. No need for a new column for each data item.

---

For example, I get a lot of email spoofing my domains from one website. It would be nice to know at a glance, oh that rejected email was from website spoof1. Good. Or, oh, that rejected or quarantined email was from sender1, sender2, or sender3, that's an issue that needs resolving. Oh, partial aligned from sender4? That's expected behaviour.

domain+selector is useful for newsletter and marketing emails that have a DKIM or SPF setup with the selector as part of the DNS record name.

[liuch]

If we're talking about Summary report, I'm afraid such changes will be excessive, otherwise such a report will no longer be a “summary”. After all, nothing prevent a spammer from sending thousands of mails with different headers and selectors. I actually wanted to add an option to limit the number of IP addresses (sources) to the report, so as not to clutter it up.

I have plans to add an IP address "reference book" where you can keep IP addresses or subnets that you know of to name them. This could be used to group sources in the report. Nevertheless, I liked some of your ideas. I'll consider them.