> An RFC for what? There were a couple different points being discussed > in this thread, and it's not clear which you are referring to here.
I was talking about an RFC that would standardize a way to avoid the situation described in FAQ 4.5. If the different communities creating TMDA and similar products could come to an agreement (preferrably soon while these communities are small and few) about added headers that communicate between filters, then users wouldn't have to resort to editing whitelists manually when beginning reply-reply-reply chains with other filter users -- whether they are using identical software or not. For example: (Please don't jump all over the following. I'm not proposing it. It's just an example way to implement what I'm talking about.) Such an RFC could specify a header like: X-TAGGED-EMAIL-ADDRESS: <some address> and then expect compliant filters to use the given address (if present) in their filtering and any auto-add mechanism, instead of the envelope address, from address, reply-to address, etc. If we had that, then the chain of events in a reply-reply-reply exchange between Alice & Bill might go as follows: [1] Alice sends Bill an e-mail. Alice's filter doesn't know Bill yet, so it uses a dated address. [2] Bill's filter sees the above header, so instead of filtering based on Alice's envelope/from/reply-to addresses, it uses the specified address. Since Bill hasn't spoken to Alice before, he doesn't have this specified address in his filter/database. His filter bounces back a confirmation notice (to the dated address, not the specified one). [3] Alice's filter allows the confirmation notice to come in because the dated address is valid. [4] Alice receives the confirmation and replies. This reply would again be dated since Alice's filter doesn't know Bill. [5] Bill's filter receives the confirmation and allows Alice's original e-mail in. [6] Bill replies to Alice's e-mail and since his filter now knows Alice, it sends using Bill's bare address. [7] Alice's filter finds the specified header and uses that to search her filter/database. It isn't there yet so it bounces a confirmation notice back to Bill (using his bare address). [8] Bill's filter allows the confirmation message in because Alice is on the list. [9] Bill replies to the confirmation notice. [10] Alice's filter receives the confirmation notice and adds the specified address to her list. It also sends the original reply through. At this point, both filters are updated with non-dated addresses and replies will all continue bare and without additional confirmations. I've got another variation on this which I won't mention unless other people are interested. It would allow this whole exchange to move ahead with only a single confirmation instead of two. Is that more clear now? Gre7g. ================================================================= Gre7g Luterman [EMAIL PROTECTED] http://www.templeofluna.com/ Stay informed: http://www.templeofluna.com/keeper/mailinglist.htm Never pet a burning puppy. _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
