On Mon, 15 Jan 2007, Julian Mehnle wrote:
Search spf-discuss for "TENBOX" (just a funny acronym I made up to give the
problem a catchy name):
I've looked over those posts. Seems TENBOX is more ambitious than what
I've proposed, but even less fleshed out.
When attacking a large problem like the TENBOX requirements, it's always
good to Divide and Conquer. A good way to do this is to first simplify
the information that needs to pass from the forwarder to the recipient's
anti-spam configuration as much as possible. We could hope to reduce it
to a simple token, much like an e-mail address.
Then, we sunder the TENBOX requirements into two sub-specifications:
* TENBOX/E (E in authEntication) allows incoming forwarded mail to be
identified and associated with the forwarder's token in an efficient,
forgery-proof way.
* TENBOX/O (O in authOrization) deals with the problem of getting a list
of forwarder-tokens to trust into a non-technical recipient's MTA, while
keeping spammers-who-pretend-to-forward out.
My proposal, of course, already fulfills TENBOX/E.
As for TENBOX/O, the way I'd do it is introduce a second ESMTP extension
that allows a "Request whitelisting" command, with three arguments:
* The recipient to whom access is requested
* The token that will be used for the whitelisted mail
* An address to send a notification message once the recipient has
decided to accept or deny the request.
One implementation approach would be for the MTA to then synthesize an
e-mail similar to the "confirmed opt-in" of a mailing list, and send it to
the recipient. The recipient's reply would go direct to a "robot" address
at his ISP (the actual whitelist-requester would never see it.). When the
robot recieves the reply, it would first adjust the whitelist, and then
send a message to the notification address. This would be compatible to
all MUAs.
But a TENBOX/O implementor whose users all use one MUA (such as in
webmail), could instead take the process out of band, popping up a
"So-and-so wants you to whitelist them" dialog.
An ISP could also provide a "control panel", where a user can manually
enter TENBOX tokens to trust, and then disable notification of whitelist
requests. In this case, the whitelist request command would only tell
the requester whether he was already in the whitelist or not.
---- 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
subscription,
please go to http://v2.listbox.com/member/?list_id=735