The only problem I have with SPF is a possible licensing nightmare wrt Microsoft. Even if deployed I would be looking at a way to get it out of my network. If you look at new installs of SPF it is stalled since Microsoft announced. Building DKIM around SPF is not a good idea although keeping it open enough so that there is no leaning to any one sender auth function is a good idea.. Thanks,
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Tuesday, November 15, 2005 3:02 PM To: Douglas Otis; [EMAIL PROTECTED] Cc: IETF DKIM pre-WG Subject: Re: [ietf-dkim] DKIM charter Doug, I have no doubt you believe in all this and there are many valid points. But I think it is over blown and I don't wish to get into my opinions to dispute each of your points. But I will point out one thing that I think you are missing in all this: SPF is here to stay. You are not going to replace it with CSV/DNA or whatever. Millions of domains are already using it various policy declarations: FAIL -ALL Exclusive PASS/FAIL policy NEUTRAL ?ALL Open Neutral Policy SOFTFAIL ~ALL Warning, Something not right Thousands of SPF domains already have established polices that declare exclusive, neutral to softfail. Including high-value domains such as BankOfAmerica.com: nslookup -query=txt bankofamerica.com "v=spf1 a:sfmx02.bankofamerica.com a:sfmx04.bankofamerica.com a:vamx04.bankofamerica.com a:vamx02.bankofamerica.com a:txmx02.bankofamerica.com a:txmx04.bankofamerica.com a:cr-mailgw.bankofamerica.com a:cw-mailgw.bankofamerica.com ~all" If BankOfAmerica was concern about just the TRANSPORT, it could of just use an EXCLUSIVE PASS/FAIL SPF policy (-ALL). Instead, it used a SOFTFAIL SPF policy (~all). In other words, with an EXCLUSIVE SPF policy, they would have LESS reason to use DKIM. The exclusive SPF policy defines the MACHINES allowed to send email on their behalf. However, for whatever reasons, they choose to use a SOFTFAIL SPF policy which provides a HINT to the receiver that BankOfAmerica.com is not "100% sure" and may have some non-company network still sending email on their behalf. Maybe they are using a clearing house or bulk mailer service. Who knows? Regardless of the reason, the problem is the same - a lost of the IP::DOMAIN association or what I call a "transition point." So how can DKIM help SPF? With BankOfAmerica.com using EXCLUSIVE SPF policy, a PASS result says there is really no need to check DKIM. You should just accept the message. With BankOfAmerica.com using EXCLUSIVE or STRONG DKIM policy, along with SPF, it says that even if we allow OTHER MACHINES to send mail, the email must be BankOfAmerica.com domain DKIM signed transactions. That is where the spoofing and fraud is stopped. So.... - pretty names don't apply because DKIM will stop it. - DoS attacks can be addresses using current IP analysis and load balancing methodologies already in placed, independent of any new non-standard protocol. - The MUA does not need to change because the confidence is place in the ISP to do the transactions security. For Online MUA, the ISP can display extra confidence information, especially of the domain is using SPF+DKIM. Finally, SPF is a RFC-standards track item. CSV/DNA is not. If you want to look at the big-picture, SPF should be the integrated consideration, not CSV/DNA. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Douglas Otis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "IETF DKIM pre-WG" <ietf-dkim@mipassoc.org> Sent: Tuesday, November 15, 2005 1:32 PM Subject: Re: [ietf-dkim] DKIM charter > > On Nov 14, 2005, at 5:24 PM, Dave Crocker wrote: > > > >> It would seem consensus may have been reach by those convinced > >> that since many abusive messages spoof the email-address, limiting > >> the use of an email-address therefore prevents abusive messages. > > > > > > 3. If you aren't, then how is your lengthy note usefully responsive > > to Jim's point? > > There is a larger community affected by these changes. Inclusion of > the DKIM signature alone _greatly_ enhances an ability to defend > against abusive messages. Several have expressed almost zealous > motivations for also constraining the use of email-addresses. The > charter should take a long view and be sensitive to disruptions > created by email-address constraints, rather than offering > justifications. Never should these email-address constraints be seen > as a method to abate spam as currently implied by the charter. : ( > > Motivations for email-address constraints should be tempered by a > realization that: > > 1. Email-address constraints can be readily circumvented by Bad Actors. > MUA displays are not secure allowing: > a. acquisition of look-alike domains with various character-sets > b. reliance upon "pretty name" displays with new/used domains > c. positional obfuscation within headers > > 2. Email-address constraints will disrupt email services. > a. ISPs will require/inject multiple From addresses > b. Third-party services will need to inject multiple From addresses > c. RFC2822 precedence will be modified > d. MUAs will not function as expected > > 3. Email-address constraints will expose users to greater abuse. > a. posting multiple From addresses increases spam burdens > b. limiting email-addresses to the provider reduces privacy > c. local-parts in DNS may invite unabated dictionary attack > > 4. Once MUAs are DKIM aware, there will be _no_ benefit in email- > address constraints. > MUA would be able to: > a. track email-address/signing-domains > b. display the signing-domain > c. indicate when the email-address is assured by the signing-domain > > > Does it make sense to get the DKIM signature in place before deciding > what else must be included? Does the WG really need to promote > dubious email-address constraints? Targeted sites will benefit > substantially when link related information is compared against the > DKIM signature. Comparison of the From address offers at most a > modicum of protection which will be in place anyway in response to > the attacks. The signature itself offers a touchstone for users to > check the validity of the message by exposing the headers with older > MUAs. > > > -Doug _______________________________________________ ietf-dkim mailing list http://dkim.org _______________________________________________ ietf-dkim mailing list http://dkim.org