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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Tuesday, November 15, 2005 3:02 PM
To: Douglas Otis; dcrocker(_at_)bbiw(_dot_)net
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" <dotis(_at_)mail-abuse(_dot_)org>
To: <dcrocker(_at_)bbiw(_dot_)net>
Cc: "IETF DKIM pre-WG" <ietf-dkim(_at_)mipassoc(_dot_)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