Tim Legant writes:
>> Any suggestions for what this header should be called?
>
> Well, how about trying to keep even the idea of how these apps work > out of the
>picture. Maybe something like
>
> X-Preferred-Address
Ooh! I like this one.
Jason R. Mastaler writes:
> Here's one potential problem/objection to this. It took me a bit to
> recall why I hadn't already added such a mechanism.
>
> This would allow me to add arbitrary addresses to another user's
> whitelist.
Yes, that is an odd bit of sabotage.
What I'm going to suggest will sound odd, but I'll explain later on
in this post why I'd like to see us implement this. I've wanted this
sort of mechanism for the second part thing (auto-confirming) which
I'll explain in a moment.
I'd like to have a configurable address comparing function where we
can specify closeness. The configuration might be something like
this:
0 - No two (even identical) addresses are considered a match.
1 - Only identical addresses are considered a match.
2 - To be considered matching, addresses must have identical domains
and the first part of the addresses (up to the first punctuation
mark) must match. i.e. [EMAIL PROTECTED] and
[EMAIL PROTECTED] would match.
3 - To be considered matching, addresses must have identical domains.
4 - To be considered matching, the last two parts of address domains
must match. i.e. [EMAIL PROTECTED] and [EMAIL PROTECTED]
would match.
5 - Any two addresses are considered matching.
If we had a compare function like that, then the user could configure
how close the X-Preferred-Address would have to be to the reply-to
address before we would use it. Otherwise we'd simply use the reply-
to address.
Jason R. Mastaler writes:
>> Should I elaborate on part two of that original post (i.e. a safe
>> method for doing auto-confirms between TMDA users), or would that
be of
>> interest?
>
> Sure, go for it.
Since this thread originated on another forum, I'm going to recap
before explaining. Feel free to skip ahead.
===
[EMAIL PROTECTED] writes to [EMAIL PROTECTED] for the first time. The email is sent as
[EMAIL PROTECTED] but it includes an "X-Preferred-Address [EMAIL PROTECTED]" header.
[EMAIL PROTECTED]'s TMDA sends a confirmation to [EMAIL PROTECTED] which will be
received by user [EMAIL PROTECTED]
[EMAIL PROTECTED] replies to the confirmation, and user [EMAIL PROTECTED]'s TMDA will release
the original message. TMDA then adds [EMAIL PROTECTED] to its confirmed list
instead of [EMAIL PROTECTED] Any further mail will be allowed even if it
comes from [EMAIL PROTECTED] because [EMAIL PROTECTED]'s TMDA is using the X-Preferred-
Address header when it does a filter search.
===
Part two allows [EMAIL PROTECTED]'s TMDA to automatically add (if user [EMAIL PROTECTED] has
configured TMDA to do so) [EMAIL PROTECTED] to his/er confirmed list when TMDA
receives the confirmation request above.
Because I'm not sure of the terminology you guys use, I'm going to
define one-way function F such that N=F(M,crypt_key) if we generate a
valid address in the form [EMAIL PROTECTED] Likewise, if we receive
mail addressed to [EMAIL PROTECTED], we can verify whether it is
authentic by testing to see if N==F(M,crypt_key).
Now to accomplish part two, user [EMAIL PROTECTED]'s TMDA not only includes a X-
Preferred-Address header, it also includes an X-Authentication
header. This new header would be along the lines of:
X-Authentication [EMAIL PROTECTED],N
Where N=F([EMAIL PROTECTED],crypt_key).
When [EMAIL PROTECTED] receives the initial message from [EMAIL PROTECTED], it sees the
X-Authentication header and includes the header verbatim in its
confirmation request.
[EMAIL PROTECTED]'s TMDA receives the confirmation request and sees the X-
Authentication header which it tests. N==F([EMAIL PROTECTED],crypt_key) so we
now know that [EMAIL PROTECTED]'s TMDA is really replying to a message we sent.
Our crypt_key is never given out, so although this header could have
been data-mined from other emails, it could not be forged.
At this point, [EMAIL PROTECTED]'s TMDA compares the email address in the X-
Authentication header and the X-Preferred-Address header. These two
addresses are probably the same, but they do not have to be. We then
use the comparison function I described above to determine if the
addresses match. The user can be as picky or as lenient about
matches as s/he pleases. If the match succeeds, the X-Preferred-
Address is added to [EMAIL PROTECTED]'s confirmed list.
Whew! I know that was rather long-winded, so I thank you for hearing
me out (and possibly drawing little diagrams to make sure I'm not on
crack!).
Feedback is welcome,
Gre7g.
=================================================================
Gre7g Luterman [EMAIL PROTECTED] http://www.templeofluna.com/
Stay informed: http://www.templeofluna.com/keeper/mailinglist.htm
Into each wound, a little salt must fall...
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
