Subject: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:16:21 -0500

> It's also a principle of good engineering that you don't make unnecessary
> changes to deployed code. 

I think that's an overgeneralization.   There's neither a wide enough
deployment of DKIM, nor sufficient evidence of DKIM's suitability for
the diverse user community, for the current DKIM specification to
dictate the standard protocol.  
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:10:07 -0500

> > >Since experimentation resulted in significant Internet deployment of these
> > >specifications, the DKIM working group will make every reasonable attempt to
> > >keep changes compatible with what is deployed, making incompatible changes only
> > >when they are necessary for the success of the specifications.
> > 
> > implies the need to be clarify the charter in two ways. 
> 
>  The charter needs to reaffirm that the IETF has change control over
> the specifications at this point, so that there is no question over who
> gets to decide whether an incompatible change is necessary.  The
> charter also needs to indicate that the working group will consider the
> relationship of this work to other, existing IETF technologies. 

I'll go further than that.  The text you quoted from the proposed
charter is inappropriate, and needs to be removed entirely.

DKIM as currently envisioned has serious flaws that not only limit its
flexibility but which will do harm to domains that do not fit its
Procrustean model for policy advertisement.  The flaws are fixable, and
with the fixes DKIM could be quite useful for discouraging forgeries.
But the flaws aren't fixable without making incompatible changes. 

The "only when necessary for success" clause raises the bar for changes
too high.  At best it is confusing because different people define
"success" in different ways.   There are unfortunately some DKIM
proponents who want IETF to rubber stamp this protocol, despite its
widely acknowledged flaws.   If this clause is allowed to stand they
will try to use it as a stick to prevent changes that would make DKIM
much more widely applicable.

The DKIM working group should have complete latitude to change any
feature of the current DKIM protocol.  The DKIM protocol is neither
widely deployed enough nor useful enough in its current form to dictate
features of an IETF standard protocol. 
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:21:27 -0500

> 1. As interesting as such a discussion might be, it has no effect on the
> technical work. The choices made were the choices made. The goal is to
> make as few new ones as we can, not to spent time reviewing past
> choices. 

That is almost never an appropriate goal for an IETF working group
creating a standard.  The goal of a standard-setting working group is
to understand and describe what will work well for the Internet as a
whole and to vett that design via wide review, not to rubber-stamp what
has been designed by a small group of people and deployed under
relatively limited circumstances.

> -I'm suggesting
> > the WG tell the IETF what, if anything, is wrong with the bits the IETF had already
> > done. 
> 
> Earth to Ted:  THAT'S NOT THE JOB OF THIS WORKING GROUP.

Dave, you are not the one who decides what this working group does.
that's IESG's job.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:30:41 -0500

> >> the specification" is way too high for that.
> 
> Too high for what?  Instead of arguing principles Eric, needs to 
> indicate what specific technical work that is excluded by this language 
> is actually essential to the goals of DKIM.

Dave,

You keep making statements like that without a shred of support for
your position. You seem to think that you alone dictate the conditions
under which a working group should be chartered. You are mistaken,
and IMHO your efforts are hindering progress of the the DKIM effort.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Dec 2005 16:34:26 -0500

> It's a significant precedent that IETF charters have included language
> of this sort when there has been a deployed base at the time the WG is
> chartered.  But can someone explain what's different in this wording
> that warrants departing from the version on which there seems to be
> rough consensus?

there isn't a DKIM WG yet, so "rough consensus" of the mailing list is irrelevant.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: "Arvel Hathcock" <[email-masked]>
Date: Wed, 21 Dec 2005 15:38:26 -0600

> There is no wide deployment of DKIM. What is there are several test 
> machines on the order of couple dozen.

Either the person who made that statement is visiting all our customer sites 
and uninstalling / reconfiguring our software or this is evidence of the 
ignorance of the speaker on the topic.  I am personally responsible for many 
more than "on the order of [a] couple dozen" installations of DKIM capable 
software.  How anyone could possibly divine that there are "on the order of 
[a] couple dozen" installations (and all these are "test machines" no less) 
is grandly mystifying and I suggest that a trip to Vegas would be a better 
use of such skills.

> to go around IETF and create proposal in private
> and then present to IETF for a stamp of approval.

"go around IETF?"  What is that supposed to mean?  "Stamp of approval" eh? 
Ridiculous.  Some of the work hasn't even started.  Much that does exists is 
highly in need of a rewrite.  All that exists is open to the possibility of 
change.  Does that sound like a "stamp of approval" to anybody?  And it must 
be asked, what is the worth of an IETF "stamp of approval" these days?

> But perhaps that marketing wins over technically best

<Sigh>  Oh, the evil "marketing" wins again.

-- 
Arvel "the Marketer" Hathcock
CEO, Alt-N Technologies, Ltd.
http://www.altn.com

---

From: Mark Delany <[email-masked]>
Date: Wed, 21 Dec 2005 21:56:41 +0000

> ignorance of the speaker on the topic.  I am personally responsible for many 

Right. We are already seeing DK signed email from more different
domains than the number of domains sending S/MIME email.

Mark.

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 21 Dec 2005 14:16:40 -0800 (PST)

On Wed, 21 Dec 2005, Arvel Hathcock wrote:

> Either the person who made that statement is visiting all our customer 
> sites and uninstalling / reconfiguring our software or this is evidence 
> of the ignorance of the speaker on the topic.  I am personally 
> responsible for many more than "on the order of [a] couple dozen" 
> installations of DKIM capable software. How anyone could possibly 
> divine that there are "on the order of [a] couple dozen" installations

It is hard to distinguish dkim sites from dk based on dns records,
so exact number of sites is hard to determine, however some scripts
were run to see what the sites that are known to have _domainkey
records are sending and all but 4 of those sites I could notice 
had DK signature and not DKIM. Either those DKIM sites are not
sending any serious amount of email on the net or they are not
in production operations. So, I'll stand by the figure that number
of sites sending DKIM email is < 100 (as of Nov 20th) and if
somebody wants to provide exact list that disproves that - go
ahead and send it to dkim list.

> "go around IETF?" What is that supposed to mean?

It means that instead of starting MASS a year ago as planned and doing
proper design work there as most IETF WGs do, the group did the work
in private between several vendors and then present to IETF with 
limitations apparently put in the charter to make it less likely
there could be any changes.

> "Stamp of approval" eh? 
> Ridiculous.  Some of the work hasn't even started.  Much that does 
> exists is highly in need of a rewrite.

I'm sorry but comparing it to work I've seen done at other WGs, it
does seem like "stamp of approval" is being thought for majority of
work with some additional (mostly non-core) items still open for WGs
plus polishing the draft text.

BTW - the only significant issue that I still see that it seems WG is
expected to work on are policy records and there is not even clear
consensus there if this should be worked on.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Arvel Hathcock" <[email-masked]>
Date: Wed, 21 Dec 2005 17:08:22 -0600

> I'll stand by the figure that number of sites sending DKIM email is < 100

Go ahead and do that then but know this:  10 minutes ago I sent out an email 
to a 200 count sampling of my customer base asking "who's using DKIM".  So 
far, I've received 2 responses and already the list of domains running DKIM 
is over 35.  I'll exceed your "< 100" by the time I'm done writing this 
message.  That was with only a small sampling of 200.  I have 
tens-of-thousands of SMBs using my product and there are vendors here who 
make me look like an ant in comparison.  So, as long as I'm a member of this 
list, the claim that "nobody uses DKIM" will not go unchallenged.

-- 
Arvel Hathcock

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 07:22:52 +0100

Arvel Hathcock wrote:

> the list of domains running DKIM is over 35.  I'll exceed
> your "< 100" by the time I'm done writing this message.

That's fine, and as we know about 1,000,000 domains and 10
independent interoperable implementations are good enough
for "experimental".  3 steps or 4 steps to "full standard",
who cares, only _less_ steps could be dangerous for the Net
if serious issues with the technology show up very late.

> the claim that "nobody uses DKIM" will not go unchallenged.

BTW, what do you do with it on the receiving side, just use
it to bypass more "expensive" (CPU) spam filters, or also
some kind of "punish FAIL results" (reject / score / tag) ?

                          Curious, Frank

---

From: Mark Delany <[email-masked]>
Date: Thu, 22 Dec 2005 06:54:31 +0000

> independent interoperable implementations are good enough

Really? DKIM/DK deployment by domain already surpasses all IETF
"designed in a vacuum" email authentication protocols. You probably
know this Frank so I presume your 1,000,000 domains reference is a
humorous allusion. Forgive me for being dumb, but I just don't get
what you're alluding to. Can you elaborate?

Mark.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 10:08:41 +0100

Mark Delany wrote:

> I presume your 1,000,000 domains reference is a humorous
> allusion.

Of course, about an "experiment" trying to set new records
wrt the length of the accompanying IESG note, at least half
of it about another experiment.  As long as nobody claims
to "embrace and extend SSP" no danger here.

                            Bye, Frank

---

From: "Arvel Hathcock" <[email-masked]>
Date: Thu, 22 Dec 2005 09:31:26 -0600

> some kind of "punish FAIL results" (reject / score / tag) ?

I will send you a screen-shot showing the options privately.

--
Arvel

---

From: "Arvel Hathcock" <[email-masked]>
Date: Thu, 22 Dec 2005 09:43:21 -0600

> That's fine, and as we know about 1,000,000 domains
> and 10 independent interoperable implementations are
> good enough for "experimental".

Well, I don't have anywhere near that many.  And I'm not pretending to know 
what constitutes "wide deployment" or "how many users is enough", etc.  This 
isn't for me to decide anyway.  All I want to do is counter the claims 
people make that there are a couple dozen test machines or < 100 domains 
using DKIM.  I'm a better "marketer" than that <g>.  I now have a list as a 
result of my 200 customer sampling last night that is 300+ domains.

--
Arvel

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 22 Dec 2005 08:56:29 -0800 (PST)

> result of my 200 customer sampling last night that is 300+ domains.

It is good to have real numbers. As I said it is very difficult to find
number based on looking at dns (which is bad as I think it would have 
been better if _dkim prefix was used instead of reusing _domainkey - it
is really not that difficult to setup CNAME if one wants to share). The
only large email-use domain using DKIM I could actually see was cisco.

I do have a preference to seeing the number of separates sites (i.e. 
installations as opposed to #of domains), you did mention that just
two sites accounted for 35 domains before...

Also based on what I could see I think it may well be that there is only 
one or two commercial products that released dkim in their production
products - you can easily see it based on who talks about interoperability
testing on development list (and I don't think sendmail released their 
version  to production; neither did cisco beyond their own use, which 
leaves only ....)

In any case the amount of use for DKIM (and for that matter even DK) is 
still extremely small compared to real-word installation of SMTP and this
all should be enough that group work on standards without preconditions.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 22 Dec 2005 19:41:57 +0100

Arvel Hathcock wrote:

> I now have a list as a result of my 200 customer sampling
> last night that is 300+ domains.

Tnx for info - most of the mails I get are spam because I read
mailing lists behind a mail2news gateway online as "news", and
therefore I "see" only what the bad guys do.  So far they don't
try any tricks with DKIM from my POV, or I missed it.

                         Bye, Frank 

P.S.: got the jpg, nice :-)

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Dec 2005 18:18:26 -0800

Nathaniel Borenstein <[email-masked]> wrote:
> On Dec 21, 2005, at 12:23 PM, william(at)elan.net wrote:
> Let's be honest:  We're not really arguing about the degree to which
> the WG is biased towards the specifics of the DKIM draft, but rather
> whether or not it is "biased towards" (I would rather say focused on)
> this one fundamental approach to the exclusion of all others.

Well, that may not be what you're arguing about, but it's certainly
what I'm arguing about, at least at the present moment.

The language under debate doesn't impact the question you raise one way
or the other. The first paragraph of the charter quite clearly states
that the WG will be working on domain-level signatures. So, the language
under debate is purely about ruling out incompatible changes that still
fall along these same general lines.

> Domain-level email signatures are a pretty good idea, one of many
> that, taken all together, just *might* help us preserve the utility of
> email and other open electronic communications.  The purpose of the
> new WG should be to produce the best possible domain-level email
> signature standard, using DKIM as a concrete but reasonably flexible
> starting point.  Nobody is going to argue against considering really
> meaningful improvements to DKIM, even if they introduce
> incompatibilities, 

Then why the push to have charter language designed to do exactly
that? 

-Ekr

---

From: Douglas Otis <[email-masked]>
Date: Sun, 25 Dec 2005 00:09:23 +0300

On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote:
>    
> Far from trying to "leave only one authorization method," the DKIM 
> effort is an attempt to show, by example, how an arbitrary number of 
> such methods might eventually be elaborated and standardized.

There is danger viewing any abuse control mechanism as representing a
"authorization" scheme.  The control method should strive to identify
the source of abuse, and not just whether the message has been
authorized.  The DKIM signature provides a fairly strong indication of
the message source, with a normal potential for abusive replay as with
any cryptographic method.

> It is an attempt to define one method first, as a step towards
> defining as many of them as possible/necessary rather than arguing
> endlessly over which is best.  For most of us, support for DKIM does
> NOT imply opposition to any other proposals related to controlling
> spam and related ills.  A lot of us who have worked on DKIM were
> previously active in trying to bridge the gap between SPF and Sender-
> ID, and despite the disappointments we'd still like to see that effort
> succeed, as well as quite a few other anti-malware ideas and
> technologies.

Those who envision SPF or Sender-ID as a means to control spam, clearly
have not considered the inherent weakness in an "authorization" scheme.
Bad actors are adept at adopting any such authorization.  Reputation
remains the only solution able to abate the bulk of abuse.  When
reputation is applied against an "authorization" as an identifier,
innocent email-address domain owners will be seriously harmed.  Abusers
will find acceptance methods for an authorization scheme.

To abate abuse, name-based identifiers are needed to overcome growing
exploits. Reliance upon "authorization" as an abatement control must be
avoided as inherently unfair.  The DKIM signature can identify the email
source, and when considered independent of any email-address, can
establish non-disruptive reputation based abatement controls.  A
verified EHLO can also serve the same purpose.  There are drafts and MTA
extensions available today to offer this similar low cost solution.

If the desire were really to abate abuse, there is no mystery what can
help.  CSV, BATV, and the base DKIM would be examples of schemes that
can identify email sources.  Name-based schemes can significantly reduce
the amount of spam when coupled with fair reputation assessments.

Authorization is clearly not an abatement solution.  Authorization
should be seen as a method to shift the burden onto the email-address
domain owner.  The outcome of an authorization strategy in today's
shared environments would likely damage the reputation of most email-
address domains.  The exception may be for the mega-domains less
sensitive to reputation assessments simply due to their size.

DKIM should be devised to exist without requiring an authorization
scheme to handle message replay or unsigned messages.  When MTAs and
MUAs are designed to recognize the source of email using DKIM
signatures, reliance upon authorization (or reputation) for spoofing
protection would be unnecessary.  Reliance upon visual examination that
often involves acquiring every look-alike domain may also become
unnecessary.  Recognition ability could be rapidly included in the MTA
to offer immediate protections for commonly spoofed domains, while
avoiding the disruption an "authorization" scheme is sure to cause
current email practices.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 27 Dec 2005 07:46:48 -0800 (PST)

On Fri, 23 Dec 2005, Nathaniel Borenstein wrote:

> I generally try to stay out of discussions when everything has already been 
> said a thousand times, but this one is too important to ignore, and I fear 
> that people are arguing over red herrings rather than speaking plainly about 
> the underlying issue. So in what follows I will try to give a reasonably 
> simple explanation of why a bunch of long-term IETF guys decided to form a 
> private group to develop DKIM:

I think simple explanation is the one you can fit in one sentence, this
wasn't it...

>> Yes, the DKIM group clearly purposely bypassed discussions as part of
>> MASS (i.e. ietf open forum) in order to do it in private and leave only 
>> one authorization method
>
> This is completely backwards, the precise opposite of why a few of us 
> decided to start a closed, private group to define what became DKIM.   Far 
> from trying to "leave only one authorization method," the DKIM effort is an 
> attempt to show, by example, how an arbitrary number of such methods might 
> eventually be elaborated and standardized.  It is an attempt to define one 
> method first, as a step towards defining as many of them as 
> possible/necessary rather than arguing endlessly over which is best.  For 
> most of us, support for DKIM does NOT imply opposition to any other 
> proposals related to controlling spam and related ills.  A lot of us who 
> have worked on DKIM were previously active in trying to bridge the gap 
> between SPF and Sender-ID, and despite the disappointments we'd still like 
> to see that effort succeed, as well as quite a few other anti-malware ideas 
> and technologies.

Talk about "red herring". I specifically meant authorization method
used with email automated (mailserver-added) signatures and you change
the subject be different kinds of email "authorization" systems. I'm
in fact all for different types of systems and supported wider view
of the problem and use of multiple tools (if they don't interfere
with each other), but not standardization of closed designs.

So what is true is that I did not get it wrong. MASS originally was 
discussing several authorization methods: public keys in DNS, 
fingerprints in DNS (and in special HTTP fingerprint server),
X509 certificates located on HTTP server and X509 certificate servers.

In DKIM however there is left only public key in dns (and talking about
other methods would be excluded by means of the working group charter)
and I do not believe this issue was ever properly decided on and my
argument is that there should be more authorization methods being
available (in initial release, otherwise they'd never really get deployed)
because public keys retrieval from domain root is too limiting and can 
not for example fit all scenarios well; plus I think this "chosen" method 
is in fact the worst one [based on possible impact to infrastructure]
of those available (although it does have large vendor supporting it
and only it as usual...)

For reference as to how it all occurred you might want to go back one
year and glance at
  http://web.archive.org/web/20050204075618/mipassoc.org/mass/crocker-features-iim-dkeys-09dc.htm
and that might make you wonder what is ESTG (care to guess about what
this acronym stands for...) which has its own meetings and mail list -
  http://mipassoc.org/mailman/listinfo/estg-general
it was mentioned on ietf too:
  http://www1.ietf.org/mail-archive/web/ietf/current/msg39474.html
BTW - even more interesting message was recently leaked out of it:
  http://www.mhonarc.org/archive/html/ietf-dkim/2005-12/msg00115.html

I'm against doing standardization in limited (and especially private
and closed) forums and to me this is what it looks like MASS turned
out to be (and I really don't care if this had few "long-term IETF"
folks involved or not). When some SPF folks wanted to do their own 
standardization group I had some strong comments on their effort too.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Dec 2005 10:31:42 -0800

On Dec 27, 2005, at 7:33 AM, Nathaniel Borenstein wrote:
>
> I'm sorry, the "authorization method" was an echo of the term used  
> in the mail I was replying to (which is why it was in quotes).  I  
> was really trying to generalize to a whole range of technologies  
> without making my wording too awkward.  Perhaps I should have  
> replaced "such methods" with "antimalware technologies" or "abuse  
> control mechanisms."  In any event, I fully agree that the term  
> authorization, in this context, is both A) insufficiently  
> generalized, and B) troublesome  on countless philosophical grounds.

The response was specifically against the use of "authorization."   
With respect to SPF/Sender-ID or SSP, these are indeed email-address  
"authorization" schemes.  With Sender-ID, "authorization" has been  
incorrectly described as form of "authentication", and much like  
Sender-ID, SSP appeared more by way of introduction rather than  
discussion.  All of these "authorization" schemes, especially SSP,  
will disrupt the delivery of legitimate email.  This "authorization"  
scheme also proposes untold numbers of DNS lookups for perhaps any  
number of From addresses and signatures.  The art of "open-ended  
authorizations" (burden shifting) in SSP will soon include  
"authorized" signature lists.  SSP also considers itself a "weak"  
form of "authentication" by directing complaints to email-address  
rather than the signer. : (

>> Reputation remains the only solution able to abate the bulk of abuse.
>
> The word "only" makes me cringe a bit in any discussion like this  
> (a global fascist state, for example, is another possible  
> solution), but I think most of us pretty much agree about the  
> critical role of reputation.

Some view a closed system, rather than a system open to tens of  
millions of email-address domains, as an alternative to reputation.   
Even in that austere system however, each would consider their access  
contingent upon their reputation for good behavior.  Reputation is an  
unpleasant reality where identifying those culpable for abuse _must_  
_not_ be taken lightly.

> I see the cycle as going like this:  We need at least one  
> standardized, moderately-useful system for weakly authenticating  
> the sources of messages.

I see the base DKIM draft forming a solid basis to identify email  
sources.  The ill considered SSP draft will seriously hinder the DKIM  
effort.  Serious problems are already being handled by way of burden- 
shifting, rather than considering real solutions.  The related  
expense associated with an imposition of a disruptive email-address  
authorization scheme does not justify this component's inclusion  
within the DKIM charter.  With far less overhead, spoofing attempts  
can be thwarted without email-address authorizations.  Many of the  
serious crimes depend upon embedded links rather than use of an email- 
address (which are never seen by the majority of recipients).  A  
solid basis for the source of an email-address will significantly  
enhance protective strategies.  It is a dangerously false premise  
that an authorization scheme offers protection, as any assurance in  
that regard will increase the success rate of criminal fraud.

> Once we have that, we have the minimal data that a reputation  
> system will require to be able to start doing something at least  
> mildly useful.

Please note authentication does _not_ include SSP.

> Once we have *that*, we will have (in our reputation systems) a  
> built in "market" for additional systems for (perhaps less weakly)  
> authenticating the desirability (not necessarily solely due to the  
> source) of incoming messages.  To some extent, there's a chicken- 
> and-egg problem with authentication and reputation technologies.   
> My hope for DKIM is that it will give us one good enough egg to  
> produce a chicken, which can then (in much the manner that Cain and  
> Abel found their wives, I guess) facilitate a whole new generation  
> of authentication technology eggs.

Agreed.  Do not let the ill conceived SSP derail DKIM.

>> When reputation is applied against an "authorization" as an  
>> identifier, innocent email-address domain owners will be seriously  
>> harmed.  Abusers will find acceptance methods for an authorization  
>> scheme.
>
> Yes, every one of these schemes will be flawed.  That is why we  
> need to understand A) the role of "weak authentication" (weeding  
> out some but not all of the bad guys at any point in time, and  
> using multiple sources of information to judge the desirability of  
> a message) and B) the need for a continually evolving set of (ever- 
> stronger, we hope) mechanisms for proving that a message is  
> desirable to the recipient.  Some of those mechanisms will also  
> involve (ever-stronger, we hope) sender authentication, but others  
> could eventually involve technologies as unrelated to  
> authentication as anonymous payment.

To ensure email does not self-destruct, use of reputation against  
authorizations _must_ be avoided as imposing highly unfair treatment,  
even when email practices adapt to new paradigms.  When governments  
start issuing digital postage stamps, knowing the source of the email  
message remains important.  The recognition of these sources is  
beyond visual examination that can _not_ be aided by an authorization  
scheme.  MUAs will need to assist in the recognition efforts.  DKIM  
and recognition, but not authorization!

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 28 Dec 2005 04:55:23 -0500

----- Original Message -----
From: "Douglas Otis" <[email-masked]>

> effort.

You keep saying that "every which way but loose."

The thing is, I don't agree and I know I not crazy... so. :-)

The bottom line is "for me" is NO SSP, NO DKIM. I won't bother. I won't
waste my time.    Call it want you want SSP or whatever, the process
must be consistent, and if there is NO HIGH reliable DETERMINISTIC (not
HEURISTIC) verification concept of a newly introduced entity into the
process, then its isn't worth anything.  What's the point?  We will get
swamped with YAHOO junk mail anyway and until the day YAHOO declares a
specific POLICY on how to handle its domain mail, the DKIM/DK overhead
will not be added. PERIOD.

If you wish to continue to pitch "your ideas" that's fine, but you
should really give it up already trying to convince people SSP will
crack the earth.

FWIW, NO SSP == NO DKIM.  Its worth less overhead.

That said, Have a happy new year. :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 Dec 2005 10:12:14 -0800

On Dec 28, 2005, at 1:55 AM, Hector Santos wrote:
> "Douglas Otis" <[email-masked]> wrote:
>>
>> sources.  The ill considered SSP draft will seriously hinder the  
>> DKIM effort.
>
> The bottom line is "for me" is NO SSP, NO DKIM. I won't bother. I  
> won't waste my time.  Call it want you want SSP or whatever, the  
> process must be consistent, and if there is NO HIGH reliable  
> DETERMINISTIC (not HEURISTIC) verification concept of a newly  
> introduced entity into the process, then its isn't worth anything.   
> What's the point?  We will get swamped with YAHOO junk mail anyway  
> and until the day YAHOO declares a specific POLICY on how to handle  
> its domain mail, the DKIM/DK overhead will not be added. PERIOD.

The dkim-options draft provides the 'w=?' signature extension:

  w=b  Always signed by MSA, broad ass. across email-domain
  w=n  Always signed by MSA, narrow ass. with email-address
  w=d  Signed by MSA, broad association across email-domain
  w=a  Signed by MSA, narrow association with email-address
  w=o  Signed by MSA, association with Opaque-Identifier
  none Signed by MSA, no association assured
  w=B  Always signed by Mediator, broad ass. across email-domain
  w=N  Always signed by Mediator, narrow ass. with email-address
  w=D  Signed by Mediator, broad association across email-domain
  w=A  Signed by Mediator, narrow association with email-address
  w=O  Signed by Mediator, association with Opaque-Identifier
  w=M  Signed by Mediator, no association assured
  w=X  Signed by MDA, no association assured

Most of this information should prove valuable for the MUA, and not  
the MTA.  The exception could be 'w=b'.

When an MTA sees the 'w=b' within a signature, for bigbank.com as  
example, where the email-address domain is also within the signature  
domain, this can be captured in a local-list as a (wildcard) domain- 
name (in a zone) with a pointer to where this assertion can be later  
confirmed.  When a message is accepted, email-addresses may be  
quickly queried against this local list.  When the message has an  
originating email-address domain found within this local-list, but is  
not signed by this domain, once the 'w=b' assurance is confirmed, the  
message would be refused.  This involves only a single cached query  
that occurs only when a spoof has been attempted.

Compare that to SSP, where Jim suggested in the threat draft every  
 From email-address domain may have the tree climbed looking for an  
SSP policy record.  Few of these lookups would be cached when these  
records do not exist.  These records also increase the domain's  
exposure to unfair reputation harm, unless the record expressed  
essentially the same assurances as 'w=b'.  If a domain like Yahoo  
still allowed their users the freedom to send their email-address  
through other providers, there would be no exclusion obtained.   
However, when Yahoo signs their messages and includes an Opaque- 
Identifier, the recipient would be able to recognize when the email  
source used by a particular Yahoo author changed.  The value of the  
DKIM signature does not depend upon excluding messages at the MTA, or  
being from a major corporation that assures exclusive use of their  
domain name.

The value of DKIM is fully realized when MUAs utilize the signature  
to recognize prior correspondents.  Highlighting such messages would  
be a safe and useful indication shown to recipients.  (Offering any  
indication that a message was authorized by an SSP record would put  
the recipient in serious jeopardy of being mislead.)  With DKIM and  
recognition built into the MUA, look-alike domains exploits, and  
other spoofing attempts could become a problem of the past.  BATV  
would still be needed to handle DSN exploits, and CSV would be needed  
to offer DoS protections and replay mitigations.  : )

-Doug