I'll be really interested in which POLICY causes this low likelihood, low impact problem?
-- Hector ----- Original Message ----- From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Douglas Otis" <[EMAIL PROTECTED]> Cc: "IETF-DKIM" <[email protected]> Sent: Thursday, November 17, 2005 5:27 PM Subject: Re: [ietf-dkim] SSP security relies upon the visual domain appearance > > Doug - quick and simple question: does all of this depend > on there being >1 From address? > > Douglas Otis wrote: > > 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: <[EMAIL PROTECTED]>, Mustang Sally <[EMAIL PROTECTED]> > > > > Introducing similar visual confusion for list-servers the following > > will appear: > > > > From: IETF-DKIM No-Reply <[EMAIL PROTECTED]>, Douglas Otis > > <[EMAIL PROTECTED]> > > > > > > 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 > > > > > > _______________________________________________ > ietf-dkim mailing list > http://dkim.org > _______________________________________________ ietf-dkim mailing list http://dkim.org
