On Sat, 2005-08-20 at 13:08 -0400, Scott Kitterman wrote: > Douglas Otis wrote: > > > Defensive strategies must find a different identifier assured by the > > domain as a unique basis for locating trouble. This is simply being > > pragmatic, but this new identifier will not impact the way email > > operates, as would adding constraints on the mailbox-domains. MASS > > should adhere to an oath that above all, do no harm to remove all > > excuses. : ) > > You can't stop forgery without stopping forgery. Some things that are > perhaps technically forgery are considered desireable. Other things > that aren't forgery might be affected by forgery prevention protocols.
Stopping forgery requires a system analogous to S/MIME or OpenPGP. Anti-forgery may be seen as a cause to garner support. However, in reality DKIM is ill suited to satisfy such a goal directly. DKIM has the limited scope of _just_ the signing domain. Forgery or non-forgery can not be directly determined by the signing domain. There is no practical benefit attempting to conditionally select headers that must share the domain of the signature. Headers may not be displayed, or displayed by the pretty name. The mere option of the binding and the possible lack of display seriously erodes any presumed value, but increases susceptibility to fraud, which would be a dubious cause for garnering support. Should this already dubious effort pursue greater complexity by extending this optional binding authorization scheme to include extensive tree walking for possibly dozens of mailbox-addresses to discover their domain-wide binding assertions. Should there be specific permission lists assessed for each of these mailbox-addresses, to decide whether the signing domain is authorized to send such re-submitted messages? Won't this cause far more trouble than it could be possibly worth? > I'm not on a 5-10 year timetable that says things get better after the > whole world upgrades. > > I don't believe it is possible to have any near-term positive effect > without also having some potential for near-term harm. DKIM should > allow for restrictive policies for domain owners that are willing to > live with the side effects of those policies. Breaking email in the near term, for half measures trivially evaded, will not garner support. Feeble half measures still impact those who want nothing to do with troublesome and ill-conceived schemes. Email can least afford dealing with support issues due to changes in previously valid procedures. Worse, new limitations in email address re-submission increase costs, risk expectations of deployment, while abusers still slip past these troublesome email address obstacles. > I ask you which would be worse for a commonly phished domain, that their > messages would fail verification if sent to a mailing list or that > forgeries of their domain would continue to be delivered to end users? As phishing involves much more than spoofing the From address (which even the current DKIM draft does not prevent), there needs to be a different strategy. To combat phishing, Draconian conventions must be followed with respect to _all_ aspects of the email message. The number of checks such anti-phishing efforts entail, means these checks may be best limited to an industry list of specific domains. DKIM can play a vital role by indicating the signing domain, to offer a solid basis for detection. Anti-phishing's extensive checks could be placed at risk when applied universally or perhaps when applied upon request by any sender. > I expect that many domains would be willing to give up mailing lists for > a way to enable receivers to detect and reject forgery of their domain > during the SMTP session. The term forgery with respect to DKIM is misleading. Email did not achieve its current scale of deployment by checking authorizations for every possible entity contained within a message. Instead email depends upon a hierarchy of trust or accountability. It would be a significant achievement having the DKIM signature, with perhaps even the HELO, verified. Such domain level authentications greatly strengthens this trust and accountability. The basic operation of email would not change, yet an ability to exclude those known for abusive behavior would be dramatically improved. Use of a name would cause less collateral blocking. A name can rely upon a history specified by the registrars, even though specific information of who owns the name may be concealed. Just this fundamental ability can help abate all these cause Celeb abuses. > I think it's DKIM's job to give them the choice and the information to > make an informed decision. > > First do no harm is fine if the patient isn't dying already. Unfortunately, problems are not constrained to just email. Header binding From is cosmetic when done "some of the time" and does not consider pretty names. This binding will not breath life into email, but rather it will create problems for users, and likely discourage adoption, and encourage those committing fraud. DKIM should verify a domain that can be held accountable for stopping abusive messages. (It would be nice for the recipient to see who is accountable.) However, displaying the accountable domain is not needed and should not be attempted with feeble header bindings. With DKIM, administrators can ensure bad actors are excluded. With DKIM, creating a list of trusted domains will exclude most of the emails which need greater examination. I like the "profound" quote from the comedy City Slickers. Jack Palance played trail boss Curly Washburn and said "Do you know what the secret of life is? One thing. Just one thing. You stick to that, and everything else don't mean s***." DKIM should do one thing. Verify a domain that can be held accountable for stopping abusive messages. -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org
