DKIM should serve as an excellent mechanism for verifying the domain
accountable for the MTA to MTA exchange at the transport level.
However, once the email-address is bound in some manner to the
transport, a set of significant problems arise.
In the current SSP draft:
2.9 Verifier Acceptable Third Party Signature
...
,----
| A Verifier SHOULD accept signatures that correspond with
| addresses in the "Sender" header, MAY accept signatures
| that are for identities that the Verifier is certain will
| be displayed to end users, and MAY accept signatures that
| pass other tests such as accreditation or reputation.
| Verifiers SHOULD NOT accept signatures from identities
| that have no known relationship with the message other
| than their appearance in the "DKIM-Signature" header.
'----
From this, at least the Sender header must correspond with the
signing-domain or the message MAY NOT be accepted. To meet the
general requirement for a first-party signer, the first From email-
address is expected to match the signing-domain where multiple email-
addresses may then be required, such as:
From: <my-account(_at_)my-isp(_dot_)com>, Mustang Sally
<Sally(_at_)some-school(_dot_)edu>
Introducing similar visual confusion for list-servers the following
will appear:
From: IETF-DKIM No-Reply <ietf-dkim-bounces(_at_)mipassoc(_dot_)org>, Douglas
Otis <dotis(_at_)mail-abuse(_dot_)org>
DKIM deployment will prove disruptive when introducing a requisite
correlation between an email-address and the signing-domain. Some
may consider these issues as simple changes in current practices.
Spending months sorting millions of various spoofs, I still find
myself missing subtle changes that take a minute even when I know it
is wrong. Some companies have spent large sums attempting to acquire
look-alike domains. There is also an emergence of more than one
million characters where many overlap ASCII, and where perhaps even
puny-code compatible TLDs are not far off, rather than using multiple
character-sets within a domain name.
See:
http://www.circleid.com/posts/in_pursuit_of_idn_perfection/
A quote out of context from a comment to this article by Suresh:
,---
| I would have thought that people over the ages will have
| become extremely wary of ad-hoc fixes and technologies
| that don't have global consensus, and which fail non-gracefully
| in the case of edge situations. But no :(
'___
The initial response to puny-code in some applications has been to
turn-off the display of the referenced fonts. Will displaying the
puny-code for the segment of the population relying upon this
technology prove helpful for detecting a spoof?
For example: xn--cjsp26b3obxw7f.com
Puny-code places visual examination of the domain for security
purposes well beyond reason. Even when restricted to just ASCII,
spammers have proven resourceful at finding visually similar urls
where perhaps a 1/l/I are interchanged or an extra l is added. Of
course, the majority of email readers only see the pretty-name not
checked against SSP policies.
It would be reasonable for the MUA, and in some cases the MTA, to
track the signing-domain with that of the email-address. When these
two items change their relationship, the recipient can be alerted to
perhaps even the most subtle of change. This would ensure recipients
detect spoofs as those of a prior correspondence. This approach
would not require the email-address correspond in any manner to that
of the signing-domain, or require an out-of-band policy mechanism.
Better still, this would not disrupt current practices allowing for
the normal use of the From header and for list-servers to sign their
mail without extensive changes to list-server applications and the
corresponding handling by the MUA.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org