Michael Deutschmann wrote on Sunday, January 28, 2007 3:34 PM -0600:
That reminds me -- you never responded to my suggestion that the
TENBOX requirements should be split into two. There should be a
TENBOX Authentication protocol that forwarders to mark their
forwards with a forgery-proof token the recipient can whitelist,
and a TENBOX Authorization protocol that allows a forwarder to
request whitelisting from the recipient MTA with no more enduser
involvement than subscribing to a mailing list.
An interesting way to facilitate whitelisting. Unless you're proposing
a new ESMTP extension or putting this information into the headers, this
means changing the return-path and that will likely end up similar to
SRS. In that case, there's no need for whitelisting. There's nothing
stopping any forwarder today from implementing their own private flavor
of SRS to accomplish that. As long as you use the forwarding domain
name in the return-path and somehow give yourself the ability to route
DSN's to the original recipient, you've accomplished the goal.
Forwarder whitelisting is another matter, as it suggests the forwarding
domain is immune to spam complaints, and that's a much higher level of
trust. I don't see a great deal of motivation for large recipient
systems, who will often be the target of forwards, to whitelist such
mail and then deal with spam complaints for messages they wouldn't have
accepted themselves. Forwarders can correctly say their users
_required_ them to forward all received messages, except the users
didn't like the result and then complained to the target domain. End
users don't understand that the majority of spam is blocked due to the
identity of the source, not the content, so the target system looks like
the right place to complain.
--
Seth Goodman
-------
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
subscription,
please go to http://v2.listbox.com/member/?list_id=735