Subject: Re: [ietf-dkim] New Issue: Applicability of SSP to subdomains

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Dec 2006 14:46:31 -0800

I'd like to bring up this topic again, which I raised on November 9 and 
got only a little discussion and didn't make it into the issue tracker.  
The various drafts that have been proposed for SSP differ substantially 
in how they address subdomains, and I'd still like to understand whether 
this is an SSP requirement or not.

-Jim

Jim Fenton wrote:
> In the process of preparing my slides for the recent WG meeting, it 
> occurred to me that there is no requirement in the SSP requirements 
> doc for SSP to apply to subdomains of a given domain.
>
> The issue is this:  If an SSP record exists for example.com saying, 
> for example, "I sign everything", it's probably not a good idea if an 
> attacker can avoid that policy by sending mail from (for example) 
> mail.example.com.  The recipient is still likely to associate the 
> message with the example.com domain.
>
> This can occur whether or not there actually is a mail.example.com 
> subdomain, or some other sort of record (such as an A record) for 
> mail.example.com.
>
> It's also probably a good idea to require a flag in SSP that indicates 
> whether the policy published there is intended to apply to 
> subdomains.  This would be used when the subdomains are under separate 
> administrative control, and there is a desire to avoid having a 
> parent's SSP "bleed through" to subdomains.
>
> This also needs to be done to (sub-)*domains, e.g., 
> q.w.e.r.t.y.example.com.
>
> -Jim
>
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Dec 2006 15:11:27 -0800

On Dec 7, 2006, at 2:46 PM, Jim Fenton wrote:

> I'd like to bring up this topic again, which I raised on November 9  
> and got only a little discussion and didn't make it into the issue  
> tracker.  The various drafts that have been proposed for SSP differ  
> substantially in how they address subdomains, and I'd still like to  
> understand whether this is an SSP requirement or not.

This concern incorrectly assumes protection is afforded as a type of  
prohibition.  Such a prohibition fails with respect to EAI, as this  
eliminates reliance upon visual inspection, as well as changing  
headers viewed by the recipient.

When the protection afforded by DKIM is abased upon an annotation of  
the "recognized" email-addresses "associated" with a valid signature,  
then there is _no_ need to have policy be associated with sub- 
domains.  There is also _no_ need to search for policy either.   
Without an "associative" mechanism, the message simply does not  
receive any annotation.  Nothing is blocked, but then nothing gets  
annotated either.

DKIM requires some form of annotation as the signature is invisible  
by design.  The "recognition" of the email-address should be based  
upon actual email-addresses comparisons that have been previously  
retrained by the recipient.  These retained email-addresses might be  
in the form of an address-book or a DAC compatible list.

It is hard to imagine chasing 2 million new domains every day.  It  
does not matter what policy is required, or what hoops bad actors  
jump through, they will not be limited by these requirements.  Just  
the opposite.  Nor will reliance upon visual examination offer any  
protection either.  Just the opposite.  There is a large part of the  
world that does not even use ASCII email-addresses.  : )

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 07 Dec 2006 20:33:13 -0800

Doug,

I'm really confused by your reply.  The question is simply, "should it 
be possible for an SSP record published by example.com to also apply to 
sub.example.com [for any value of sub]".  I don't see how it relates to 
EAI, annotation, and so forth.

I interpret your response as expressing the position that this should 
not be a requirement.  Let me know if I have that wrong.

-Jim

Douglas Otis wrote:
> then there is _no_ need to have policy be associated with 
> sub-domains.  There is also _no_ need to search for policy either.  
> DKIM requires some form of annotation as the signature is invisible by 
> design.  The "recognition" of the email-address should be based upon 
> actual email-addresses comparisons that have been previously retrained 
> by the recipient.  These retained email-addresses might be in the form 
> of an address-book or a DAC compatible list.
>
> does not matter what policy is required, or what hoops bad actors jump 
> through, they will not be limited by these requirements.  Just the 
> opposite.  Nor will reliance upon visual examination offer any

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 7 Dec 2006 21:49:16 -0800 (PST)

On Thu, 7 Dec 2006, Jim Fenton wrote:

> I'm really confused by your reply.  The question is simply, "should it be 
> possible for an SSP record published by example.com to also apply to 
> sub.example.com [for any value of sub]".

Its not quite that simple, the issue is really should you go out of
your way to solve issue which is more fundamental due to missing
feature in current DNS protocol and its wildcards (especially if
that involves complicating with extra queries...). My view is
somewhat similar to Phillip - I think this issue should be worked
on in general, but I don't think it should be done in the context
of this WG (i.e. not part of your protocol specs).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Dec 2006 01:15:32 -0500

Jim Fenton wrote:

> The question is simply, "should it 

Yes, but allowance is made for the sub as well.  Isn't the specs 
currently written as such?

We had a lengthy thread on this a few months back.  I think this is a 
matter of what we believe is more efficient and the order of the lookup 
and how the BASE should cover or be consistent with the entire sub-domain:

Example:

Given domain:  D.C.B.A

Lookup order #1

     D.C.B.A
     C.B.A
     B.A
     A

or Lookup order #2

     A
     B.A
     C.B.A
     D.C.B.A

I believe the specs currently says order #1 is to be done.  But I think 
there is valid consideration that a base domain should be consistent 
with the authorization of the sub-domains.

To me, the lookup order #1, makes more sense, although probably less 
efficient when a DOMAIN doesn't probably set his SSP records right and 
forces redundant NXDOMAIN or fails on the receivers:

     D.C.B.A   NXDOMAIN
     C.B.A     NXDOMAIN
     B.A       NXDOMAIN
     A         SSP record found

That would be my only technical concern about this.  But I think we have 
no choice here because I think we ant to allow a DKIM DOMAIN to offer 
different sub-domain policies.

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Dec 2006 01:40:24 -0500

william(at)elan.net wrote:
>> be possible for an SSP record published by example.com to also apply 
>> to sub.example.com [for any value of sub]".
> 

Good point, but in lieu of industry wide support for wild cards, we do 
have the fallback logic of doing direct lookups.

Yes, absolutely, not ideal and probably can create more redundant DNS 
query faults on the net than we really care for, but we do need the 
general idea worked out as you elude to above.

To me, the question is valid:

Does my received do a lookup order of:

      D.C.B.A
      C.B.A
      B.A
      A

or just start at the BASE first?

I think the answer lies on the application side:  Should DKIM/SSP offer 
domains the ability to have two or more policies with the same base domain?

Example:

    public.santronics.com    - a more relaxed option policy
    santronics.com           - exclusive policy

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Fri, 08 Dec 2006 00:28:11 -0800

On Thu, 2006-12-07 at 20:33 -0800, Jim Fenton wrote:

> to sub.example.com [for any value of sub]".  I don't see how it
> relates to EAI, annotation, and so forth.

Blocking "exact" email-addresses not "properly" signed assumes
recipients see and visually recognize addresses.  When various forms of
display-names are common, and when EAI changes headers to fully
introduce UTF-8, no assumption or assertion that recipients will benefit
by blocking "exact" email-addresses should be made.

This mode of blocking is unsafe and breaks email in many cases.  A
superior means to prevent spoofing and provide better protection is to
associate email-addresses with signing-domains, where annotations can
then be applied.  This is safe, does not break email, and works after
EAI is introduced.

With annotation rather than blocking as a basis for protection, there is
no danger created by use of a sub-domain that misses a policy providing
an association.  Annotations are simply not applied.  In an era where
registries accept millions of new domains each day without payment due
to fraud, there can be no expectation vsiserifying control of a domain
offers proof of goodness or abates abuse.

> not be a requirement.  Let me know if I have that wrong.

Correct.  

There is no need to hunt for policy in higher domains.  There should be
no assertion that extending policies into sub-domains offers protection
either.  Such claims would be imprudent.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Fri, 08 Dec 2006 10:32:25 -0800

Hector,

Hector Santos wrote:
> Jim Fenton wrote:
>
>> The question is simply, "should it be possible for an SSP record 
>> published by example.com to also apply to sub.example.com [for any 
>> value of sub]".  
>
draft-allman-dkim-ssp does attempt to address subdomains, but there are 
problems with its methodology that I presented at the WG meeting. I know 
you weren't there, but if you look at the slides at 
http://www3.ietf.org/proceedings/06nov/slides/dkim-3.pdf, especially 
slide 4, it discusses this further.

But this question is about the SSP requirements draft.  Currently the 
requirements draft is silent on this issue, and not all of the drafts 
presented at the WG meeting address propagation of SSP to subdomains, 
which is what prompts me to ask the question.  Lookup order would then 
be a secondary question if we decide that we need to address subdomains.

-Jim

---

From: Damon <[email-masked]>
Date: Fri, 8 Dec 2006 14:40:43 -0500

Hector,

I believe they should.
Many mail systems I have been involved with have things like:

news.example.com
critical.example.com
mail.example.com
statements.example.com
etc.
Some of these sub domains are outsourced to ASP's.

While there is an issue with wild cards, I think that if a site wished
to implement this type of solution, un/wild carding the domain would
be on the check list of things to do to implement the solution. Or..
could the parent domain provide the information for each of its sub
domains in its record somewhere?

Regards,
Damon

---

From: Eliot Lear <[email-masked]>
Date: Fri, 08 Dec 2006 21:08:53 +0000

Jim,

I'm not sure I fully understand the threat.  If an attacker is attacking 
from mail.example.com, then mail.example.com must have been delegated to 
first in example.com.  Otherwise, there would be no lookup for an SSP 
record in mail.example.com, right?

I had thought the concern was the wildcard concern about how much trust 
is afforded between superior and inferior domains.  In that case, I 
answer, "you pays your money you takes your chances".  Don't like a 
particular superior?  Find another.  If you can't for policy reasons, 
then that's not a technical problem.

What do I have wrong?

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Fri, 08 Dec 2006 15:23:58 -0800

Eliot Lear wrote:
> Jim,
>
> I'm not sure I fully understand the threat.  If an attacker is 
> attacking from mail.example.com, then mail.example.com must have been 
> delegated to first in example.com.  Otherwise, there would be no 
> lookup for an SSP record in mail.example.com, right?
>
> I had thought the concern was the wildcard concern about how much 
> trust is afforded between superior and inferior domains.  In that 
> case, I answer, "you pays your money you takes your chances".  Don't 
> like a particular superior?  Find another.  If you can't for policy 
> reasons, then that's not a technical problem.
>
> What do I have wrong?
It's fairly simple. Let's say I have a policy record setup for:

_policy._domainkey.example.com: "policy=I-sign-everything;"

Then if there's unsigned mail for [email-masked], I look it up
at example.com, I see that unsigned mail is bogus, life is good.

So attacker now gets smarter and sends as [email-masked].
Is there a policy record there? No. Can I populate every possible
subdomain there? Not with DNS wildcards, therefore no. Uh-oh.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Dec 2006 21:50:22 -0500

> slide 4, it discusses this further.

Thanks, printing it out now.

> be a secondary question if we decide that we need to address subdomains.

I agree. I think it fits and we need it simply because from the domain 
owner standpoint sub-email-domains will mostly likely have different 
purposes for their existence.  Everyone may apply it differently, but I 
think it fits for DKIM purposes as well.

Technically, look at the print slide #4, the "Solution:" item:

Given D.C.B.A, does this imply the lookup is?

   A
   B.C
   C.B.A
   D.C.B.A

and you stop at the first NXDOMAIN?

So for example, lets say their are policies written for

   A             Policy 1 - company wide
   B.C	        Policy 2 - subdomain
   C.B.A         Policy 3 - subdomain
   D.C.B.A       NXDOMAIN

Which policy is applied for D.C.B.A?    Policy 3?

Did I read that slide right?

If so, what is technically wrong starting at the bottom first, with the 
direct domain first, then if NXDOMAIN, go to the next base domain?

hmmmm, I think I see why you want to start at the base first, to cover 
the entire domain policy.

But maybe we need a flat in the policy that says the specific sub-doman 
policy should be looked up.

So you always start at the base (A), then if the flag does not say to 
try the sub-domain, then this can serve as a short circuit to
minimize lookups.  But if it does, then the direct lookup is done.

Make sense?

---
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Dec 2006 22:13:04 -0500

>subdomain there? Not with DNS wildcards, therefore no. Uh-oh.
Well, I guess my question would be does a.b.c.d.example.com exist?  If not 
I think perhaps I don't want their mail in any case.  

If SSP limits itself to domains that exist, then doesn't that simplify 
things.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Sat, 09 Dec 2006 04:02:59 -0800

> If SSP limits itself to domains that exist, then doesn't that simplify 
Define "exists". That there's an A record there? That it's pingable? What?
That's pretty much the root of this problem -- you need to have coverage
and it needs to conform more or less to what's legitimately deployed. I
for one would like to see more creative suggestions in the solution realm
because nothing I've seen seems especially satisfactory and strikes me as
meeting the conform test at the same time.

But the main question here is really for requirements: should defining
some method be a requirement. I can read your response both ways.

       Mike

---

From: Graham Murray <[email-masked]>
Date: Sat, 09 Dec 2006 12:38:50 +0000

Michael Thomas <[email-masked]> writes:

> Define "exists". That there's an A record there?

That it has at least one of A, AAAA, MX, or CNAME records.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Dec 2006 11:05:32 -0500

> That it has at least one of A, AAAA, MX, or CNAME records.

That's what I was thinking.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 9 Dec 2006 11:24:58 -0500

On Saturday 09 December 2006 07:02, Michael Thomas wrote:
> > Well, I guess my question would be does a.b.c.d.example.com exist?  If
> > not I think perhaps I don't want their mail in any case.
> >
>From a requirements perspective, I think providing policy for non-existent 
domains is explicitly NOT a requirement.  For a domain to be covered by SSP, 
it MUST exist.  I like Graham Murray's definition of exists.

Once you limit yourself to extant domains for SSP, then I think that (with the 
limited exception of domains that exist solely due to DNS wildcards) there is 
no requirement to deal with subdomains.  An explicit SSP can be published for 
every domain.

So, then the question becomes are wildcards worth the trouble?  I'd say not, 
but they are part of the existing infrastructure, an so I imagine they can't 
be ignored.

Going back to Jim's slides that he reference earlier, I think there is a 
requirements trade between slides 3 and 4:

http://www3.ietf.org/proceedings/06nov/slides/dkim-3.pdf

Slide 3 describes using a new RR type for SSP.  Once you use a new RR type at 
the domain level (not as an underscored domain name) then as I understand it, 
SSP records could be wildcarded.  So, if you have the ability to wildcard SSP 
records, (given SSP only covers domains that exist) then there is no 
requirement for hunting for parent/sub domains.  The problem in Slide 4 is, I 
think resolved (NXDOMAIN is enough of an answer).

Slide 4 describes a problem is the SSP record cannot be wildcarded which, I 
think, drove Jim's original question here about hunting for 
parent/sub-domains.

Back to requirements...

It should explicitly NOT be a requirement for SSP to cover non-existant 
domains.

Either:

SSP records MUST be wildcardable for the domains the relate to.

or

The search for SSP records much include looking to parent domains.

I don't think we need to do both.

Perhaps for now, both concepts could be encapsulated in a higher level 
requirement that says that SSP records must be fetchable for domains that 
only exist due to DNS wildcards and either of those approaches is a design 
for meeting those requirements.

I guess there's a reason you could read my response both ways....

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sat, 9 Dec 2006 19:02:30 -0800

On Dec 9, 2006, at 8:24 AM, Scott Kitterman wrote:

> From a requirements perspective, I think providing policy for non- 
> existent domains is explicitly NOT a requirement.  For a domain to  
> be covered by SSP, it MUST exist.  I like Graham Murray's  
> definition of exists.

An Address RR could be for anything.  Blocking "improperly" signed  
messages would require discovery of a policy RR indicating  
exclusivity (all "From" headers are assured to be signed).  The  
likely outcome of such an assertion is disabling use of mailing- 
lists.  The discovery process for this "rare" assertion must be done  
for each "improperly" signed message using one these methods:

a) search for a prefixed policy RR up the label tree ignoring non- 
existence.

b) check for an MX RR or Address RR and then assume coexistence of a  
prefixed policy RR.

c) define a new RR type for policy and publish wildcards at each  
label blocking synthesis.

d) define a new RR type for a pointer of common locations for policy  
records and publish wildcards at each label blocking synthesis.

-Doug

---

From: John Levine <[email-masked]>
Date: 10 Dec 2006 03:57:15 -0000

>subdomain there? Not with DNS wildcards, therefore no. Uh-oh.

We ran into just this problem while defining CSV, the "like wildcards
except that we use prefixes" problem.  Having gone around this a lot
of times, I think I can say with confidence that there are a lot of
hacks, some rather clever, but there is no good solution.

The suggestion that SSP would fail if a domain doesn't have at least
one of MX, A, or AAAA (perhaps with intervening CNAMEs) is intriguing,
but it would have the effect of adding the same condition to RFC 821
or 2821 since SSP users would thereby decree such mail to be
undeliverable..  I entirely agree that it is unlikely that one will
get legit mail from an address without enough DNS to write back, but
this is severe standards mission creep.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Dec 2006 23:05:31 -0500

Douglas Otis wrote:
>> From a requirements perspective, I think providing policy for 
>> non-existent domains is explicitly NOT a requirement.  For a domain to 
>> be covered by SSP, it MUST exist.  I like Graham Murray's definition 
>> of exists.
> 
> messages would require discovery of a policy RR indicating exclusivity 
> (all "From" headers are assured to be signed).  The likely outcome of 
> such an assertion is disabling use of mailing-lists.  

First isn't that a contradiction?  If a company invest in DKIM and 
prefers to use an exclusive policy for some of its high value domains, 
it would be highly probably that it be done on the basis to stop such 
public external usages.  That would be one goal. Protection from 
unauthorized usage of their domains.

Note, this doesn't stop a company from using using a Mailing List Server 
for original signed distribution.   But if you are talking about open 
ended mailing list such as this one, it would be an contradiction to 
define a exclusive policy and continue to behave in this open "laissez 
faire" promiscuous manner.

Second, this issue of MAILING LIST SERVER (MLS) really has nothing to do 
with SSP but with DKIM-BASE mail integrity issues.  Thats the problem 
with a MLS, not SSP.  SSP is really the easy part when it comes to a 
MLS.  You could throw SSP away and you STILL have the mailing list 
DKIM-BASE mail integrity problems.

The problem is the idea of MLS resigning in order to correct the DKIM 
transaction of a broken original signature.   This is where SSP plays a 
role in defining the 3rd party authorization, otherwise, SANS SSP, you 
have a major threat with bad actors using a MAILING LIST to mask a 
broken original signature with a resigning.

---
HLS

---
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Dec 2006 00:42:01 -0500

> this is severe standards mission creep.

I'm not suggesting SSP fails, just that providing an SSP for non-existing 
domains is not a requirement.  If the domain doesn't exist, then SSP can say 
nothing either way.  It's outside the scope of this protocol.

One could regard this, potentially, as a gap in the protection (such as it is, 
let's not argue that again) provided by SSP, but I think non-existence of a 
domain is reason enough to be suspicious.  That doesn't say one couldn't 
accept such a message, if you do, you are welcome too, I just don't think we 
should complicate SSP by attempting to require non-existent domains be 
protected.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Dec 2006 1:08:02 -0500

Doug,

I think you may have replied to the wrong message.  I wasn't able to 
related what I wrote in my message to which you were replying and anything 
in your reply.

Scott K

---

From: John Levine <[email-masked]>
Date: 10 Dec 2006 14:06:33 -0000

>> undeliverable. ...

>One could regard this, potentially, as a gap in the protection (such
>as it is, let's not argue that again) provided by SSP, but I think
>non-existence of a domain is reason enough to be suspicious.

No need to argue, it's obvious that it's a gap.

We have now descended to the level of protocol design by winking and
nudging.  It is quite reasonable to reject mail from non-replyable
senders, for any definition of sender you want.  It would be a fine
change to 2821 and 2822 to say so.  But that is not what they say now.

I hope that it is a given that any proposed extension to Internet mail
has to be opt-in, that is, if senders or receivers don't implement it,
they continue to operate the way they always have.  But what you're
saying to recipients is that if you want to get the benefits of SSP,
wink wink nudge nudge, you might want to make this other change to
your SMTP implementation.

If SSP requires a change to SMTP, which is what you've been dancing
around, please say so directly.

But it occurs to me that even in the unlikely event that 2821 were
updated to tell people to reject non-replyable sending domains, it
still wouldn't make it possible for SSP to handle subdomains.  There
aren't a whole lot of DNS wildcards in the wild, but one of the few
places where they work reasonably well is with MX records.  (Two
actual applications are for the obsolescent sendmail setup that puts
the host name into the return address, e.g. mail from [email-masked]
comes from [email-masked], and subaddresses baked into the
domain name, where you can write [email-masked] as
[email-masked].)  If you have a wildcard MX, or for that matter a
wildcard A, there's no way to cover its names with a prefixed record
such as SSP.

So I guess that in the requirements we should add:

Bad guys MUST NOT use subdomains of domains that publish SSP, since
that will trivially defeat whatever it is that it does..

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sun, 10 Dec 2006 06:39:44 -0800

> this is severe standards mission creep.

Right and it seems completely orthogonal to the question of "what is the
signing policy of a.b.c.d.example.com?" The question at hand is more of
"does SSP provide inheritance to even possibly non-existent domains?"
Assuming that SSP does, a receiver may or may not want to ask the policy
question, and may or may not ask the exists question. They seem pretty
severable to me.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Sun, 10 Dec 2006 06:37:40 -0800

On Dec 9, 2006, at 8:05 PM, Hector Santos wrote:

>>> existent domains is explicitly NOT a requirement.  For a domain  
>>> to be covered by SSP, it MUST exist.  I like Graham Murray's  
>>> definition of exists.
>> lists.
> prefers to use an exclusive policy for some of its high value  
> domains, it would be highly probably that it be done on the basis  
> to stop such public external usages.  That would be one goal.  
> Protection from unauthorized usage of their domains.
>
> Note, this doesn't stop a company from using using a Mailing List  
> Server for original signed distribution.   But if you are talking  
> about open ended mailing list such as this one, it would be an  
> contradiction to define a exclusive policy and continue to behave  
> in this open "laissez faire" promiscuous manner.
>
> Second, this issue of MAILING LIST SERVER (MLS) really has nothing  
> to do with SSP but with DKIM-BASE mail integrity issues.  Thats the  
> problem with a MLS, not SSP.  SSP is really the easy part when it  
> comes to a MLS.  You could throw SSP away and you STILL have the  
> mailing list DKIM-BASE mail integrity problems.

That's not the case.

No mailing list (or other) corruption of an email in transit can do  
anything worse than change the delivery of a legitimate, DKIM-signed  
email into the delivery of a legitimate non-DKIM-signed email.

It's not until you hang the SSP bag on the side that this has any  
negative impact on legitimate email usage.

> The problem is the idea of MLS resigning in order to correct the  
> DKIM transaction of a broken original signature.   This is where  
> SSP plays a role in defining the 3rd party authorization,  
> otherwise, SANS SSP, you have a major threat with bad actors using  
> a MAILING LIST to mask a broken original signature with a resigning.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Dec 2006 10:15:21 +0800

On Dec 10, 2006, at 2:08 PM, Scott Kitterman wrote:

> I think you may have replied to the wrong message.  I wasn't able  
> to related what I wrote in my message to which you were replying  
> and anything in your reply.

We have a failure to communicate, or perhaps in some people's a view,  
a failure to not communicate. : )

You mentioned there could be a test for an address record as proof of  
a domain's existence.  That must then also assume every address RR  
must also publish a policy record to override an assumption that just  
any address record means the domain is used to send email.  As John  
pointed out, this type of test for an address record as a basis for  
acceptance, independent of DKIM, for all improperly signed and non- 
signed messages changes how email works.

-Doug

---

From: Damon <[email-masked]>
Date: Mon, 11 Dec 2006 10:52:41 -0500

Since you brought it up...

No mailing list (or other _ Spam_ ) corruption of an email in transit
_or just plain spam_ can do anything worse than change the delivery of
a legitimate _or purposely munged_, DKIM-signed email into the
delivery of a legitimate _or more likely illegitimate_ non-DKIM-signed
email.
>
> It's not until you hang the SSP bag on the side that this has any _positive_
> snip<negative> impact on _<il>_legitimate email usage.
>
> Cheers,
>   Steve

 The volume of spam is now -- what-- 7 out of 10?
 Doesn't BAD=NOSIG seem, even a little, useless... Especially at the
cost of decoding it at our current volume levels?

Damon

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Dec 2006 09:22:13 -0800

(Just background for Damon, and anyone else in the same frame of mind,
nothing SSP or DKIM specific here).

On Dec 11, 2006, at 7:52 AM, Damon wrote:

>> _positive_

Were you around for the fiasco that was SPF?
That's where a lot of our operational experience of throwing away
perfectly good mail, simply because it wasn't transmitted in a way
that followed the dogma of the message signers came from.

It was, basically, a failure, in that the SPF policies (which are very
much equivalent to SSP) that are published are almost "?all",
which is pretty much equivalent to "I sign some things" in SSP
speak.

People wouldn't tolerate mail being thrown away for
no good reason, nor were even the developers of SPF prepared
to modify the way in which they forwarded email around in order
to work around the flaws of SPF.

There seems to be some belief that if SSP does exactly the same
thing as SPF then we'll pull the phishing-proof, spam-resistant
mail architecture out of the hat this time.

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Dec 2006 13:06:12 -0500

Steve,

This is complete nonsense.  To use your lack of SPF knowledge as a 
justification for all the ills of SSP is simply surreal.  Sorry.

The fact of the matter is you are directly competing and blowing against 
the wind with the every growing MTA trend of REDUCING unsolicited 
abusive mail and spam BEFORE it gets to the user.  Whether you like it 
or not, its a reality both technically and every more growing in the 
legal world. Its happening. So get use to it.

So either DKIM-BASE is going to be part of the solution or its not, at 
the very least, my INPUT says that SSP will give it a fighting chance 
and  in all honestly, will help people, as yourself, in your market who 
have a direct interest in seeing users' make the final decision of all 
messages.

---
HLS

Steve Atkins wrote:
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Dec 2006 03:22:05 +0800

On Dec 12, 2006, at 2:06 AM, Hector Santos wrote:

> The fact of the matter is you are directly competing and blowing  
> against the wind with the every growing MTA trend of REDUCING  
> unsolicited abusive mail and spam BEFORE it gets to the user.   
> Whether you like it or not, its a reality both technically and  
> every more growing in the legal world. Its happening. So get use to  
> it.

DKIM might be used for white-listing (assuming the SMTP client can be  
associated with the signing-domain).  White-listing does not get rid  
of abusive mail, it trades off other measures that might be more  
costly in terms of integrity or overhead.

DKIM however can never reduce the level of abuse through the  
application of a restrictive policy.  DKIM can reduce the level of  
abuse by making spoofing unsuccessful.  There are millions of new  
domains created every day at no cost to the bad actor.  Neither SPF  
or DKIM identify new sources based upon some restrictive policy.  A  
restrictive policy adds little, if any anti-spoofing protection when  
the recipient must still visual recognize the originator based upon  
what they see.  Authentication and recognition is where progress is  
made, often by intelligent filtering at this point that is not based  
upon a policy record.  DKIM in conjunction with a recognition scheme  
provides reasonable protections without any policy record being  
used.  The policy record requirements should instead focus on  
ensuring a larger portion of email can be recognized without complex  
three-party administration, as now envisioned.  Focus upon enabling a  
greater use of DKIM+Recognition+Annotation.

> So either DKIM-BASE is going to be part of the solution or its not,  
> at the very least, my INPUT says that SSP will give it a fighting  
> chance and in all honestly, will help people, as yourself, in your  
> market who have a direct interest in seeing users' make the final  
> decision of all messages.

With a recognition scheme that adds annotation on messages found in  
their address-book or on a DAC compatible list, this will help people  
by providing the desired protections.  A restrictive scheme takes  
away freedoms without little protective benefit, but at a loss of  
email integrity.

-Doug

---

From: Damon <[email-masked]>
Date: Mon, 11 Dec 2006 14:56:52 -0500

> that followed the dogma of the message signers came from.

I don't think it was a fiasco. I believe that it was the first attempt
at doing ~something~ meaningful. There were many intelligent people
involved, many are still here and still involved. (Nods to Dave,
Hector, Scott, Douglas, and others).
Please note the date on this post (an interesting historical read :) -
http://www1.ietf.org/mail-archive/web/asrg/current/msg00334.html
DK wasn't even around yet. The real death knoll came with MS decided
to license our next step just as we were getting there (PRA).
All in all I believe that it was an excellent learning experience. Too
bad many of the lessons from it are still not learned.
> which is pretty much equivalent to "I sign some things" in SSP
And ?all is/was supposed to be temporary. But I do know many domains
that protect themselves with SPF. If an admin inadvertently posts a
bad SPF, it can be fixed. You are missing the point. You are pointing
to the fact that valid mail is thrown away and saying SPF is broken. I
point to it and say- It is working exactly as it should! It is an
administrative issue, not a technical fault.
SPF was NOT supposed to block spam, it was an attempt at validating
where the email is/should be coming from. The real issue as I see it
is admins discovered they really don't know the extent of their own
infrastructure. Hence all the ?ALL's.
I believe that I remember a thread asking what we are going to
recommend people do when sig validation fails. From an operational
side, I would say that it would be nice if I got a rejection
notification but only from email that ~also~ passed the SPF check. SSP
does not do what SPF does. SPF isn't dead or even sick, just
misunderstood. SSP lets admins have granular control over their rules.

> to work around the flaws of SPF.

As those involved will tell you... this was because it was watered
down and good suggestions from people like Hadmut Danish were not even
considered. Hadmut finally got tired of it all and stopped
participating... which is too bad. Have not heard from him since.
> mail architecture out of the hat this time.

I am going to get my knuckles rapped again by the chairs for this trip
down memory lane so I will stop here. Since Base is closed to the type
of modification I would have hoped to see, I am looking forward to
debate on SSP.

Regards,
Damon Sauer

---

From: Hector Santos <[email-masked]>
Date: Mon, 11 Dec 2006 16:25:27 -0500

Doug,

In lieu of no MUA that currently supports your DKIM address book ideas, 
are you suggesting that every SMTP or MUA system that is waiting for the 
standardization of DKIM will also have to use Levine's and Hoffman's new 
  non-standard, untested, unverified, no threat analysis, commercial DAC 
venture in order to get any PAYOFF or BENEFIT from DKIM?

In other words, are you saying without DAC, DKIM is useless?

Is this the reason why SSP is being brushed aside? Because the DAC group 
have succeeded in clouding the SSP picture and non facts that it work 
hence the non-standard DAC should be used instead with DKIM?

The why are we wasting time with SSP requirements.  If enough people 
here are so CONVINCE that DAC is the ultimate technology to be used with 
DKIM, why they do do an official IETF I-D proposal?  Why did Paul 
Hoffman, one of the Key IETF GODS, stray away from using the IETF to 
standardized DAC?

I'm sorry, you have to excuse me, but I am engineer at heart, and none 
of this make sense to me.  Too much politics and self-interest for me 
going on here.

---
HLS

Douglas Otis wrote:
>> unsolicited abusive mail and spam BEFORE it gets to the user.  Whether 
>> you like it or not, its a reality both technically and every more 
>> growing in the legal world. Its happening. So get use to it.
> 
> associated with the signing-domain).  White-listing does not get rid of 
> abusive mail, it trades off other measures that might be more costly in 
> terms of integrity or overhead.
> 
> DKIM however can never reduce the level of abuse through the application 
> of a restrictive policy.  DKIM can reduce the level of abuse by making 
> spoofing unsuccessful.  There are millions of new domains created every 
> day at no cost to the bad actor.  Neither SPF or DKIM identify new 
> sources based upon some restrictive policy.  A restrictive policy adds 
> little, if any anti-spoofing protection when the recipient must still 
> visual recognize the originator based upon what they see.  
> Authentication and recognition is where progress is made, often by 
> intelligent filtering at this point that is not based upon a policy 
> record.  DKIM in conjunction with a recognition scheme provides 
> reasonable protections without any policy record being used.  The policy 
> record requirements should instead focus on ensuring a larger portion of 
> email can be recognized without complex three-party administration, as 
> now envisioned.  Focus upon enabling a greater use of 
> DKIM+Recognition+Annotation.
> 
> their address-book or on a DAC compatible list, this will help people by 
> providing the desired protections.  A restrictive scheme takes away 
> freedoms without little protective benefit, but at a loss of email 
> integrity.
> 
> -Doug
> 
> 
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Dec 2006 08:32:08 +0800

On Dec 12, 2006, at 5:25 AM, Hector Santos wrote:

> Doug,
>
> In lieu of no MUA that currently supports your DKIM address book  
> ideas, are you suggesting that every SMTP or MUA system that is  
> waiting for the standardization of DKIM will also have to use  
> Levine's and Hoffman's new  non-standard, untested, unverified, no  
> threat analysis, commercial DAC venture in order to get any PAYOFF  
> or BENEFIT from DKIM?
>

DAC provides guidelines for creating these lists, if I am not  
mistaken.  So not even DAC offers a full-up solution, just as DKIM  
does not either.  There are some start-ups already offering plugins  
for the popular web and email-clients based upon their own lists.  I  
can obtain that today, and months prior.

> Is this the reason why SSP is being brushed aside? Because the DAC  
> group have succeeded in clouding the SSP picture and non facts that  
> it work hence the non-standard DAC should be used instead with DKIM?

I suspect that all methods that enable recipients the ability to  
protect themselves will be tried.  A restrictive SSP however will  
create the greatest trouble for the least benefit.  There are areas  
of weakness that can be repaired using associative techniques, from  
protecting a white-list to protecting the MailFrom.

> The why are we wasting time with SSP requirements.  If enough  
> people here are so CONVINCE that DAC is the ultimate technology to  
> be used with DKIM, why they do do an official IETF I-D proposal?   
> Why did Paul Hoffman, one of the Key IETF GODS, stray away from  
> using the IETF to standardized DAC?

Even waving a magic wand will not overcome several issues that need  
to be resolved such as protecting white-listing, the MailFrom, and  
allowing sign-domains to be used for annotation without the sharing  
of private-keys.  All of this becomes possible with the right type of  
policy where recipients are better protected, email delivery is not  
negatively affected, and there is greater freedom of choice regarding  
how a domain is associated with their provider.

> I'm sorry, you have to excuse me, but I am engineer at heart, and  
> none of this make sense to me.  Too much politics and self-interest  
> for me going on here.

This is not about politics or self-interest, other than also being  
someone that uses email.  DKIM will make life better, but associative  
schemes will not shift benefits to one group or the other, just away  
from the bad-actors.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Dec 2006 10:37:57 -0800

Some people seem to be confused about the purpose of VBR. It is 
basically unrelated to SSP, and is certainly not a replacement for 
it. We expect that many sites will use both.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Dec 2006 19:39:00 +0100

> Were you around for the fiasco that was SPF?

SPF FAIL works as designed, stopping forgeries of Return-Paths,
thanks for asking.  Spammers understand how SPF works, now it
is merely a self-fulfilling prophecy.

> our operational experience of throwing away perfectly good
> mail, simply because it wasn't transmitted in a way that
> followed the dogma of the message signers came from.

As soon as somebody throws mail away for whatever reason they
should be ready for some years in jail, unless it's their own
mail of course.  SPF policies SHOULD be checked at the border
MTA during the SMTP session, and at that point in time the
only realistic behaviour of a server is to reject FAIL.  Not
accept and throw away, that's madness, nobody would do this.

> SPF policies (which are very much equivalent to SSP)

They are completely unrelated.  SPF is an SMTP protocol, not
some mail-magic like DKIM or SenderID.  SPF is about the HELO
and the envelope sender, not about obscure identities like a
PRA, or the utter dubious 2822-From SSP ideas discussed here.

> that are published are almost "?all", which is pretty much
> equivalent to "I sign some things" in SSP speak.

No, an SPF PASS is still better than nothing, a bounce or any
other kind of auto-reply covered by RFCs (i.e. going to the
envelope sender) won't hit innocent bystanders.  SPF FAIL and
SPF PASS both have a clear meaning wrt SMTP.

> People wouldn't tolerate mail being thrown away for no good
> reason

That's why it's so important to reject mail a.s.a.p.  Anything
else is unreliable.

> nor were even the developers of SPF prepared to modify the
> way in which they forwarded email around in order to work
> around the flaws of SPF.

That's complete rubbish.  The concept of a "reverse path" is
older than RFC 821, and SPF revived it after the situation
with the broken RFC 1123 5.3.6(a) got out of hand.  The same
loophole that established open relays.  "Just modify RCPT TO"
never worked, it was always wrong, from day one of RFC 1123.

> There seems to be some belief that if SSP does exactly the
> same thing as SPF then we'll pull the phishing-proof, spam-
> resistant mail architecture out of the hat this time.

A lousy chance based on PRA (SenderID).  Zero chance based on
2822-From, the concept makes no sense, it's incompatible with
tons of special cases with PRA != 2822-From.

Frank

---

From: Steve Atkins <[email-masked]>
Date: Thu, 14 Dec 2006 11:01:10 -0800

> tons of special cases with PRA != 2822-From.

So, to summarize, you believe that SSP is drastically less likely
to provide any operational benefit or achieve widespread
deployment than SPF?

Cheers,
   Steve

---

From: Damon <[email-masked]>
Date: Thu, 14 Dec 2006 15:00:38 -0500

> to provide any operational benefit or achieve widespread

Lot's of 'ifs' here.
If it does not get watered down to much here.
If it has options that cover most situations.
If we can demonstrate its usefulness.
If software gets written for it.
If it is easily deployable across many platforms.
If the big ISP's push it.
...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Dec 2006 04:22:14 -0800

On Thu, 2006-12-14 at 19:39 +0100, Frank Ellermann wrote:
> SPF FAIL works as designed, stopping forgeries of Return-Paths, thanks
> for asking.  Spammers understand how SPF works, now it is merely a
> self-fulfilling prophecy.

SPF attempts to authorize SMTP clients for where the Return-Path is
acceptable.  "Working as planned" means messages sent to recipients
forwarding their mail will lose messages when sender's SPF records are
handled in a "strict" fashion.  In the cases where SPF does not break
forwarding, it also does not prevent the spoofing of the Return-Path.
This problem may explain Bell Canada's "+all".

Providing a means to associate DKIM signing-domains with that of the
Return-Path could be done within one small DNS transaction that would
not break when the message is forwarded, even when handled in a strict
fashion.

> accept and throw away, that's madness, nobody would do this.

When the forwarded message is refused due to SPF, this message MUST be
bounced.  Provider could protect themselves by:

1) Not publishing or inspecting SPF records.

This works once there is something better.

2) Publishing SPF records with neutral or positive defaults.

But then why bother?

3) Modify Return-Paths on all messages.

The next problem of modifying Return-Paths might become replay of
messages.

> PRA, or the utter dubious 2822-From SSP ideas discussed here.

This concern would be in regard to the initial SSP I-D.  This is also
where Mike and a few others appear to be headed with the requirements
draft, the wrong direction.

> SPF PASS both have a clear meaning wrt SMTP.

Not as clear as all would want.  A neutral result might lead to message
acceptance, but then cause a subsequent bounce to then be dropped.  This
weakens the integrity of email delivery, which is the sure outcome of
strict path registration without strict conformance.

Never advocate strict conformance in the case of SPF however, because
the SPF scripts themselves represent a serious threat.  With the
prevalence of malware in messages, few execute script found in messages
from unauthenticated senders, however SPF requires execution of script
found in DNS to obtain just authorization.  SPF is ideal for taking out
authoritative name servers and for causing hundred of queries for
address records no one would have ever done otherwise.

> > People wouldn't tolerate mail being thrown away for no good reason
> 

SMTP is still store-and-forward in many places.  Email could adopt the
T10's object (content) addressable storage concept and combine that with
BURL.  A double hash of the object and a time stamp creates a very long
token that acts as a type of password.  This token is also how the
storage system handles the message body at the sending side.  Email
changes into the rather safe exchange of URIs containing message-body
tokens.  At that point, there would be less need for DKIM or worrying
about accepting messages.  Only the Display-Name and the Subject line
would be prone, and would be much easier to filter.

> never worked, it was always wrong, from day one of RFC 1123.

While some were willing, the premise requires execution of scripts from
anonymous senders and remains flawed.  This can be fixed by associating
the Return-Path with the signing-domain instead.

> tons of special cases with PRA != 2822-From.

Agreed.  But DKIM base can still be used to assure any originating
identity without introducing the problems seen with SPF.  The DOSP draft
attempted to illustrate how this could be possible.

There remains the mistaken belief that blocking messages after searching
(often in vein) for some policy record will prevent visual spoofing.
Words can not describe the futility of this effort.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Dec 2006 15:05:27 +0100

Steve Atkins wrote:
 
> to summarize, you believe that SSP is drastically less likely

I wouldn't compare SPF and SSP, they're mostly unrelated.  For
a comparison of SenderID and SSP it's hard to judge, the "PRA"
concept makes more sense than looking only at the 2822-From.

On the other hand SenderID is based on an IP enumeration (like
SPF), and DKIM on a signature surviving almost everything excl.
"some" (= unfortunately almost all) irregular mailing lists.

If SSP sticks to the 2822-From as its method to identify some
kind of "authority" for _unsigned_ mails I think it's hopeless.

Phil's ideas about updating algorithms could still work, no 
matter what the rest of SSP tries to achieve.

Frank

---

From: [email-masked] (Wietse Venema)
Date: Fri, 15 Dec 2006 09:39:02 -0500 (EST)

> concept makes more sense than looking only at the 2822-From.

Isn't (SSP for DKIM) analogous to (SPF for IP addresses)?

Isn't (SSP versus MLMs) analogous to (SPF versus forwarding)?

The arguments seem to have a lot in common to me.

	Wietse

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Dec 2006 16:24:43 +0100

> When the forwarded message is refused due to SPF, this message
> MUST be bounced.

Yes, MUA to MSA, MSA (or separate box) to MX (forwarder), MX or
separate box to 3rd party, 3rd party rejects, forwarder bounces,
"MON" (= mail originating network of the MSA) puts the bounce 
in the mailbox of the user, ready, user can make another plan.

A perfect "551 user not local" emulation.  The receiver is free
to pick a better solution, e.g. change MAIL FROM as soon as the
RCPT TO is modified to go to a 3rd party.  Or white list the
forwarder.  Or collect mails sent to old addresses with POP3
instead of forwarding them.  Incomplete list, in practice I'm
still at one perfect 551-emulation in more than 30 months with
a no nonsense PASS / FAIL policy directly enumerating IPs.

>  Provider could protect themselves by:

I was more worried about the 1,000 misdirected bounces per day 
than the one pseudo-551 caused by a FAIL in 30 months.  YMMV.

> 2) Publishing SPF records with neutral or positive defaults.

An SPF PASS is no waste of time, receivers can couple it with
their white lists or other "reputation" schemes.  And they can
delay more expensive checks to a post-SMTP stage, based on an
SPF PASS they're free to accept and bounce messages later.

Without a PASS they MUST get their decision reject vs. accept
right at the border, later is too late:  Either they'd "throw
away mails" incl. false positives, or more likely they'd send
spam to forged envelope sender addresses.

Of course I prefer PASS / FAIL over PASS / NEUTRAL, but other
folks have other preferences.  Some even promote NEUTRAL over
PASS in certain cases, but I digress.

> The next problem of modifying Return-Paths might become replay
> of messages.

It's no problem of the first S in SSP or SPF or SIDF, receivers
aren't forced to pick that solution.  1123 5.3.6(b) is clearly
better than 5.3.6(a), that doesnt mean that it's perfect.  For
some receivers a real or emulated 551 can be better.  <shrug />

>> SPF FAIL and SPF PASS both have a clear meaning wrt SMTP.
       ^^^^         ^^^^  
> Not as clear as all would want.  A neutral result might lead
                                     ^^^^^^^
> to message acceptance, but then cause a subsequent bounce to 
> then be dropped.

NEUTRAL has no effect, same idea as "no signature" in DKIM.  The
SSP-discussion is IMO about adding some kind of "FAIL" to DKIM.

> Never advocate strict conformance in the case of SPF however,
> because the SPF scripts themselves represent a serious threat.

There's no such thing as "SPF scripts".  SPF policies are just
enumerations of permitted IPs, as precise as publishers wish.  

A policy permitting all minus one failing IP can make sense, e.g.
if there's a problem with this IP sending tons of spam resulting
in tons of misdirected bounces.  

Make sense for all parties, alleged sender, receivers checking
SPF, and if the rogue IP has an "admin" (= spammer) it's time
for them to forge another address, or to pick a permitted IP, if
they find one.  Probably they're forced to pick a neutral IP.

> SMTP is still store-and-forward in many places.

Most mail needs one critical hop, where the "MON" had to look up 
the MX of the MRN, and unknown strangers meet.  Anything before
that hop is the local business of the sender, anything behind is
the business of the receiver (or list-admin).  

Store-an-forward, avian carrier, or floppy by snail mail doesn't
enter the picture.  Almost all mail goes through one (virtual)
point, the q=mx singularity.  Local mail won't touch that point.

Mailing lists might touch it twice, but with different MAIL FROM,
no problem.  Old RFC 821 mail always modified the MAIL FROM for
a proper reverse path.  That leaves 1123 5.3.6(a) touching the
q=mx singularity more than once with the same MAIL FROM.  This
case is broken by design.  You're not forced to believe this, as
sender or receiver.  But publishers of SPF FAIL policies and the
MXs rejecting FAIL obviously believe it.

> adopt the T10's object (content) addressable storage concept
> and combine that with BURL.  A double hash of the object and a
> time stamp creates a very long token that acts as a type of 
> password.
[...]

Get an RFC number for something with the same effect as SPF FAIL
and SPF PASS, only better, and I'll try to convince my ISPs that
they add it or switch to it.  Until then SPF is the only game in
town roughly doing what RMX promised to do.  Skipping some BATV-
considerations, IMO BATV is a kind of standalone hardcore RMX,
but doesn't actually prevent forgeries, it "only" filters most
of the misdirected bounces.  Adopt it if you can.

Frank

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Dec 2006 13:53:51 -0500

> The arguments seem to have a lot in common to me.

I can see your point, but its not really the same.  Any arguments are 
ones of politics and management, not technical.

SPF issues had to do with a technical barrier where at transition points 
(e.g., routers), the client IP has changed with the RFC required 
persistent return path.  Solutions for this are:

    - RFC 4405 SUBMITTER
      http://www.ietf.org/rfc/rfc4405.txt

    - Non-standard, altered reversed path methods

DKIM/SSP does not have a technical problem with transitions points hence 
one of its major attraction.

SPF mail senders are sending to a MDA with no presumption or expectation 
that any further routing will be done. As far as the sender is concern 
the job is done.  The SPF receiver, if its going to further route, is 
required to maintain the LMAP (Domain::IP) relationship.

Since this not a technical issue with DKIM/SSP, the question debated 
here with SSP had to do with controlling the DKIM-BASE signature 
process.  That is more of "feature", "management" issue.  Not a 
technical barrier.

On a related note, SSP is really not the big concern with MLM or mailing 
list servers, but rather DKIM-BASE mail integrity issues are nearly 100% 
guarantee, making anything beyond DKIM-BASE a moot issue.

However, at the very least, SSP can help control the "bad side" of such 
operations where it is NOT expected to happen.

---
Hector Santos, CTO
http://www.santronics.com