On Sat, Aug 19, 2006 at 06:56:26PM +0000, Julian Mehnle wrote:
So this is what TENBOX should, IMO, cover:
* A user must be able to define and store his trusted e-mail network
associations (specifically including his trusted forwarders),
and communicate them to his receiving agents. Ideally, the user
would configure these associations in his MUA, be it Outlook,
Mutt, or the Gmail web-mail interface. A specialized editor
could be substituted as long as it is able to interface with the
user's MUA. The information would then be communicated in a
_standardized_ way to the receiving agents. This might encompass
simply sending an e-mail message including the information in a
standardized format (perhaps a RFC2822- header-style, YAML, INI,
or even XML attachment).
* The receiver's agents must receive and store those associations. Of
course, authenticity needs to be established, either implicitly (when
there's a trusted channel between the user's MUA and the receiving
system, e.g. SMTP AUTH or on a web-mail system), or explicitly using a
cryptographic signature (PGP or S/MIME). Then the receiving agents
must act on that information, i.e. exempt trusted forwarders and other
members of the user's trusted e-mail network from SPF checks and
possibly _other_ rigorous abuse checks.
* Not only the transmission protocol of the trusted e-mail network
associations needs to be standardized, but also their semantics. I'd
really like to avoid specifying a whole new policy language at this
time, but at least the _fundamental_ semantics _have_ to be
standardized. If we can make it extensible for future purposes, all
the better.
In a way, this concept is exactly reciprocal to the trusted-forwarder.org
service[1], which is (and should be) rarely used (and for a reason --
trust is mostly individual and can hardly be centralized!).
All this stuff would have to be specified and then implemented for as many
MTAs, MUAs, and e-mail services as possible. Or we could forget about it
and let the "forwarding problem" go on as a de-facto argument against
SPFv1's path-based authentication concept.
Comments strongly anticipated.
This mirrors some of my recent thinking, except replace 'trusted e-mail
network associations' with 'trusted email identity associations' in
your first bullet. I'm also thinking that the focus needs to be on MUA
changes. I also think a new email identity needs to be created.
However, this identity is specific to the two parties who are
exchanging email.
Suggesting MUA changes is very ambitious, but if Goodmail was able to
convince AOL and Yahoo to make MUA changes on top of doing crypto
checks via Goodmail, I think it is more possible then ever.
--
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | jmacdonald(_at_)e-dialog(_dot_)com
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com
-------
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com