On November 12, 2005 at 22:16, "Hector Santos" wrote:
You change the "rules!" - again! Doug, I'll give you thing. You are
consistent. :-) The lack of an answer proves my entire point of the 2821
vs. 2822 exercise and to make a long story short, DKIM/SSP needs to stand on
its own. It can be integrated with other ideas, but it can't be dependent on
it because once it is, the issues become too wide, too complex and costly.
We are back to square one. As it is, it will difficult to keep 2821 related
concepts out of the mix, but that all depends on which school of thought you
are from and without a doubt, more related to implementation suggestions.
When I saw your first post about the exercise, I thought it was a
rhetorical one to make a point.
The problem with your exercise is that it assumes that 2821 and
2822 are mutually exclusive and a method may not encompass both.
Design arguments can be made that any method should not encompass both,
but the realities of how email operates may make that difficult since
current operating practices already blur the two.
Also, from a security perspective, it has not been proven that a
per-2822 method may not have to rely on 2821 (transmission level)
method(s) to deal with certain threats (replay attacks comes to mind).
Therefore, a party could use payload-only solution, but such a practice
may be ineffective if threats exist that cannot be adequately addressed
by the payload-only solution.
So in theory, you can have a payload-only solution independent
of any transmission-level solution, but in reality there may
be a dependency to adequately address security threats.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org