Domain authorization mechanisms should not make anti-forgery
claims, despite the misleading charter goal. A domain is
never the author of a message. Nor would a message being
from an authorized domain assure the recipient that forgery
has been prevented. Secondly, the circuitous matrix of
information involved in such a mailbox-domain authorization
approach would be difficult to convey to the recipient as the
basis for acceptance. Opportunistic identifications can be
limited to direct and immediate information found within the
message itself.
I think that the problem here is that you are describing an
implementation rather than a specification.
I agree that the type of analysis you describe is possible, the
anti-spam filtering services already have similar processes in place.
The point of SSP is to simply describe the sender signing policy of the
domain. This helps the recipient interpret unsigned messages purporting
to come from the domain with greater accuracy.
For example consider the following policies:
* "The domain anybank.com is regularly targetted by phishing attacks,
all legitimate mail from this domain SHOULD be signed"
* "The domain example.com is performing a limited trial of DKIM, only
some mail from example.com is signed".
* "The domain example.com signs every mail using RSA-SHA256."
Each one of those statements provides information that helps a spam
filter to make the right decision.
At this point we basically have two proposals:
1) Try to solve the problems of spam and phishing to the best extent
that email signatures allow
2) Limit the scope of the work strictly to the minimum.
I think that the second is a major mistake that would result in the
working group taking longer to deliver just the message package than it
would take to deliver a full specification.
I have seen this happen more than once. WGs fail when they attempt to
develop abstract platforms which are not grounded in a practical
problem. The further the group steps away from the problems of spam and
phishing the harder progress will be.
_______________________________________________
ietf-dkim mailing list
http://dkim.org