I've thought of a better may to state my case for a
forwarder-whitelisting extension, so here's a "reboot" of the "Better way
The central problem for a forwarder in this modern internet is that he
is, effectively, a border MX for the recipient, but usually he is not
treated as one by the actual MXes. Thus, he can get saddled with
responsibility for backscatter, and can wind up getting his IP reputation
blackened when he forwards spam. Basically, the forwarding system as a
whole is sick in precisely the same way that a mailsystem with a lax
backup MX and a content-filtering primary MX (which doesn't exempt the
backup) is sick.
If I were the forwarder, I would insist that this problem has *one
acceptable solution* -- the recipient must super-whitelist me, giving my
MTA the same rights as a backup MX. Namely, the mail must go straight
through no matter how spammy it may look.
From this outlook, the blockage that results when traditional forwarding
meets SPF is a blessing in disguise. By blocking good mail, it causes as
much grief to the recipient as it does to the forwarder, putting pressure
on the recipient to *get off his ass and do the whitelisting*.
Since SRS dissipates this pressure on the recipient while still leaving
the forwarder with the bulk of his problems, from the forwarder's point of
view SRS is a step backward. It's throwing away the leverage to demand
whitelisting that SPF gifted him with.
Now, whitelisting a forwarder is technically difficult at present. So
rather than do whitelistings, recipients largely choose to put off the
problem by simply not deploying receiverside SPF. This situation is
neither good for the forwarder (*still* no whitelisting) nor good for the
recipient (can't use SPF).
So an extension to make forwarder whitelisting as easy as sender
whitelisting would be a good idea. While it must be deployed at both
recipient and forwarder, both sides have an incentive to take it up.
Unlike SRS, where while the recipient doesn't need to do anything, the
forwarder who does has a negative incentive.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
please go to http://v2.listbox.com/member/?list_id=735