-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You can now stop staring at the weird acronym I created. New concepts need
snappy names in order to be successful in word-of-mouth propagation. It
worked for XML, LAMP, AJAX, and SPF, so there you are. Alternate sugges-
tions for a term are welcome, but for now, I'll use that.
TENBOX isn't an entirely new concept. Essentially it means a coherent
drive to implementing "forwarder white-listing" on various MTAs, MUAs, and
e-mail services (Pobox, Gmail, etc.). (Expanding your trusted e-mail
network's boundary to include your forwarders, which you do trust as an
e-mail receiver, is what "forwarder white-listing" is all about.)
The current "SRS for postfix" thread once again brought up the problem that
the real, elegant solution to SPF's so-called "forwarding problem", i.e.
forwarder white-listing, is difficult to implement. This thread was the
proverbial last straw that broke the camel's back and seriously got me
thinking about why it is so difficult to implement. Perhaps difficult on
a similar scale as SPF itself.
The reason is that it's not a single concept that could be implemented in a
Perl module on CPAN or a "libtenbox" C library. Rather the "forwarder
white-listing" concept spans a gap between various proximate concepts.
IOW, _glue_code_ needs to be written. And since there are _a_lot_ of
MTAs, MUAs, and e-mail services, _a_lot_of_ glue code needs to be written.
As a result, it won't happen all by itself. If we wait for that to
happen, we'll still be waiting in five years.
(Of course, that's not to say that path-based e-mail authentication such as
SPFv1 is the ultimate solution to sender address forgery and spoofing.
Other authentication methods such as PGP, S/MIME, or DKIM may well be more
powerful and suiting to the problem. But as long as we support path-based
authentication, we need to help the world implementing it _properly_.)
Of course the amount of work necessary will not decrease directly just
because we give the complex concept a fancy name. But it might make it
easier to convey the concept to the world and raise awareness among
potential glue code writers for all the e-mail software and systems out
there. And finally, a coordinated effort avoids duplicated work.
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.
References:
1. http://trusted-forwarder.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFE517bwL7PKlBZWjsRAkrNAKCzaAWjXkUE//hB1YVogkQbGs7mvACg+jdt
HCThE/qBtMJx4Ny7KC9ILhs=
=wiFz
-----END PGP SIGNATURE-----
-------
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