On Tue, 2005-01-18 at 04:04 -0800, william(at)elan.net wrote:
Well, its not useless, just not as usefull and not a solution for phishing
as we're trying to present this effort as.
What I said is 'useless to _me_'. Which it would be -- because if it
doesn't let me reject mail out of hand because it's not signed when the
apparent sender says they'll sign all mail, I won't even bother to
implement it.
Yes, perhaps it'll have some utility to _some_ people but it'll have
none for me unless it manages to exceed the threshold where the hassle
of implementing it is outweighed by the benefit :)
Take a look at the following and after that decide for yourself if you
reall could get automated software that would rely on Resent-
headers.
You've presented an example in which it's fairly much impossible to
choose the wrong address as the 'most recent sender' because the Sender:
and Resent-Sender: are the same. Based on that example alone I can't
really conclude that it wouldn't work.
To be interesting, your example would need more than one Resent-Sender:
header to be present. Can you try resending a message to that list (or
to a similarly configured list) and show us what happens?
I still think it's wrong for us to be authorising a single RFC2821
transition by grubbing around in the higher layer for RFC2822
identities. But the consensus seems to be otherwise and I'm trying to
salvage what I can from the consequences of that decision.
--
dwmw2