Sender-specific Policy: A firewall-in-training for email

Make a splitter to fork off deterrent behaviour with respect to:

• DKIM adherence
• SPF adherence (with extensions for passing through one or two forwarders)
• Avoiding ARPA2 Communication Access violations
• Avoiding ARPA2 Identity Signature errors (email framing, timing)
• Appearance in other parties' Errors-To: or From: headers

Basic idea: Have looseness sliders on each, ranging from 1 to 9, and move it up when a domain deters, or down when it does not. Fixate on 10 for rejection, which may be a user setting. Fixate on 0 as a user setting (and configure whether the slider can sink to that, thus fixating after behaviour). There can be an overall slider for a domain, but it is a hierarchy and sliders can be split up if this is desirable. For instance adding the domains of other parties, or adding IPs for acceptable forwarders.

Database size: This calss for a database of known-good domains. It might be seeded by outgoing traffic or approved incoming traffic, and would exclude never-seen-before domains, which subsequently fall prey to a default policy, while the actual traffic can be as tight or loose as desired. Databases would not need to capture spammer domains, not even for persistent ones, that would always be handled under a default. The default should be possibly captured at any level, so as to choose user handling and domain handling based on overlap of interest with peers.

Processing: These data structures are first tried for the sender user@domain.name, then for @domain.name and finally for @. so default. Such structures may be specifically defined by the recipient alias/user/group, recipient domain or apply as defaults for general use.

Splitting: The emails may be split into a spam stream and a business-as-usual stream. The spam stream would be lardered with reasons, with a callback URL where an override can be selected, and with enough information to allow automatic correction when spam is marked as non-spam by the user. When no spam stream is split off, then there are options of rejecting/bouncing the email with similar feedback.

Example Trusted Parties: Trusted parties such as payment services, postal services or tax office trigger phishing and spam. Their senders can usually be squashed with DKIM as well as SPF, in a less permissive manner than for plain email. The same reasoning interestingly also works to make exemptions that are more permissive. In general, variability in policy can be defined on an individual basis, to bypass tooling stringency.

Example Massive Provider: Massive provider domains may be more or less reliable depending on the sender. It is possible to weed out some users while fully subjecting others to greylisting, spam filtering and so on.