boundary filter

A boundary filter is a mail filter that is preferably operated at the boundary between the originating and the receiving networks.

DNSBL

DNS Block Lists are IP addresses of known spammers or compromised machines. Looking up the remote IP of an incoming SMTP connection is commonly used for avoiding a good percentage of spam. Obviously, this operation has to be done at the boundary. Otherwise, only the last forwarder's IP address can be checked.

Some users don't want their mail to be filtered against some or all DNSBL, though. They possibly counter spam by avoiding to publish their email address. A server may accomplish such kind of request by setting an environment flag in case the remote IP is blacklisted, then check user's preferences on each RCPT command. When this can be done, the negotiation of a forwarding agreement should include a list of available DNSBL, letting the target host choose on behalf of the user which of them should be enabled or disabled. This option makes more sense for single-recipient forwarding recipes than for, say, mailing lists.

A completely different requirement is that the receiver whitelists the forwarder itself, in case the latter gets blacklisted. A receiver should only grant such a privilege to hosts that have been thoroughly identified, e.g. gathering trusted administrative and technical contacts during the handshake.

SPF

Sender Policy Framework checks must be done at the boundary. Blocking forged addresses appeared a good idea in 2003. However, some argue that SPF breaks forwarding; other counter-argue that forwarding is broken since RFC 1123.

Requiring that the forwarder carries out SPF checks, adds Received-SPF headers, and rejects messages that fail the SPF authorization, is expected to be a typical requirement of the forwarding agreement negotiation.

Negotiating a forwarding agreement may set the non-disclosure flag in the corresponding forwarding recipe under certain circumstances. In that case, the forwarder must set the envelope sender to null or to a bounce address provided by the target host. For all other cases, there is no need to use SRS or any other sender replacement, since the forwarder is exempted from SPF checks under the agreement.

N.B.: Relationship with SPF

Besides historical considerations, SPF happens to address the question "who may legally use a domain name?" That is strictly related with the privacy question "who may legally use my email address?" The latter is the main concern of the solution proposed.

Other filters

Anti-virus, DKIM, S/MIME, and other forms of authentication or authorization can be performed anywhere along the path. Running them sooner rather than later is trading bandwidth for CPU cycles. FixForwarding doesn't prescribe any particular behavior for these filters, encouraging hosts to run them as they routinely do. However, the negotiation stage may provide for exchanging a path for reporting message-specific or statistical information related to these filters, e.g. a feedback loop.