Subject: Re: [ietf-dkim] Re: Role of Sender header as signing domain

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 01 Dec 2006 14:44:13 -0000

On Thu, 30 Nov 2006 16:04:35 -0000, Michael Thomas <[email-masked]> wrote:

> Charles Lindsey wrote:
>> On Wed, 29 Nov 2006 13:44:30 -0000, Scott Kitterman  
>> <[email-masked]> wrote:
>>
>>> SSP needs an identity to key off of to lookup a policy.  The agreed  
>>> identity
>>> for that is 2822.From for several reasons:
>>
>> But that is wholly back to front. The SSP policy to look up initially  
>> should be that of the domain making the signature.
> What signature? SSP is for the case when you get a piece of mail whose  
> signature
> is either missing altogether, broken, or doesn't fit the requisites for  
> the SSP policy.

If you have a signature, then all I am suggesting is that you first look  
at the SSP of a signer to see if that provides a satisfactory explanation.  
For sure, you now know where the mail DID come from. If that domain is not  
one of the domains in From, then maybe you then need to look as some From  
SSPs.

If there is no signature, then you have less to go on. But even then,  
knowing where it was alleged to come from (Sender) is information of a  
sort, though you are more likely to need a From SSP as well.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 01 Dec 2006 15:04:00 -0000

On Thu, 30 Nov 2006 12:33:10 -0000, Scott Kitterman  
<[email-masked]> wrote:

> Not quite.  What I want to be able to do with SSP has nothing to do with  
> user
> interface.

But users might not share you opinion of that. If the user's MUA has no  
part to play in the matter, then the only options for his upstream is  
"drop" or "not drop". Some users might be happy to devolve that  
responsiblity to their upstreams. I would not, unless I had considered  
their policy and agreed to go along with it (as I do actually; I have set  
a Spamassassin score of 4+ which my provider devnulls for me; below that,  
I inspect the mail myself).
>
> In your example, let's say that foo.com is a heavily phished domain that  
> has
> published a signing complete SSP.  In this case I have received a message
> that is outside the criteria of their declared SSP.  They have published  
> such
> an SSP knowing that it will cause some legitimate use classes of mail to  
> fail
> (e.g. mail sent through mailing lists that break signatures), but that  
> the
> benifits of combatting exact domain forgery are worth the cost (this has  
> been
> extensively debated on the list already and the group is divided on this  
> - I
> don't propose to redo this debate).

OK, I think each domain has to establish its own level or paranoia, and we  
can rank SSP policies in some order. So, for the most paranoid:

We sign everything
All our from addresses are single role addresses so we never add Sender
Our staff are forbidden to subscribe to mailing lists
Our staff are forbidden to post to Usenet
Our staff are forbidden to forward mail that is received
Our staff are forbidden to resend mail that is received
We actively request all other agents through which our mail passes to drop  
it silently and with extreme prejudice if the signature fails to verify
There are NO exceptions to these rules.

And then you can gradually drop thos restrictions to achieve lower levels  
of paranoia, so that at the bottom you would have:

We run an open relay, and are happy to sign anything that is passed  
through us.

And yes, it might be a good idea for us to prepare a ranked list of SSP  
policies/features, with a view to discussing what sensible policies might  
be when faced with each. But I think all here would agree that the great  
majority of domains will place themselves well down the paranoia scale  
 from the extreme example I have given.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 01 Dec 2006 15:12:45 -0000

On Thu, 30 Nov 2006 22:27:04 -0000, Douglas Otis <[email-masked]>  
wrote:

> On Nov 30, 2006, at 2:55 AM, Charles Lindsey wrote:
>
>> There are two cases:
>> 1. The MUA has been specially adapted to work with DKIM
>> 2. The MUA has not been specially adapted
>>
>> We are supposed to be designing a system which will work with existing  
>> MUAs (i.e. case 2), so in that case the verifier's policy module can  
>> only communicate with the user via the body of the message - rather  
>> like those irksome systems which add long paragraphs to the end of  
>> messages to inform you of all the viruses they did or didn't detect.
>>
>> So in that case it is up to the policy module to describe its  
>> suspicions in a manner the user can understand whether he can see all  
>> the relevant headers or not.
>>
>> So it might say
>>    "This message was sent by [email-masked] (good signature by bar.com)  
>> but you
>>     should notice that the From: address made no mention of bar.com."
>> or
>>    "This message was sent by [email-masked] apparently on behalf of  
>> [email-masked],
>>     but there is no valid signature from either of them."
>
> It should be understood modifying the body prevents a recipient from  
> using DKIM.   Assuming the MUA does not directly support DKIM will allow  
> bad actors to make similar assertions within the body of the message.    
> Adding information to the body of the message must contend with complex  
> structures within HTML such as color and text schemes.  This too can be  
> irksome while also damaging efforts of adopting a truly secure  
> strategy.  At this _very_ moment, the recipient might be able to  
> validate DKIM messages based upon a trusted list, where an assumption  
> that the recipient can not MUST be done on an individualized basis.

Though if the start of the added portion is clearly delimited, then it is  
not too hard to establish that the signature is still valid for everythng  
above.

However, what is become clear is that verifiers will have to be prepared  
to treat things differently according to the ability of their users. Some  
possible policies might be:

1. Drop/quarantine suspicious messages regardless.

2. Give the user sufficient information to make the decision himself, but  
by a mechanism that will work with current MUAs.

3. For those users with specially adapted MUAs, communicate with them by  
whatever protocol has been standardized for the purpose.

However, I understood that this group was primarily charged with producing  
a system that would work within #1 or #2.

---

From: [email-masked] (Wietse Venema)
Date: Fri, 1 Dec 2006 10:52:48 -0500 (EST)

> >> should be that of the domain making the signature.
...
> at the SSP of a signer to see if that provides a satisfactory explanation.  

The bad guys can use SSP too. They will be more than happy to
provide you with every possible satisfactory explanation that you're
willing to believe.

> For sure, you now know where the mail DID come from.

Nothing that DKIM-BASE didn't already tell you. In my opinion,
making decisions based on the signer's SSP instead of or before
the 2822.From SSP is the worst possible application of this
technology.  It's like allowing the idiots to run the asylum.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Fri, 1 Dec 2006 09:44:08 -0800

On Dec 1, 2006, at 7:52 AM, Wietse Venema wrote:

> Charles Lindsey:
>> If you have a signature, then all I am suggesting is that you  
>> first look at the SSP of a signer to see if that provides a  
>> satisfactory explanation.
>
> provide you with every possible satisfactory explanation that  
> you're willing to believe.

Agreed.  A DKIM related policy should be referenced from various  
email-originating-elements.  These polices might then associate  
various these email-originating-elements with the signing-domain.  It  
is rather nonsensical to reference signing-domains to inquire about  
who should be signing.

> making decisions based on the signer's SSP instead of or before the  
> 2822.From SSP is the worst possible application of this  

Policies should be available for any email-originating-element and  
not just 2822.From headers.  In addition, attempting to accommodate  
non-DKIM aware MUAs by appending information at the end of the  
message (when allowed by the signer), is also prone to abuse.  There  
should be no claims made regarding DKIM's ability to prevent  
spoofing, even when proposing strict enforcement of authorization  
policies that is based upon the recipient's visual perceptions.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 01 Dec 2006 14:03:42 -0500

>I inspect the mail myself).

I didn't say 'drop', I said 'reject'.

Dropping mail impacts the reliability of e-mail as there is no knowing if a 
message was delivered or not.  Rejecting at the border MTA leaves 
responsibility with the sending MTA.  Legitmate MTAs will let the 
originator know.  

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Dec 2006 21:35:04 -0500

Charles Lindsey wrote:
> to treat things differently according to the ability of their users. 

In my mail system engineering experience, thats that last thing you want 
in this protocol.  All systems must have standard and consistency 
protocol  behavior.  At a minimum, what you are describing is "extra" 
local policy based, implementation dependent considerations. Your ideas 
for Local policy is not something you can dictate on others.

> Some possible policies might be:
> 
> 2. Give the user sufficient information to make the decision himself, 
> but by a mechanism that will work with current MUAs.
> 
> However, I understood that this group was primarily charged with 
> producing a system that would work within #1 or #2.

This is not stuff you put into a standard protocol.

---
HLS

---

From: <[email-masked]>
Date: Sat, 2 Dec 2006 08:54:22 -0500

+1

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Friday, December 01, 2006 9:35 PM
To: Charles Lindsey
Cc: DKIM
Subject: Re: [ietf-dkim] Re: Role of Sender header as signing domain

---
HLS

---

From: "John Glube" <[email-masked]>
Date: Thu, 7 Dec 2006 03:46:51 -0500

Since my name has been referenced I am compelled to
resond.

I am confused.

DKIM is not path based. It is a lightweight cryptographic
method for "validating an identity that is associated with
a message, during the time it is transferred over the
Internet. That identity then can be held accountable for
the message."

I quote from the mission statement found at
http://www.dkim.org/

This means to me that the entity responsible for injecting
the email into the Internet can say, "Yes, I am an identity
that is associated with that email and can be held
accountable."

For an e-mail application service provider, (ESP), one way
to do this is for that entity to sign the RFC 2822 sender
header.

By doing so, the ESP says "I, ESP am the entity sending
this email on behalf of my client, List (identified in the
RFC 2822 from header) and as such an identity that is
associated with that email and can be held accountable."

This approach is consistent with best practice and is
specifically allowed for in DK.

Am I now to understand that no, you may only sign the RFC
2822 from header and nothing else, if you want to: (i)
publish a sender signing policy; or (ii) take advantage of
any reputation proposals such as the Domain Assurance
Council, which although out of scope, is one of the
perceived benefits of DKIM?

If so, then in it seems we are moving in the wrong
direction. The approach is not backward compatible. It will
prejudice the ability of certain entities to follow best
practice. It appears to undermine the mission statement
quoted above.

On this basis only, I add my vote in favor of this petition.

That being said, if my understanding is wrong, such that
under DKIM base an entity associated with an email during
its transit across the Internet can properly sign the RFC
2822 sender header and so publish a sender signing policy
under DKIM SSP (whether based on any proposed standard or
draft proposal which comes out of this working group), I
will pass and go back to lurking.

John

P.S. DKIM allows for tying of reputation to the accountable
party that is an associated identity. In the case of ESPs,
receiving networks look to the sending network.  When the
ESP signs for the domain in the RFC 2822 sender header,
this allows for reputation assignment to the accountable
party. This is appropriate. It deprecates the practice of
the ESP attempting to "slip" responsibility down to
clients. It promotes what is understood as the best
approach to control abuse. However, a client with a strong
brand may insist that it is allowed to hold itself out as
the identity associated with that email and so
accountable, especially where the phishing threat is
overarching. DKIM is sufficiently flexible to allow for
these situations while supporting best ESP practice in
that the receiving network looks to the
sending network and the ESP does not hide behind
the client.

Please accept my apologies if none of this is relevant to
the present discussion.

John Glube
BigHip - Abuse / Compliance
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Dec 2006 04:29:34 -0500

John Glube wrote:

> 2822 from header and nothing else, 

No. Sender SHOULD be signed if that is what makes the authentication of 
the message stronger. But I think the "confusion" is......

 > if you want to: (i)

.... that the ESP here is a THIRD PARTY SIGNER!

The critical issue, debate, 'dividing line' whatever you want to call it 
is the "AUTHORIZATION" of the signing.

In other words, I own the domain, just because you may be hosting my 
mail, doesn't really mean you have the authority to sign on my behalf.
Remember, the specs does say the signer is now accountable.  So you have 
to consider the idea that the ESP/ISP may not want to get involved and 
in the TRADITIONAL is to not get involved in the passthru nature of 
mail.  Thats been the best practice and what most systems work with on 
that basis.

But probably in the name of "business", allowing unauthorize and 
unrestricted 3rd party signing, then this basically says ANYONE can sign 
my mail and effectively make my mail appear to end-users that my mail is 
"OK" just because it has some confusing "GOOD DKIM MAIL" SEAL on it.

It opens the door to exploitation to allow just anyone to sign on your 
behalf, and that may include a domain that doesn't even use the domain 
for sending mail! Something today, we have little control of unless you 
are using something like SPF or some other technical to determine its a 
valid EMAIL domain in play.

IMV, the "technology" that has not been completely worked out is how 
does a DOMAIN authorized 3rd party signers.  Thats the missing piece in 
all this and its the heart of most of the pros and cons debates.

IMV, there are 4 general types of DKIM messages:

     EXCLUSIVE
     OPTIONAL
     3RD PARTY
     NONE

By far, the strongest protection, and in my view, the highest benefit 
DKIM/SSP has to offer to the world is the exclusive signing policies. 
This is where the high value domains will see the greatest benefit. 
OPTIONAL gives domains to integrate DKIM/SSP into different email 
routes.   3rd PARTY can play a role in original signing or as second 
hand signings in order to maintain the "DKIM integrity" of possibly 
altered mail, and then you have NONE where NO DKIM is expected at all 
which will include the legacy market.

The missing piece, in my view, is how the 3rd party is involved in an 
authorized and expected manner.  Once that part is worked out, IMV, we 
are pretty much done.  Exclusive is easy and required for DKIM to have 
basic VALUE to offer the world.  Unfortunately, IMV, the SSP cons are 
not making it easy to allow that to happen.

---
HLS

---

From: "John Glube" <[email-masked]>
Date: Thu, 7 Dec 2006 08:14:07 -0500

> mail.  Thats been the best practice and what most systems work with on
Well ... that analysis is not accurate based on how
I operate in today's environment of abuse and compliance
management.

In my world, the ESP is the accountable party as far as the
rest of the Net is concerned.  .

ESPs would love to avoid responsibility, but ... you can't.

True, the client provides the message content and the email
address for the from header.

Yes, at least one receiving network likes to see one list per
IP address.

True, the email addresses collected by the client through use of
the ESP's facility are property of the client.

Most ESPs allow clients to import data and send mail to
their lists using the ESP's facilities.

(BigHip does not, but that is another story.)

Hence the traditional "pass through" argument.

But, that "approach" allows ESPs to avoid responsibility
for the abuse coming from their network when for
example the client imports and mails to a "bad list."

In turn, this refusal to take responsibility in general
is one of the underlying reasons why we are in today's
mess.

In my view it is simple. Folks must be responsible for their
own backyard.

Therefore, in simplistic terms:

The ESP is responsible to the Net to stop abuse
coming from its network.

The ESP is accountable to the Net to respond to
complaints of abuse coming from its network.

It is therefore appropriate in most cases that the
ESP is authorized to sign for mail sent from its
Network on behalf of its clients using the sender
header because the ESP is the responsible and
accountable party to the Net.

John

John Glube

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 7 Dec 2006 09:47:04 -0500

> accountable party to the Net.
There has been a lot of discussion on the list in the last several months 
about the benifit/necessity of allowing domains to specify which 3rd party 
signers are authorized to sign for them.  I think that this proposal, which, 
IIRC, is listed in the SSP requirements as a tentative requirement, would 
solve the problem you are trying to solve without diluting the tie between 
SSP and the 2822.From which is pretty much the entire point of SSP.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Dec 2006 10:28:37 -0800

On Dec 7, 2006, at 12:46 AM, John Glube wrote:

> DKIM is not path based. It is a lightweight cryptographic method  
> for "validating an identity that is associated with a message,  
> during the time it is transferred over the Internet. That identity  
> then can be held accountable for the message."

DKIM does not encompass the envelope.  While it might be possible to  
hold signers accountable for content, this MUST exclude unsolicited  
message status.  This eliminates DKIM for white-listing or block- 
listing, because either is easily abused.  While DKIM is not path  
based, white-listing MUST be protected from replay abuse.  Before a  
message obtains a "white-listed" status, a prerequisite should  
include associating SMTP clients with the signing-domain.  The same  
strategy protects MailFrom, "third-party" signing, and establishes  
policy for all other headers.

For illustrative examples see:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

> This means to me that the entity responsible for injecting the  
> email into the Internet can say, "Yes, I am an identity that is  

It would be nice to think a DKIM signature is indicative of the  
entity transmitting the message.  If so, DKIM would then help in  
resolving abuse issues.  Alas, an expectation that providers use  
their customer's private keys removes this feature. : (

> For an e-mail application service provider, (ESP), one way to do  
> this is for that entity to sign the RFC 2822 sender header.

Fully agree. : )

> By doing so, the ESP says "I, ESP am the entity sending this email  
> on behalf of my client, List (identified in the RFC 2822 from  
> header) and as such an identity that is associated with that email  
> and can be held accountable."
>
> This approach is consistent with best practice and is specifically  
> allowed for in DK.

It could also be allowed in DKIM when protection is obtained by  
annotation of email-addresses associated with the signing-domain.   
With millions of new domains created at no cost for bad actors each  
day, marking message "known" (through non-visual comparison) allows  
DKIM to prevent spoofing.  DKIM can not prevent abuse, although not  
being on a "white-list" might limit the volume.  Many of the larger  
domains are often block-listed due to acts of a few.  While these  
domains are also easy targets of replay abuse, safe "white-listing"  
of these domains remains possible only when the SMTP client can be  
associated with the signing-domain.

> Am I now to understand that no, you may only sign the RFC 2822 from  
> header and nothing else, if you want to: (i) publish a sender  
> signing policy; or (ii) take advantage of any reputation proposals  
> such as the Domain Assurance Council, which although out of scope,  
> is one of the perceived benefits of DKIM?

Without a means to associate a signing-domain with other email- 
originating-identities, yes!  Some suggest abuse can be blocked after  
"everyone" publishes highly restrictive policies that "break" email,  
AND after everyone searches the domain label tree for rare highly  
restrictive policy statements.  Of course this overlooks a sizable  
problem of visual recognition and perhaps why UTF-8 remains ignored.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Dec 2006 14:29:27 -0500

> accountable party to the Net.

Hi John,

That may be so, but by the time the receivers, "a real victim" of the 
torrent abuse of transactions that by today measures is 9 of 10 
messages, gets the mail:

a) it doesn't have a clue what function you (the SMTP Client) is
serving. Is it a ESP, ISP, ABC, XYZ?

b) Does it matter? It doesn't care? and

c) There is no reason to trust that the sender represent the important 
2822.FROM domain owner.

Whats to stop any sender, whose true role the RECEIVER does not know or 
care, from using any 2822.FROM domain?

What purpose does validating the DKIM signature of the SENDER?

Are you suggesting that as long as we AUTHENTICATE the sender, the 
payload, any payload can be trusted?  That it can use any domain it wants?

If so, there are far more cheaper mechanisms than DKIM (a payload 
solution) to do TRANSPORT authentication/validation.

---
HLS

---

From: Damon <[email-masked]>
Date: Thu, 7 Dec 2006 14:33:10 -0500

> > > to do this is for that entity to sign the RFC 2822 sender
        What if I don't want you to. (see reasoning below)

> > > associated with that email and can be held accountable."
         So if a spammer invades a third party (ESP, ISP, ASP,
ISP->ASP) I have a conundrum... how do I distrust gmail or AOL?? Sure,
I could flip the switch but realistically, who is going to do that?
Which is why I don't want my 'as a sender' email signed by the
service. Their sig isn't worth the bits used to inject it- especially
not compared to my wholesome image.

> ESPs would love to avoid responsibility, but ... you can't.

But you can't really block them either can you :)

> example the client imports and mails to a "bad list."
But I can't 'force' the issue by distrusting the ESP's sig... when who
we REALLY want to trust is 'The' sender

> is one of the underlying reasons why we are in today's

Amen.
> In my view it is simple. Folks must be responsible for their

And if it actually happened we wouldn't be here :)

> complaints of abuse coming from its network.
.. and they all lived happily ever after. (You forgot to end your fairytale :)

> BigHip - Abuse / Compliance

Regards,
Damon Sauer

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Dec 2006 19:53:53 +0000

Folks,

Please look at the archive for numerous examples of threads
like this, that, like this, go nowhere.

I sort-of admire the energy to keep doing this, but it makes
no progress and, in this context, is therefore futile.

At this stage of the WG's progress, I think we are only
interested in specific suggested changes to ssp-reqs, and
we are not interested in repeats of the various positions
of the various folks.

And at this point, we are absolutely not interested in
suggested changes to dkim-base.

So, can we please get back on-topic or just say nothing,
where that's appropriate (and my thanks to all those who've
not, or only very slightly, taken the bait:-)

To repeat, specific changes to ssp-reqs are on-topic for now,
very little else is.

Thanks,
Stephen.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 7 Dec 2006 12:11:41 -0800

> To repeat, specific changes to ssp-reqs are on-topic for now,

So... punctuation changes, rather than substantive changes?

Cheers,
   Steve

---

From: <[email-masked]>
Date: Thu, 7 Dec 2006 15:33:22 -0500

As a receiver it appears all mail is much like the "land Shark" of the
old Saturday Nite comedy skits. So SSP is interesting to me for a number
of reasons.

ssp.3Psigner.com=http://WhoWeSignFor.signer.com
Could be useful for building local cache entries

Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Dec 2006 12:43:42 -0800

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

>>  By doing so, the ESP says "I, ESP am the entity sending this  
>> email on behalf of my client, List (identified in the RFC 2822  
>> from header) and as such an identity that is associated with that  
>> email and can be held accountable."
>
> So if a spammer invades a third party (ESP, ISP, ASP, ISP->ASP) I  
> have a conundrum... how do I distrust gmail or AOL?? Sure, I could  
> flip the switch but realistically, who is going to do that?  Which  
> is why I don't want my 'as a sender' email signed by the service.  
> Their sig isn't worth the bits used to inject it- especially not  
> compared to my wholesome image.

Some type of associative method MUST be available with the SMTP  
client as a ssp-requirement.  Otherwise, NO signature offered by a  
large provider can be safely "white-listed".  The IP address of the  
SMTP client will continue to be the dominate basis for acceptance.   
The ESP SHOULD be interested in receiving feedback based upon the  
DKIM signature, but that only happens when they use _their_  
signature.  This therefore REQUIRES a means to associate email- 
address domains in various headers with that of the signing-domain, a  
ssp-requirement.

> But you can't really block them either can you :)

When ESPs use customer's private keys, establishing a basis for  
"white-listing" becomes more difficult and makes abuse reporting more  
difficult.  Associating the signing domain with email-addresses in  
various header MUST be an ssp-requirement to permit the signing- 
domain to represent the transmitting entity.

A bulk sender SHOULD sign with _their_ domain and have their  
customer's associate their email-addresses with their domain.  To  
protect providers from "white-listing" replay abuse of their domain,  
a means to associate the SMTP client with the signing-domain becomes  
an ssp-requirement.  A means to associate the From header email- 
address with that of a different signing-domain becomes an ssp- 
requirement.

>> But, that "approach" allows ESPs to avoid responsibility for the  
>> abuse coming from their network when for example the client  
>> imports and mails to a "bad list."
>
> But I can't 'force' the issue by distrusting the ESP's sig... when  
> who we REALLY want to trust is 'The' sender

Annotation of "recognized" email-addresses "associated" with the  
signing-domain offers strong protection from spoofing.  Associating  
the signing-domain with the SMTP client provides strong protection  
from "white-listing" abuse.

One really wants to be able to trust something.  As it currently  
stands, by allowing any bad actor an ability to replay any message  
from a "white-listed" domain prevents trust from ever being  
established.  Trust MUST be protected as an ssp-requirement.  Trust  
requires an ability to associate the SMTP client, the MailFrom, and  
other email-address domains within other headers with that of the  
signing-domain.  DKIM MUST be able to protect trust that might be  
established from abuse.   These associations as an ssp-requirement  
provides this protection.

-Doug

---

From: Damon <[email-masked]>
Date: Thu, 7 Dec 2006 15:56:27 -0500

> provides this protection.

Section 1.1
DKIM separates the question of the identity of the signer of the
   message from the purported author of the message.  In particular, a
   signature includes the identity of the signer.  Verifiers can use the
   signing information to decide how they want to process the message.
   The signing identity is included as part of the signature header
   field.

In this case, wouldn't it be better to say:

DKIM separates the question of the identity of the signer of the
   message from the purported author of the message. In particular, a
   signature includes the identity of the signer which can be traced to a
   specific author or first party signer.  Verifiers can use the signing
   information to decide how they want to process the message based on the
   reputation of the author. The signing identity is included as part of the
   signature header field.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Dec 2006 14:50:53 -0800

On Dec 7, 2006, at 12:56 PM, Damon wrote:

> signature includes the identity of the signer which can be traced  
> to a specific author or first party signer.  Verifiers can use the  
> signing information to decide how they want to process the message  
> based on the reputation of the author. The signing identity is  
> included as part of the signature header field.

Some wish to view protections afford by DKIM are prohibitions of  
specific uses of an email-address.  Some view DNS delegation, sharing  
private-keys, or CNAMEs a means to establish simple mandates-

  The From MUST be signed by a "parent" domain. (Often worded as "All  
signed.")

While seeming like a simple mandate, it fails to handle replayed  
messages as the recipients of the message is not constrained.  In  
addition, the "author" can not be held accountable for the sending  
unsolicited messages.  Few will assess reputation based upon content,  
which brings in issues of censorship and privacy.  White-listing can  
be abused.  So just how can the reputation of the "author" be  
applied, even assuming it can be established?

Millions of new domains are created every day.  This affords bad  
actors (who might not be charged for this service) greater freedom  
than a good actors who must wait 48 hours for their NS record  
updates.  It is hard to imagine there is much value tracking negative  
domain reputations of such a disposable commodity.

The positive reputations of DAC appears to represent a reasonable  
approach for staying ahead of the registration mayhem.   
Unfortunately, the signing-domain not be related to the SMTP client,  
so there is no means to safely use the DKIM signature as a basis for  
acceptance.  The term "trace" is misleading.  The term associate  
would be better.

What needs to be associated to protect white-listing the signing- 
domain are all the identities of the email-originating-elements.   
These include the:

  1) From
  2) Sender
  3) Resent-From
  4) Resent-Sender
  5) MailFrom
  6) SMTP Client

-Doug