-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Deutschmann wrote:
On Sat, 27 Jan 2007, Julian Mehnle wrote:
That's essentially what the lame "TENBOX" catchphrase is about. (Can
we find another term? In any case I think we do need one.)
That reminds me -- you never responded to my suggestion that the TENBOX
requirements should be split into two.
(That's because I seem to have missed it. Can you point me to the message
where you originally made that suggestion?)
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.
When you say "mark forwards with a forgery-proof token the recipient can
whitelist", do you really mean some kind of mark that gets applied to
every message during forwarding? I don't think that would fly. If it
flied, we'd have a solution equivalent to DKIM or PGP. That could work
but would be significantly more effort than simply semi-statically white-
listing forwarders by their IP addresses.
Perhaps a prototype implementation is in order...
If you want new acronyms, how about:
FAR - Forwarding Agent Recognition
for the authentication protocol, and
FAME - Forwarder Authorization Made Easy
for the authorization end.
About choosing new acronyms... I think we should stay with "TENBOX" during
the concept phase, as that's the term under which related discussion can
be found in the mailing list archives. But it is not a good term for a
technical/pubilicity "end product". We need a new term (or terms) for
that.
One other idea that has been buried in RFCs 821 and 2821 largely
unnoticed is the HTTP-redirection-like "551 User not local; please try
<joe(_at_)example(_dot_) org>"-style "forwarding" (Frank mentioned it
before). I
think this would be _the_ solution if only more MTAs supported it. If
we want to work on
Problem is that most uses of forwarding are accounted by:
[see enumeration of cases below]
In all these cases, disclosure of the direct address to all and sundry,
which is what 551 implies, would defeat the whole purpose of the
forwarding.
There are still cases where redirection-style "forwarding" is acceptable.
For those cases, redirection forwarding is a simple solution. For all the
other cases, alias forwarding simply won't cut it without forwarder
white-listing.
* People who want to send and recieve mail under a pseudonym.
Legitimate case.
* People who don't expect much of the spam defenses at their real
address, so they use a forwarding service with better defences as their
only world-visible address.
Legitimate case, but also a textbook example of when the receiver should
consider the forwarder to be part of their e-mail infrastructure (and thus
white-list the forwarder from SPF and perhaps most other checks).
* People who are using mail aliases as canary traps to detect misuse of
e-mails collected by businesses.
You don't have to use a forwarding service to set up disposable addresses.
(Of course your immediate ESP may not support it, but that's not a
_fundamental_ problem that requires a forwarding service.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFvSNvwL7PKlBZWjsRAkqbAJ9suUeJAQc3YAkW8toB/xMuetKfQwCgigpo
pOBCzOzsI4ovGPj8Ln2D0Gw=
=3XIX
-----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/?list_id=735