Subject: RE: [ietf-dkim] A more fundamental SSP axiom

From: Arvel Hathcock <[email-masked]>
Date: Fri, 04 Aug 2006 19:05:00 -0500

> If a signer wants to take that risk, isn't that for them to decide?

Precisely.

> Also, if the usual strategy of a verifier is to bounce (or be
> encouraged to bounce) the offending email, a "I sign all" sender will
> almost always know about delivery failures of originally signed
> traffic and be able to act accordingly. 

Right.  I don't see a big reason to worry with this at all.  There are all sorts of reasons SMTP might bounce a message back as it is.

-- 
Arvel 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 20:19:53 -0400

> Right.  I don't see a big reason to worry with this at all.  There are all sorts of reasons SMTP might bounce a message back as it is.

True, but those bounces are more than likely going back to the user to
let them know, their buddy changed his email address, or they
mistyped, etc. Things that they can effect.
 This bounce will be utterly useless to the user because they can't do
anything about it except to resend. So they get 10 more bounces for 10
re-sends... then what.. my phone starts ringing off the hook. Not
something I will likely be able to fix right away.... and my phone
keeps ringing.

Regards,
Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 17:26:49 -0700

>>traffic and be able to act accordingly. 

So if I set a policy of "I sign all", and a mailing list mangles it, 
what exactly
is the mailing list receiving the bounce going to do? Blackhole it? Bounce
the user off the list? Anything useful whatsoever?

>Right.  I don't see a big reason to worry with this at all.  There are all sorts of reasons SMTP might bounce a message back as it is.

That makes the assumption that it gets bounced at all. Lots of things just
silently discard things they don't like these days.  Not that there's 
anything
useful that a mangler is likely to be able to do in any case.

       Mike

---

From: Mark Delany <[email-masked]>
Date: Sat, 5 Aug 2006 01:13:37 +0000

> the user off the list? Anything useful whatsoever?

That's a matter between the "I sign all" and the list. I would say
that if it hurts, don't do it.

As you say receivers do all manner of things already, including
bouncing content they don't like. Bouncing mail that has attachments,
bouncing mail that is too big. I'm told that some places bounce all
mail that has freemail address in the From:

And are we talking about Mailing Lists today, or Mailing Lists in five
years time after DKIM slowly ramps up? A Mailing List of the future
mail well be verifying incoming mail and make decisions about
re-broadcasting based on "I sign all"?

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 21:02:52 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: <[email-masked]>

> what exactly is the mailing list receiving the bounce going to
> do? Blackhole it? Bounce the user off the list? Anything useful
> whatsoever?

We develop an MLS so I can provide my our integration design considerations
done.

It depends first if the MLS is DKIM compliant.  If not, normal MLS
processing is done, which may of course promotes the #1 DKIM concern -
breaking the integrity of the message.

For the DKIM compliant MLS, then in order to "better" support DKIM, some
major consideration has to be done.  Some considerations were written in
DSAP:

 3.3.  Mailing List Servers

   Mailing List Servers (MLS) applications who are compliant with DKIM
   and DSAP operations, SHOULD adhere to the following guidelines:

   Subscription Controls

      MLS subscription processes should perform a DSAP check to
      determine if a subscribing email domain DSAP policy is restrictive
      in regards to mail integrity changes or 3rd party signatures.  The
      MLS SHOULD only allow original domain policies who allow 3rd party
      signatures.

   Message Content Integrity Change

      List Servers which will alter the message content SHOULD only do
      so for original domains with optional DKIM signing practices and
      it should remove the original signature if present.  If the List
      Server is not going to alter the message, it SHOULD NOT remove the
      signature, if present.

In short, there were three design questions here:

- Will a domain who wants to sign all mail even want to send
  his mail into a mailing list that is not DKIM complaint?

  You are assuming this is desirable.

- Will then DKIM compliant MLS even want to accept the
  responsibilty for handling the incoming domain mail with
  restrictive policies?

  The MLS will only want to do 3rd party signing, so it would
  only be ideally work with policies that allow 3rd party signing.

- and will then DKIM compliant MLS even to allow the subscription
  from email domains  restrictive policies?

  To mininize failure, a pre-emptive approach is a great feature
  for the MLS DKIM implementator.  I see this an feature for
  the software. So the docs should only provide hindsight.

If you believe MLS should be able to sign all mail itself without
restriction, then without a doubt this will help mold (cut down) the
available policies for DKIM.  This is what you want, I believe.

But again, this assumes that domains will even want to send these types of
high-value domain mail to a mailing list, and without a 3rd party signing
restriction, you open the door for abuse because you will never know for
sure if it really come from a MLS or some other middle-man exploitation.
You lose confidence in the DKIM signing practice.

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 18:42:59 -0700

>that if it hurts, don't do it.

_Who_ don't do it?  The subscriber to the list? As in, just don't send 
anymore?

>re-broadcasting based on "I sign all"?
You've got me. Sure sounds like the net effect is a DOS on the poor schlub
on the mailing list though. Maybe IETF can finally wind down its business
before hand.

       Mike

---

From: Mark Delany <[email-masked]>
Date: Sat, 5 Aug 2006 02:16:56 +0000

> on the mailing list though. Maybe IETF can finally wind down its business

I'm a little confused. I thought you were gathering requirements, but
this "Death of the Internet at 11" sort of response suggests that
you're done with hearing from others.

I don't really care one way of the other, I just want to understand
where in the process we are.

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 19:39:04 -0700

>you're done with hearing from others.

I can't gather requirements if I can't make any sense of what you're saying.
I'll note that you cut out the question that was trying to get at what 
you're getting
at. It would also help if people didn't give glib hand waving answers 
expecting
me to guess as to what they mean.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 22:54:32 -0400

From: "Mark Delany"

> re-broadcasting based on "I sign all"?

Very good point.

For me, it is almost a no-brainer of what we will need to add our mailing
list server on the onset.  To reduce all kinds of issues from support,
survivability questions, including reduce liability,  these two features
will help:

1)  Check for restrictive policies during subscription process, accept
     only non-DKIM domains or those that might allow 3rd party signing
     depending if the MLS signing option is enabled.

2)  Offer new options to avoid mail integrity changes (adding Header and
     Footers) based on DKIM messages.

The last one is very tough because most people are going to want to add
footers, so that pretty much dictates one or more two things:

    - The domain allows 3rd party signing, and/or even possibly
    - The domain allows stripping of the original.

Stripping I believe violates DKIM-BASE so that's something that should be
reconsidered.   Stripping fits well with a policy such as:

       OP=optional;3P=optional;    Both Party may sign

But if the MLS is intent in signing the mail, it will be difficult for MLS
to support:

        OP=NEVER; 3P=NEVER;    No signing expected
        OP=ALWAYS; 3P=NEVER;   1st party only always signs mail
        OP=OPTIONAL; 3P=NEVER;  1st party may sign mail

So the domain itself has to be aware of what it doing with its DKIM mail.

---

From: John Levine <[email-masked]>
Date: 5 Aug 2006 01:41:39 -0000

>> So if I set a policy of "I sign all", and a mailing list mangles
>> it, what exactly is the mailing list receiving the bounce going to

>that if it hurts, don't do it.

No, the sensible user will accept all the mail from the list.  With
luck the list will sign and the user will whitelist the list's sig,
or get an endorsement from his favorite reputation system.  Or the
list won't sign and we'll recognize it the way we do now via List-ID
or other clues.  If you already have an opinion about a message,
there's little reason to look at SSP.

The one case where "I sign all" might be useful is if a message shows
up with no signature and no other hints that it might be from a
reliable sender.  Maybe.

R's,
John

---

From: <[email-masked]>
Date: Sat, 5 Aug 2006 00:09:23 -0400

How does the post office do it? It receives mail from other countries
and determines what kind of stamps official franking etc to either
deliver or return to sender unopened. Part of that is a balance of
payment schedule but I imagine it is a mutual bi-lateral agreement that
determines this. A ruthless prosecution of people who purport to send
legitimately franked mail is also part of the solution.

DKIM is an electronic stamp, SSP (to me) appears to be the franking
system.
A bi-lateral agreement that implementers can agree that if the stamps
and the franks are okay, mail will be deemed semi acceptable except for
checking for criminal (spammish) activities.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Levine
Sent: Friday, August 04, 2006 11:41 PM
To: [email-masked]
Subject: Re: [ietf-dkim] SSP requirements

>I can't gather requirements if I can't make any sense of what you're
saying.

That's a reasonable concern.

The fog around SSP is so opaque that I'm really wondering if it
wouldn't make more sense to punt and wait for people to do enough
experiments to understand what turns out to be useful.

The first open question is when a receipient would check a sender's
SSP.  It seems pretty clear that if a message is self-signed, there's
no need to check, and if it's completely unsigned you do want to
check.  But what if it's signed by a third party you trust?  (That's
the mailing list scenario.)  If a message is signed both by you and by
someone else I see no reason to treat that as anything other than a
self-signed message, but some people disagree for reasons that remain
unclear.

Assuming we can work that out, I hear reasonable unanimity on "I
send no mail", that is, if you get an unsigned message purporting
to be from me, it's a fake so throw it away.

I hear considerably less consensus on "I do send mail but throw it
away if it's not signed."  There's some sentiment for "if foo signs
it, then it's OK" although then we get into arguments about delegating
signing keys and the like.  I hear no consensus at all about anything
else.  There are lots of other true things one could say about one's
outgoing mail, but surprisingly little that's useful to recipients.

A spec with 1 2/3 bits of data doesn't impress me as worth writing.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Aug 2006 21:43:30 -0700

> experiments to understand what turns out to be useful.

The problem, here, is that it really is not possible to do "experiments" in the
classic sense.  First there is the matter of needing to get adoption among
multiple independent administrations.  Second there is the matter of needing
experience in natural environments.

This combination means that we can field initial, small mechanisms and see how
to enhance them, but we are not likely to get adoption/testing if folks think it
is an experiment.  However the might adopt and test if they see it as an
obviously useful mechanism that will be around for a long time.  However this
requires a compelling value proposition.

So "punting" is probably not the right path.

What is more likely to be the right path is standardizing a mechanism for
publishing SSP statements, and standardizing 1-3 statements that will get
published.

Do we have consensus on 1 statement that senders will want to make and receivers
will want to know?  I suspect we do.

After that we are merely haggling over price.

So let's settle on the 1, 2 or 3 statements with a sufficiently broad and strong
consensus to make it clear that we should standardize them, and be done with it
(for now.)

The two that I vote for are:

1. I sign everything.  If the rfc2822.From field has my domain in it, then I
assert that it will be signed by me.  If you get a message with my domain in the
rfc2822.From field and the message is not signed *by that same domain* then I
assert that the message is not valid.  You might want to consider handling it
accordingly.

2. I send no mail.  If the rfc2822.From field contains my domain in it, then I
assert that its posting was not authorized.  You might want to consider handling
it accordingly.

Both of these will eliminate cases of classic From-field spoofing. (Of course
they will have no effect on bots sending from machines authorized to create
those From fields.)

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Mark Delany <[email-masked]>
Date: Sat, 5 Aug 2006 04:46:40 +0000

> No, the sensible user will accept all the mail from the list.  With

Well maybe, but that's not the intent of my style of "I sign all".

If "I sign all" I would much rather no one accept a mail purportedly
from me that doesn't verify. Why would an "I sign all" domain want
mail accepted that can't be proved to be from them?

But them I'm missing this whole "list" issue. It seems to me to be
largely a red-herring because the size of the intersection of "I sign
all" traffic and DKIM-unaware Lists is pure speculation at this stage.

Mark.

---

From: <[email-masked]>
Date: Sat, 5 Aug 2006 01:03:32 -0400

Perhaps we should work backwards, what are the mechanisms for DKIM
compliant mailing lists?
If a signed message arrives and SSP says 3rd party allowed, evaluate
resign send
If evaluate fails bounce without propagation
If no sig and policy says "I sign all" bounce message
If SSP states "I only sign" forward without adding list signature or
bounce message
Myriad other possibilities
 
Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Delany
Sent: Saturday, August 05, 2006 12:47 AM
To: [email-masked]
Subject: Re: [ietf-dkim] A more fundamental SSP axiom

Mark.

---

From: Mark Delany <[email-masked]>
Date: Sat, 5 Aug 2006 05:09:30 +0000

> experiments to understand what turns out to be useful.

That's a reasonable proposition. It's certainly the case that we're
dealing with parties who want to make bi-lateral "I sign all"
arrangements with us, but it's early days so measuring the value an
generality of that is some way off.

Their thinking is that they don't need Internet-wide support (or
perhaps they don't want to wait for it), all they need is enough
support to make the attackers move onto an easier target. Yes,
self-preservation is not pretty, but it's common.

As far as I recall, we have never been propositioned for any
bi-lateral that is less rigid than "I sign all" for a given
domain. From this list it's clear that senders must be clammering for
more subtle policies, but those senders aren't talking to us so I'm
not competent in those discussions.

Mark.

---

From: John L <[email-masked]>
Date: Sat, 5 Aug 2006 01:13:19 -0400 (EDT)

> deliver or return to sender unopened.

International postal mail is one of the worst possible analogies for 
Internet mail.  It's a closed system consisting of only 190 post offices, 
each of which is a national monopoly.  All the security is at the 
perimeter, i.e., when you mail a letter to England, the USPS checks that 
the stamp is real, but when the USPS hands it to RM, RM assumes it's OK. 
There's a complex settlement scheme to share postage revenue when the 
bilateral flow of mail is unbalanced which has no online equivalent, thank 
goodness.

And, of course, there's no identity security at all on postal mail.  I can 
write "Bill Oxley" as the return address on a letter, mail it, and no post 
office will notice or care.

Although it is completely irrelevant to Internet mail, the international 
postal system, which goes back to the 1870s, and its history are quite 
interesting.  See http://www.upu.int.

> DKIM is an electronic stamp, SSP (to me) appears to be the franking

This is so wrong I don't know where to start.

R's,
John

---

From: <[email-masked]>
Date: Sat, 5 Aug 2006 01:22:36 -0400

It's  an Analogy Son, an Ananalogy. Thanks for the link. The issue is
how do disparate systems agree on how to talk to one another, declare
reasonably enforced rules and abide by them. According to many here a
SYN does not need to be followed by a ACK but perhaps a SWIFTY is
perfectly reasonable and should be understood and enacted upon by both
parties.

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: John L [mailto:[email-masked]] 
Sent: Saturday, August 05, 2006 1:13 AM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]
Subject: RE: [ietf-dkim] SSP requirements

International postal mail is one of the worst possible analogies for 
Internet mail.  It's a closed system consisting of only 190 post
offices, 
each of which is a national monopoly.  All the security is at the 
perimeter, i.e., when you mail a letter to England, the USPS checks that

There's a complex settlement scheme to share postage revenue when the 
bilateral flow of mail is unbalanced which has no online equivalent,
thank 
goodness.

And, of course, there's no identity security at all on postal mail.  I
can 
write "Bill Oxley" as the return address on a letter, mail it, and no
post 
office will notice or care.

R's,
John

---

From: John Levine <[email-masked]>
Date: 5 Aug 2006 03:40:58 -0000

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 05 Aug 2006 07:30:07 -0700

> all" traffic and DKIM-unaware Lists is pure speculation at this stage.

Consider that "I" may be in regard to a list of domains.  As such, there
would be two statements that could apply. "I sign all" and "Only I sign"
as an indication of whether the "I" list is complete.

The reason for making the stipulation of the list being complete would
be to indicate non-complaint services will not be used.  A financial
institution would most likely want to make this stipulation, where
concerns regarding issues related to things that might look like
e-invites, or mailing-lists are rejected without further examination.
For the vast majority of domains, "I sign all" where the list of other
possible sources is defined as incomplete would be a better choice. 

When "I" refers to an empty list, "I sign all" would then mean my
messages may or may not be signed, and an empty list with "Only I sign"
would mean this domain does not send mail.  

The default assumption of a listed domain in the policy would be to
assume "I sign all".  This could even be called the "I sign all" list.
The only embellishment needed would be the "Only". The default policy
when none is found would be an empty list with the assumed "I sign all"
assertion.

-Doug 

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 05 Aug 2006 09:28:55 -0500

> So let's settle on the 1, 2 or 3 statements with a sufficiently broad
 > and strong consensus to make it clear that we should standardize them,
 > and be done with it (for now.)
 >

+1.  This is exactly what we should do in my view.  Also make the 
protocol extensible and we're pretty much done for the initial round.

-- 
Arvel

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 5 Aug 2006 14:54:45 -0400

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

> when none is found would be an empty list with the assumed "I sign all"

+1.

In terms of the DSAP draft syntax:

    OP=ALWAYS; 3P=NEVER;     # Only "I" sign mail

or

    OP=ALWAYS; 3P=ALWAYS;    # "I" sign mail
    3PL=;                    # defined, but empty list;

In terms of the SSP draft syntax:

   o=!  # All mail from the entity is signed; Third-Party signatures
        # SHOULD NOT be accepted

But the SSP I-D stills has the "semantics" argument of what is meant by
"Third-Party signatures SHOULD NOT be accepted."  I took this to mean 100%
exclusivity. Apparently that is not what it means.  Hence one of the reasons
for a "Fill in the holes" DSAP I-D proposal

---

From: Michael Thomas <[email-masked]>
Date: Sat, 05 Aug 2006 13:11:06 -0700

>experiments to understand what turns out to be useful.
That's a pretty reasonable question, frankly. The set of domains that 
would actually
benefit from SSP from the consensus I've seen seems like it's a pretty 
tiny fraction of
the internet at large and almost certainly could be handled by third 
party dnsbl-like
or accreditation schemes as well. But it may be worth it if for no other 
reason to
provide the transport, discovery, and syntax framework for putting 
goodies in for the
experiment.

          Mike

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 5 Aug 2006 16:42:42 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "John Levine" <[email-masked]>

> would actually benefit from SSP from the consensus I've seen seems
> like it's a pretty tiny fraction of the internet at large and almost
> certainly could be handled by third party dnsbl-like or accreditation
> schemes as well.

This is complete hogwash and it is completely dumbfounding that a person who
was either commissioned, asked or had volunteered to write the design
requirements has already come to a own incorrect, highly subjective
conclusion about the need SSP without ever completing the work!!

This is completely unacceptable.  If you don't understand SSP and can't do
the job of writing the draft document, then it is probably best to  hand it
off to someone who does understand and is willing to be completely open
minded with ALL parties in mind and then allow chips fall where they may.

My apology to the WG chairs, but this is utterly ridiculous position coming
from a person who is suppose to write the SSP design requirements.  It reeks
badly with obvious signs of conflict of interest by specific individuals to
kill SSP.

---

From: John L <[email-masked]>
Date: Sat, 5 Aug 2006 16:42:14 -0400 (EDT)

> would actually benefit from SSP from the consensus I've seen seems like 
> it's a pretty tiny fraction of the internet at large and almost 

Agreed.  That's what I've been thinking all along.

> But it may be worth it if for no other reason to provide the transport, 
> discovery, and syntax framework for putting goodies in for the 
> experiment.

If people want to do experiements, they should do experiments.  The IESG 
would never go for an SSP spec that was just a container for data yet to 
be invented.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 05 Aug 2006 15:23:35 -0700

> for a "Fill in the holes" DSAP I-D proposal

A major benefit regarding a DKIM From policy is in facilitating
relationships between different From and signing domains.  Other methods
involve greater coordination between DNS and email providers.  Zone
delegation or selector/key arrangements are not easily achieved with a
simple "fill in the blank" style questionnaire.  Zone delegation or
key/selector arrangements likely require an arrangement of trust beyond
the immediate customer to achieve the needed transaction.  This
additional element of trust will likely act as a barrier to greater use.

Imagine that an organization certifies DKIM signing domains as doing the
"Right Thing".  The "Right Thing" might be using authenticated SSL 587
port submissions, where the From address has been vetted in some
fashion.  This vetting might be acknowledgments of receipt as commonly
used for mail-lists, or anything deemed trustworthy by the
organization. 

In the event that this mode of delegation "by way of policy" becomes
popular, an assertion that Foo signs for Bar may be fairly common.  Your
terminology attempts to make assertions specifically related to the From
domain separately from that of other listed domains.  This fails to make
a clear distinction for a listed domain. With your terminology, the
listed domain is easily confused as being some undefined signer, which
is not right.  It seems safer to include the From domain _and_ the other
listed domains into just one category of Designated Signing Domains.
Any domain listed in the DKIM From policy would be a Designated Signing
Domain.  Apply _any_ assertion to this entire DSD category.

The default assertion for _any_ listed domain is "Always Signs".

There Foo indicates they always sign.
"DKIM-FP: Foo"

It would confusing to use a 3PL entry to indicate no other signature
unfriendly services are being used that might perhaps originate a
message using the From domain.  Here a flag, perhaps at the end of the
list, could make this stipulation.  Call this the Only, Exclusive,
Closed-ended, or Complete-List flag.  To illustrate, this flag is "." or
(FULL STOP).

The "Only" Flag stipulates that no other services are used. Further
examination of possible e-invites or mailing lists are require or
desired, as they are not used.  This policy would be something like:

"DKIM-FP: Foo, ."

Sends no mail would be:
"DKIM-PF: ."

May or may not sign would be:
DKIM-FP: "

Both Foo and Bar sign (for Bar) would be:
DKIM-FP: Foo, Bar"

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sat, 05 Aug 2006 15:32:04 -0700

On Sat, 2006-08-05 at 15:25 -0700, Douglas Otis wrote:

Correction:
The "Only" Flag stipulates that no other services are used. Further
examination of possible e-invites or mailing lists are [not] required or
desired, as they are not used.  

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 5 Aug 2006 19:05:16 -0400

----- Original Message -----
From: "John L" <[email-masked]>
To: "Michael Thomas" <[email-masked]>

> Agreed.  That's what I've been thinking all along.

In other words, your 3rd party dnsbl-like DAC business venture with some
highly exploitable VBR protocol, with $10,000, $5000 entry feeds, with
absolutely no plans for SSP, is the right solution for everyone and will
resolved all the security issued related to DKIM.   This wasn't about the
your so called "SSP FOG" rethorical chaos but rather a conflict of interest.
Having SSP still in play will not serve your business well.

Wonderful.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 5 Aug 2006 16:16:50 -0700

On Aug 5, 2006, at 1:42 PM, John L wrote:

>> That's a pretty reasonable question, frankly. The set of domains  
>> that would actually benefit from SSP from the consensus I've seen  
>> seems like it's a pretty tiny fraction of the internet at large  
>> and almost certainly could be handled by third party dnsbl-like or  
>> accreditation schemes as well.
>

The DKIM From policy is fairly limited to being a possible domain  
delegation alternative, and perhaps a flag that might indicate  
greater care is being exercised due to a phishing problem.

>> But it may be worth it if for no other reason to provide the  
>> transport, discovery, and syntax framework for putting goodies in  
>> for the experiment.
>
> If people want to do experiments, they should do experiments.  The  
> IESG would never go for an SSP spec that was just a container for  
> data yet to be invented.

I would hope this would be true.

An another policy that might be considered would be one for the DKIM  
client, rather than just for the DKIM From domain.  The DKIM client  
policy could simply an indication a client in this domain always  
signs, and that the client can always be authenticated by a DKIM  
convention.  The DKIM client policy could be even implied by the  
presence of the DKIM From policy.  The simplest authentication  
convention would be just an Address RRset transaction for the EHLO  
host-name.  Knowing the name of the client makes further domain name  
association within the message possible, and would be a domain  
examined before any additional resources are expended.

The DKIM authentication convention could be noted at the EHLO by  
having the host-name for the client utilize a "_dkim." prefix.  This  
prefix signals the mode of authentication made possible by the DKIM  
convention claiming this prefix.  This could fall into the same realm  
as the key, and From policy records.  There would be zero additional  
transactions needed to support this form of client authentication,  
assuming an A record lookup would be performed anyway.  The "_dkim."  
prefix can make this authentication more stringent, instead of this  
being allowed to fail as currently defined in RFC2821.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 5 Aug 2006 17:17:21 -0700 (PDT)

> Having SSP still in play will not serve your business well.

Hector, calm down. John does have business interests in commercial
accreditation services, however I think he in general somehow does
not like policy records (probably something to do with his dislike
of SPF) and that has not seriously changed and probably would not
have had no matter if he was working on DAC or not. Besides that DAC
seems to be more like accreditation organizations' business group
and the above mentioned fees are such organizations' membership dues
rather then actual accreditation service fees (though I hear some
accreditation service charge a lot more...).

I do want to point out though that there does seem to be number of
people on this list heavily involved in commercial accreditation
services. As many of these organization's business plan can be in
conflict with having mature email policy record framework, it would
be good if these people attempt to either avoid policy record
discussions or make their best effect to look at the world from the
point of that their (and other) accreditation systems do not exist
and in such a way try to examine use of the email policy records.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Sat, 05 Aug 2006 17:18:50 -0700

Douglas Otis wrote:

> client

I'm sorry, I have no idea what a dkim client is. Can you in as few of 
words as
possible tell me what that is?

       Mike, rather burned out on these threads
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John L <[email-masked]>
Date: Sat, 5 Aug 2006 20:56:37 -0400 (EDT)

> John does have business interests in commercial accreditation services, 
> however I think he in general somehow does not like policy records

It's true, I don't, and I've been trying to figure out why not.  It 
finally came to me: senders are not the right people to judge their own 
importance.

When I think of SSP records saying dump mail if it's not signed, I see a 
bunch of tiny gorillas*, beating their teensy chests and saying in high 
squeaky voices, "Beware, oh Internet, of the Scourge of Criminals 
attempting to forge the image of my Inestimable Personage, and do not DARE 
to be fooled by these Base Mockeries of Communication!"  The only 
reasonable response from everyone else is somewhere between "Huh?" and 
"Get real."

If the ABA or the FDIC published a list of domains used by member banks to 
send signed transactional mail, I would find that really useful.  A list 
of people who think they are as threatened by forgery as those banks is 
useless other than for entertainment value.

So that's the problem with SSP.  Whatever your policy is, unless you're 
someone I already have reason to be interested in, I don't care.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

* - Lest anyone wonder, on the 500 pound gorilla scale I rate about an 
ounce and a half.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Sat, 5 Aug 2006 17:58:08 -0700

A DKIM client authentication method validates the DKIM client.

A DKIM Client Policy defines whether:

  - The entire domain subject to the policy must adhere to a DKIM  
client authentication method.

  - All messages from a DKIM client within this domain must be signed.

  - All messages from a DKIM client within this domain must be signed  
by this domain.

An illustrative example of a DKIM authentication method could be:

_dkim.host-name-0.example.com	A	1.2.3.4
				A	1.2.3.5
				A	1.2.3.6
				A	1.2.3.7

EHLO _dkim.host-name-0.example.com

_DKIM_CP.example.com		DKIM-CP	"All clients DKIM authenticate & "All  
clients sign all"

  or

_DKIM_CP.example.com		DKIM-CP	"All clients DKIM authenticate & "All  
clients signed all by this domain"

Establishing a domain name evaluation early better defends the  
resources used to process DKIM signatures.  Use of the _dkim prefix  
eliminates any discovery process of the authentication assured to  
work for the client.  With the _dkim prefix, the associated A records  
must be present.  The "All clients DKIM authenticate" could be  
implied by the presence of a DKIM From policy where this policy could  
then also delineate the signing requires of the client.  Combining  
this policies into one record could be done to reduce the number of  
transactions.

-Doug

---

From: <[email-masked]>
Date: Sat, 5 Aug 2006 21:18:55 -0400

Well, some extremely useful information here. Thank you, I was starting
to wonder. Now lets try the other case

"if you are running the parlous operating system that shall not be named
for fear of dudgeous lawsuits beware of mails that look like mine that
are not, and don't come whining to me because.... wait, you will be too
busy pretending to be me"

I hear all the time from the gorillas who insist that everyone wants
their mail, none of it is ever spam and how dare my users gleefully
insist that it is.

All DKIM does for me is to get a case of who to kvetch at when I get
some real nasty spam and senders policy will assist me in determining
that.

In no way does accreditation=DKIM 
Thanks,

Bill Oxley 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John L
Sent: Saturday, August 05, 2006 8:57 PM
To: DKIM List
Subject: [ietf-dkim] The problem with sender policy

attempting to forge the image of my Inestimable Personage, and do not
DARE 

If the ABA or the FDIC published a list of domains used by member banks
to 
send signed transactional mail, I would find that really useful.  A list

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for
Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: John L <[email-masked]>
Date: Sat, 5 Aug 2006 21:20:47 -0400 (EDT)

> some real nasty spam and senders policy will assist me in determining

Pretty much.  If you have a whitelist, it'll also help you recognize 
people on the whitelist.

> In no way does accreditation=DKIM

Quite right.  That's why Paul and I set up DAC.

Regards,

---

From: Mark Delany <[email-masked]>
Date: Sun, 6 Aug 2006 01:30:01 +0000

On Sat, Aug 05, 2006 at 07:05:16PM -0400, Hector Santos allegedly

> Having SSP still in play will not serve your business well.

Hector. Most of us on this list are in the email business - including
you - as I understand it. If we start slinging arrows at anyone who
has a business connection, most of us would have to recuse ourselves,
would we not?

John has a business interest, you have a business interest, I have a
business interest. So what? I expect that we're all smart enough to
recognize technical merit over business interest and respond
accordingly.

Let's face it, this is a list chock full of cynics. John has a zero
(or less) chance of coercing you, me, or the other hundred folk on the
list.  John is not so dumb, he knows the obvious.

I will say that that I think that John's DAC venture is exactly what
we had hoped would be an outcome of this process. May there be many
more DAC competitors emerging as DKIM is deployed.

Mark.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 5 Aug 2006 18:54:03 -0700 (PDT)

>> In no way does accreditation=DKIM

But policy records are in a way. Lets look at it in general -
policy record is just a statement of what sender believes to
be true about their email system setup and how receiver can
use the email..

Accreditation is basically the same thing but the difference
is that its not sender directly saying it but that sender asked
(paid) some other party to provide this information to the
public (and depending on how good accreditation service is
they might go through some sort of checks to verify its true;
in the end its still that accreditation service has been paid
by the sender and is thus not true neutral party no matter
what they say). Another slight difference is that accreditation
focuses more on the "use of the email" rather then email system
setup. Reputation is actually highly similar too but in that
case it only answers about "use of the email" from perspective
of 3rd party that has [hopefully] nothing to do with the sender.

We could in fact have a system/protocol that accommodates all of
these at once. The difference would be that for "policy record"
the answer would be found directly at the service run by the
sender (or whoever appears to be the sender in case you need
to check on that). In the case of accreditation you'd ask some
3rd party chosen by the sender where as with reputation you'd
ask 3rd party chosen by the receiver. The questions asked could
all actually be the same and could even be if that party always
sends signed email.

As far as example given by John [FDIC and banks], I think its
special corner-case because banks members of FDIC so what
FDIC does is answer a question if they are member or not
and there is no doubt that FDIC is only place to reliably
find this out. However if a bank were to have paid some
other 3rd party to say this bank belongs to FDIC, I'd not
believe it much more then if bank itself said that directly
(in fact lawyers would say it should be believed less).

---

From: Douglas Otis <[email-masked]>
Date: Sat, 5 Aug 2006 19:35:46 -0700

On Aug 5, 2006, at 7:24 PM, Dave Crocker wrote:

> Ad hominem attacks on IETF lists is worse than merely rude.  It is  
> prohibited by
> IETF rules.
>
> If there is a problem with someone's statements, attack the merits,  
> not the speaker.

Well said.

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 5 Aug 2006 23:34:30 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>

> If there is a problem with someone's statements, attack the
> merits, not the speaker.

According to John, no one understands SSP, we are in a SSP FOG, says there
is no logic to it,  indicates the IESG will not consider SSP, suggests
specifications has yet to be invented, begins to convince Michael to doubt
it, and therefore it will suit us all better if we drop SSP and begin to use
reputation systems.  John crossed the fine ethical line in cooperating
engineering when he has no interest in using SSP, is actively against it in
every shape and form, and begins to promote his own business.

That is slap in the face in all the work people are doing and to do
understand SSP and have no conflict of interest in pursuing its engineering
for the greater good of the community.

I am not the only one who feels this way.  But I am sorry I had to point it
out.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 05 Aug 2006 19:24:02 -0700

> has a business connection, most of us would have to recuse ourselves,

Ad hominem attacks on IETF lists is worse than merely rude.  It is prohibited by
IETF rules.

If there is a problem with someone's statements, attack the merits, not the speaker.

d/

-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 04:33:24 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>

> 1. I sign everything.
> 2. I send no mail.

Dave, these are ok, but please consider the implementations considerations
that were already discussed in the old list and well as here.

Lets assume these are it.  How do implement it?

Lets use an email example:

   From: abc.com
   DKIM-Signature: d=xyz.com

In order to satisfy the checks, my verifier needs to a DNS SSP lookup.

If the policy said "I send no mail", then is strong evidence that this
message is unauthorized and unacceptable.  Agreed?

If the policy said "I sign everything", then the existence of the
DKIM-Signature is checked.  If it was missing, then is strong evidence that
this message is unauthorized and unacceptable.  Agreed?

But it does exist, so you have two security questions here:

    - Was a signature expected?
    - Was a 3rd party signature expected?

Lets handle the first question first - "Was a signature expected?"

It is quite conceivable that during the migration period, many systems will
implement an DKIM verifier first before completely the DKIM signing
component.  During this phase, it would not be signing message, so no
message is expected to be sign.

Understandibly, some people said that checking the KEY will fail so this is
basically the same "I never sign mail."

But is not a 2nd DNS lookup. By simply adding policy "I never sign mail",
then the 1st SSP lookup would satisfy this requirement in an efficient and
optimal manner.

There could be other reasons why one may not want his mail signed beside
migrations, but migrations, to me, seems to be a good reason, in fact, I can
see us completing the DKIM verifier first before we get into the signing
part.  So I see this as a reasonable and practical situation.

Now, the more complex issue is the second question "Was a 3rd party
signature expected?"

I believe this is where the major source of contention in simplifying the
policies vs. enhancing the security of the system.

But consider this:  During the 1st SSP lookup, if there was a policy "Only I
sign mail", then we immediately resolve this condition with additional
overhead or change in logic.   The verifier simply sees the d=xyz.com and it
will immediately now this is not a desirable condition expected by the
domain.  1 DNS lookup is all that was required.

So in opinion, there is sound technical reason to include:

    "I never sign mail"
    "Only I send mail"

I hope this make sense and I hope you take the time to review my comments
here and see it from a software implementation standpoint.

I just want to add that my #1 goal is to optimize rejection with 100% True
Negatives at the transport level by eliminating the most obvious failure
conditions that can occur.

All the rest will be passed to other MFA (Mail Filter Agents) including
Reputation Systems.

---

From: Douglas Otis <[email-masked]>
Date: Sun, 6 Aug 2006 03:01:53 -0700

>     - Was a 3rd party signature expected?

Rephrase:
  Is this a designated signing domain?
  Do non-designated domains carry messages on behalf of this domain?

Non-designated domains carrying messages on behalf of a domain might  
be a mailing-list, an e-invite, a news article, an auction bid, etc.   
Although a domain may indicate that they have designated domains that  
sign all their messages, other non-designated services may not.   
Whether these other non-designated services are being used could be  
stipulated in the policy as perhaps representing an open/closed list.

> basically the same "I never sign mail."

"I never sign" introduces a state tested against an invalid signature  
where not finding a key for a DKIM signature should be fairly  
suspicious by itself.  "No mail sent" provides a clear disposition  
for an invalid signature.  One would have to wonder about the  
motivation for making a "I never sign" assertion and how many would  
bother with it.

> then the 1st SSP lookup would satisfy this requirement in an  

This seems to suggest that looking for policy precedes verification.   
Policy may or may not exist and may require several transactions.   
DNS transactions take awhile. The reason for questioning this, is  
that an open empty list should be defined as maybe signs as would be  
applied to any non-designated domain that might carry mail for the  
 From domain.  I doubt that many bad actors will attempt to spoof  
signatures without also knowing where a key exists within the domain  
to obtain a modicum of credibility.

> So in opinion, there is sound technical reason to include:

Fine.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 Aug 2006 11:23:43 +0100

Hector,

Hector Santos wrote:
[...]
> Having SSP still in play will not serve your business well.

That mail is entirely out of order.

There are IETF rules for handling such mis-behaviour. Let's not go
down that road,

Regards,
Stephen (definitely wearing WG-chair hat).
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 06 Aug 2006 12:03:06 +0100

Hector,

I missed this one earlier.

> badly with obvious signs of conflict of interest by specific individuals to

This is also out of line. You're accusing someone of bad faith (which
is totally out-of-line) and without even waiting to see the I-D (which
is ridiculously premature).

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 07:41:41 -0400

What is out of line is one who is suppose be writing the design requirement
has suddenly decided that it probably isn't a good idea after all.

What's wrong with that picture?  Ban me if you must, I will not lower my
standards, my ethics nor morals.  Never.

----- Original Message -----

From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, August 06, 2006 7:03 AM
Subject: Re: [ietf-dkim] SSP requirements

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 08:05:05 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> which is ridiculously premature.

which begs the questions;...

What is wrong with SSP-01?    Why start at ground zero with the premise "we
don't understand SSP" which only serves to perpetuate chaos when in fact, it
is well documented?

SSP-01 only needs some fine tuning with the "allow domain list" or as Doug
calls designated and non-designated list and we are practically done.

Nearly all the policies discussed in the last few weeks, if not all, are
covered in a document created last year.

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 06 Aug 2006 15:25:10 -0500

> finally came to me: senders are not the right people to judge their
 > own importance.

In my view, SSP is not a "judgement of one's own importance".  It's 
simply an advertisement to others through which some assessment of 
authenticity might be usefully gleaned and potentially used.  I see 
nothing self-absorbed or arrogant in providing that advertisement.  To 
the contrary, I see it as useful to the email community at large.

 > When I think of SSP records saying dump mail if it's not signed, I see
 > a bunch of tiny gorillas*, beating their teensy chests and saying in
 > high squeaky voices, "Beware, oh Internet, of the Scourge of Criminals
 > DARE to be fooled by these Base Mockeries of Communication!"

First, SSP doesn't say "dump mail if it's not signed" -- that might be 
an outcome but that's up to the receiver and needn't be an SSP mandate. 
  Second, if one ignores the irrelevance of words like "teensy" and 
"high squeaky voices" etc it becomes apparent that every gorilla 
(regardless of size) has the right (and duty) to protect his domain from 
abuse as far as possible.

-- 
Arvel

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 09:43:52 -0400

> Having SSP still in play will not serve your business well.

How many +1's am I allowed to put on this?
+1

Fog?! Give me a break. I have caught up with what is going on in a
matter of days and I am NOT confused or in a fog. I have disagreements
and suggestions, but by no means do I think we are tripping around in
the dark here.
To say there have been no suggestions that you have heard from
something less strict than "I sign all" means you have not read a word
I and others have said and especially over the last few days.
In the movies when the Whig's pretend not to hear the cannon fire,
it's funny- I'm not laughing.
Stop trying to steer the ship from the purser's vault.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 09:55:39 -0400

I believe that without policy records (we can discuss the particulars
later), the rest is useless.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 12:29:31 -0400

> being allowed to fail as currently defined in RFC2821.

I like this idea...
But not for stringency.. more for reducing the number of lookups.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 09:50:13 -0400

I apologize. I meant to say... stop trying to steer the ship from the
sea locker.
What I said could have connotations that I did not intend at all. I apologize.

Regards,
Damon Sauer

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 7 Aug 2006 20:37:29 -0400

On Sat, Aug 05, 2006 at 08:56:37PM -0400, John L wrote:

> senders are not the right people to judge their own importance.

So, I've been thinking pretty much the same thing after seeing all the
recent threads going on. I'm going to go out on a limb and say that
DKIM and related tech are the wrong approach.

There is an interesting quote from J.P. Rangaswami in the Sept. issue
of Linux Journal (pg 44):

"If you go to many Eastern countries, _identity_ is not about who I am,
because the I is very unusual. Identity is about _what I belong to_.
Identity is a statement of the community that I belong to. Identity is
a statementof things that I will associate with me, that empower me as
a result of belonging to something..."

There are many discussions about 'which Identity' to use in 'Sender
Authentication' schemes. I think it is time to create a new Identity
simply because it seems all the current identities have their own
flaws.

Once that is done, something that allows a Sender and Receiver to
establish a relationship and trust with each other can be built. The
system I'm thinking about allows a Sender to express the desire for a
relationship and only when the Receiver _wants_ this relationship does
the trust mechanism come into play.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

---

From: <[email-masked]>
Date: Mon, 7 Aug 2006 20:47:38 -0400

We already have that, CORBA, EDS, FTAM, MQ Series, no need to reinvent
the wheel. I have done FTAM over port 25 to get around firewall
issues,,,,
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeff Macdonald
Sent: Monday, August 07, 2006 8:37 PM
To: John L
Cc: DKIM List
Subject: Re: [ietf-dkim] The problem with sender policy

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Aug 2006 18:03:34 -0700

> DKIM and related tech are the wrong approach.

Feel free to start a separate effort to develop the 'right' approach.

It strikes me as unlikely that pursuing the question in this venue, at this
stage of effort, is likely to be productive for either approach.

d/
-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 8 Aug 2006 04:55:49 -0400

----- Original Message -----
From: "Mark Delany" <[email-masked]>
To: <[email-masked]>

> more DAC competitors emerging as DKIM is deployed.

Mark,

But will there be a standard?   Market segment XYZ uses this? Market segment
ABC uses that?

Will DKIM-BASE become a "Batteries Required" protocol?

The last time this happen it wasn't a very good experience for us during the
early automated electronic merchant days where there was use 1 or 2
providers (years before the paypals, etc.) and your online order entry and
sales product designs where tightly integrated with these few early merchant
providers.   When customer support issues ensured with these vendors, we
felt the blunt of  PR issues by forcing our customers to use proprietary
"Batteries Required" concept.    We lost customers because of this.  I vowed
never to repeat locking a solution to specific vendors again.

What we are doing here is exposing a rather fuzzy,  unprotected DKIM-BASE
protocol which hedges it future on unknown, yet to be delivered,
trusted-layers  protocols (Reputation Services).

SSP should be an open standard.  It still doesn't take away the need for
DKIM based reputation systems.  But in my opinion, that's a different layer
altogether.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 8 Aug 2006 10:32:38 -0400

> stage of effort, is likely to be productive for either approach.

Sorry, I didn't mean to insult those who have been working very hard at
this. If anything, all this hard work has made it very clear to me that
it is hard to ask the right question. 

At http://mipassoc.org/dkim there is this:

DKIM ... for Consideration as a new E-Mail Standard to Address E-Mail Forgery
and Phishing.

It seems the question that was asked was "how do we make the message
tamper proof?"

And perhaps I need to review the DKIM website. I went out on the 'limb'
sleep deprived (a newborn has arrived), and as that limb broke, I
remembered that DKIM is not a complete solution.

Which means there are other questions to be asked.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 08 Aug 2006 08:17:46 -0700

> Will DKIM-BASE become a "Batteries Required" protocol?

Bad actors are able to sign with DKIM and establish any favorable
policy.  Good actors may be less inclined to assert the same policy when
it might cause a percentage of their email to be rejected or discarded.
Bad actors already expect many of their messages to be rejected, and
don't care what happens when common services are used.  A bad actor
might try spoofing as a common service, but likely with less success. 

An alignment with the From, signing domain, and a policy record will not
curtail spoofed return paths without also causing the loss of valid
emails from good actors.  A DKIM client policy may help, but not the
DKIM From policy.  Even here, there can be no absolute policy asserted
without causing loss of email for a typical good actor.  Don't expect
the bad actor to care.

Devising a set of obstacles through which email is to navigate will not
eliminate a need to track source histories.  Only this history curtails
email from bad actors.  When doing so, this history must track an
unlimited number of domain names.  White-listing may bypass some
messages from the tracking process, however a growing percentage will be
from a highly diverse array of domain names.

Either the goal is to accept email from just the mega-domains (which
will continue to have their abuse issues), or something is planned that
is not apparent. The obstacle course favors the bad over the good actor.
So don't throw out your batteries, they are still needed to retain your
history information.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 16:24:00 +0100

Yet another post that seems (hard to tell) to contain no
new technical points that may help us in working on SSP.

Please desist,
Stephen.