On Nov 29, 2006, at 1:44 PM, Michael Thomas wrote:
I'm not sure whether this rises to a -ssp-req item or not -- I sort
of lean toward it just to make certain that it is tracked. Or if
there's a bunch of disagreement about what satisfies the SSP
criteria, then it most likely should be...
This should be tracked.
DKIM policy (which should include domain associations) must not be
limited to just one email header. Visual recognition of a From email
address is confounded when displaying UTF-8, where an ACE label or
different character repertoires might be used. Surely no one expects
people to visually validate puny-code conversions or inspect
character codes. This is just one problem related to visual
recognition strategies. This situation becomes even more problematic
as the From header itself changes roles. The sooner the DKIM WG
acknowledges a visual recognition strategy is seriously (if not
fatally) flawed, the better. DKIM must be used in conjunction with
trusted lists such as address-books for there to be spoofing
protections.
Proponents of visual recognition proclaim messages (such as those
passed through a mailing-list) should be rejected to support this
highly flawed strategy. A visual recognition protection scheme is so
flawed as to be dangerous when describing visual recognition in
conjunction with authorization as protection. Bad actors will adapt,
and be rewarded with a means to gain a recipient's confidence. It is
hard to imagine a worse strategy. There is no reason for DKIM to be
so disruptive with current and future email applications.
An authorization/visual recognition strategy will likely only block a
few percent of spoofing attempts once countered. An annotation
scheme based upon "listed" recognition schemes will not disrupt use
of mailing-lists or the EAI efforts, for example. Once dependence
upon visual recognition has been set aside as flawed, then other
headers can be afforded protection under an annotation/trusted list
strategy.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
