Subject: Re: [ietf-dkim] Are verifiers expected to query SSP on a successful verify?

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 07:32:31 -0700

Douglas Otis wrote:

>
> On Jul 31, 2006, at 12:26 PM, Dave Crocker wrote:
>
>>
>> I would like to see a scenario described that explains exactly what  
>> problem needs to be detected and why it is a compelling, immediate  
>> requirement.
>

I agree 100% but:

> =====
>
> Problem 1:  Spoofs of the 2822.From email-address(es) common with  
> various phishing or spoofing attempts.
>
> Solution A:  [long solution]

[]

Is not in a form that is useful. The problem/scenario needs to be 
fleshed out here, and
what we need at this point are *requirements*, not solutions. And most 
definitely requirements
that don't require me to understand three dozen acronyms that I have no 
clue what they
mean.

In the scenario, we need to enumerate what the actual technical problems 
are with SMTP/DKIM-base,
etc and what is required to fill the gap.

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 07:56:49 -0700

Dave Crocker wrote:

>Tony Hansen wrote:
>  
>
>>Dave Crocker wrote:
>>    
>>
>>>Alas, it was pointed out to me that SSP does indeed have a requirement for a
>>>lookup even when the message is signed.  This is when there is so-called
>>>third-party signing.  (I believe this means when the domain in the rfc2822.From
>>>does not make the DKIM d= domain.)
>>>      
>>>
>>I would at a minimum include rfc2822.Sender in this check: third part
>>signing is when the DKIM d= domain is not equal to either the
>>rfc2822.From's domain nor the rfc2822.Sender's domain.
>>    
>>
>
>
>Tony, et al,
>
>Switching back to the 'requirements' suggestion I have been making:
>
>I would like to see a scenario described that explains exactly what problem
>needs to be detected and why it is a compelling, immediate requirement.
>
>I would like to see the description done in a way tht talks about particular
>individuals and organizations, without referring to particular protocol units.
>
>In other words, I'd like to see the non-technical description of the requirement
>and its rationale, before it gets translated into the technical details, such as
>citing particular header fields.
>  
>
Right, this would be enormously helpful I think.

Scenario 1:

1) A sends to B with a missing or broken DKIM signature
2) B would like to know whether that is an acceptable state of affairs.

Scenario 2:

1) C sends a message on A's behalf by having been delegated a selector by A

This is a normal -dkim-base usage scenario, but there are some deployment
related issues related to how the delegation is done. What are the 
requirements
from that?

Scenario 3:
1) C sends message on A's behalf using C's identity
2) B would like to know if C's signature has any relationship to A

This is the "ISP" scenario discussed on the list often. It has scaling 
issues
naively because the number of acceptable third party signers for A may be
large, and perhaps troublingly not uniform in the trust of the third 
parties.

Etc. If people can come up with other use scenarios, please feel free. 
Please
do not follow them on with long tomes on how to solve it, or why it makes
a particular protocol well suited, etc... this is about requirements.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 1 Aug 2006 11:16:59 -0400

On Tuesday 01 August 2006 10:56, Michael Thomas wrote:
> Dave Crocker wrote:
> >Tony Hansen wrote:
> >>Dave Crocker wrote:
> >>>Alas, it was pointed out to me that SSP does indeed have a requirement
> >>> for a lookup even when the message is signed.  This is when there is
> >>> so-called third-party signing.  (I believe this means when the domain
> >>> in the rfc2822.From does not make the DKIM d= domain.)
> >>
> >I would like to see the description done in a way tht talks about
> > particular individuals and organizations, without referring to particular
> > protocol units.
> >
> >In other words, I'd like to see the non-technical description of the
> > requirement and its rationale, before it gets translated into the
> > technical details, such as citing particular header fields.
>
Scenario 3a:

1) A is a popular phishing target and prefers to suffer message rejections for 
messages that don't carry a valid signature by A (or a designated third 
party) than to have messages that are unsigned or signed by other parties 
delivered. 
2) C sends message on A's behalf using C's identity.
3) B would like to know if C's signature has any relationship to A.
4) If C's signature does not have a relationship to A, then A prefers that the 
message not be accepted for delivery (note that I say prefers because I 
understand we can't mandate receiver policy).

This is only a variant of #3 and not an entirely new scenario.  It's intended 
to highlight was Stephen referred to as an expected signature missing.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Aug 2006 08:36:29 -0700

> 2) C sends message on A's behalf using C's identity.

What does "using C's identity" mean?

> 3) B would like to know if C's signature has any relationship to A.

You mean things like "uses the same ISP", "operates in the same city", "uses the
same operating system"?

This list things that entail "has any relationship" is infinite.

> understand we can't mandate receiver policy).

SSP does not direct a recipient to do anything in particular.

SSP states behaviors performed by a DKIM signer (or potential signer.)

d/
-- 

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 08:39:44 -0700

>to highlight was Stephen referred to as an expected signature missing.
I think this is just scenario #1: for the intents and purposes of SSP, 
it does not
have a first party signature. I should have made that clear in the 
scenario though.

       Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 01 Aug 2006 10:50:16 -0500

I'm not sure if this needs pointing out but...

 > 2) B would like to know whether that is an acceptable state of

And, equally important, A requires a mechanism for advertising to B (and 
all the other B's) whether that is an acceptable state of affairs.

 > 2) B would like to know if C's signature has any relationship to A

Also A requires a mechanism for advertising that relationship to B (and 
all the other B's).

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 01 Aug 2006 11:08:12 -0500

> And, equally important, A requires a mechanism for advertising to B
 > (and all the other B's) whether that is an acceptable state of
 > affairs.

Given the sensitivity over the "Policy" vs "Practices" issue the above 
could be made less quarrelsome by stating it thus:

A requires a mechanism for advertising to B (and all the other B's) the 
fact that it is faithful to insert a valid signature anytime it sends mail.

-- 
Arvel

---

From: John Levine <[email-masked]>
Date: 1 Aug 2006 16:27:51 -0000

>Scenario 3a:
>1) A is a popular phishing target and prefers to suffer message
>rejections for messages that don't carry a valid signature by A (or a
>designated third party) than to have messages that are unsigned or
>signed by other parties delivered.
>4) If C's signature does not have a relationship to A, then A prefers
>that the message not be accepted for delivery

This is the same as scenario 1.  The message doesn't have A's
signature, B wants to know if that's OK.  The set of possible C's that
we don't trust is unlimited, and I can't see any point in trying to
enumerate them.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Aug 2006 17:39:58 +0100

> we don't trust is unlimited, and I can't see any point in trying to

I *think* he was trying to differentiate between:

- A says that he signs everything, and,

- A says that he signs everything and if A's sig is missing/bad A would
   like verifiers to drop/kill/whatever the message.

I've no idea if that 2nd one ought be a requirement for ssp, but I do
see the difference (and the fact that there're ratholes there!)

S.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 10:00:48 -0700

> see the difference (and the fact that there're ratholes there!)

A few points:

1) we should not get into the business of what receivers should do with
    the information; our job is only to provide the interesting bits
2) the scenarios themselves should focus on a situation in which a reciever
    is faced with. The requirements should flow from those scenarios. It 
might
    be worthwhile to note in the requirements if they pertain to a 
particular
   scenario.

       Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 01 Aug 2006 13:18:36 -0500

> 2) the scenarios themselves should focus on a situation in which a
 > reciever is faced with. The requirements should flow from those
 > scenarios.

Don't forget about domain owner's though.  They may have requirements as 
well and it is they whom we must convince that SSP is worth adopting.
These various requirements for receivers and domain owners may of course 
overlap or even be identical but I think the two groups come at the 
problem with differing motivations (although I'm not sure that matters 
in a requirements discussion).

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 01 Aug 2006 13:31:24 -0500

> - A says that he signs everything and if A's sig is missing/bad A
 >   would like verifiers to drop/kill/whatever the message.
 >

Scott has intimated elsewhere that he doesn't believe dictating verifier 
action to be a useful approach.

There should not be any requirement in our work here which mandates the 
ultimate disposition of an email message based upon verifier results. 
However, providing a mechanism which allows a receiver to determine that 
something other than what should have been expected has, in fact, 
occurred (such as an unsigned message when signing is to always be 
expected) -- this is a requirement.

I hope I'm helping because I'm not sure what exactly is being asked for 
with "requirements" (sorry, that's just me being dense).

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Tue, 1 Aug 2006 15:29:43 -0700

This explores a range of possible policy and auxiliary records and  
label scenarios as a general exercise.  Rather than repeating the  
same phase fairly often, acronyms are still used, but now are defined  
up front.  The expected drawbacks are retained to help with their  
eventual disposition.

Definitions of Terms
--------------------

Resource Record (RR): The storage element selected by type used by  
DNS containing structured content.

Resource Record Set (RRset): One or more Resource Records at a  
specific domain name.

Originator Address (OA): An email address found within the 2822.From  
header field.

Originator Address Domain (OAD): The domain of an OA.

Current Address (CA): The latest dominant email-address introduced  
per RFC2822. (The latest 2822.Resent-Sender, Resent-From, Sender, or  
From.)

Current Address Domain (CAD): The domain of an CA.

Mail From Domain (MFD): This represents the domain within the  
2821.Mail_From parameter.

Signing Domain (SD): The domain verified by a valid signature located  
by DKIM-Signature header field 'd=' parameter.

Policy Publishing Domain (PPD): The domain from where policy is  
published, excluding any special prefix for referencing the policy RR.

Designated Signing Domain (DSD): A domain contained within policy  
providing authoritative signatures for the PPD.

Non-Designated Domain (NDD): A domain not contained within policy and  
not considered authoritative for the PPD.

Designated Host-Name (DHN):  A host-name designated as being  
authoritative for the PPD.

Direct Message (DMSG): A message issued and signed by the OAD.

Indirect Message (IMSG):  A message issued on behalf of the OA and  
signed by a NDD.

Signature/Address Tuple (SAT):  The OA combined with either a valid  
signature by a DSD or a DMSG.

--------------------

=========

Problem 1:  Spoofs of the OA in phishing attempts.

Solution A:
In the case of IMSGs, OAD policy might provide a means to block  
spoofs of DMSGs.  Acceptance could be denied when OAD policy  
indicates exclusive use of DSDs, and the SD is not in conformance.

Drawback of solution A:
a) A recipient can not differentiate DMSGs from IMSGs.  Exclusive use  
of DSDs will not conform to common IMSG related services, such as  
mailing-lists or e-invites.  Policy may be ignored (see Solution B),  
the message may be annotated to indicate a level of policy assertion  
conformance, or the message may be refused when not conforming with  
policy assertions.

b) The OA may not be visually apparent or may be visually  
misleading.  When just display-names are visible, or look-alike or  
international domains are used, the recipient may be unable to  
discern the exact OA being displayed.

-----

Solution B:
Track SATs at the MUA with an address book or correspondence log, and  
then annotate messages matching an SAT.  This does not require policy  
be obtained to prevent spoofing and this also resolves look-alike  
issues.

Drawback of solution B:
This introduces a new requirement for MUAs to annotate messages based  
upon SATs, where this information should also be exchanged between  
disparate MUAs for the same user.

=========

Problem 2: Spoofs of visual content where the OA may also be  
contrived to be visually misleading in phishing attempts.

Solution C:
When a domain can be ascertained from the visual content of a  
message, this domain can be checked for DSD conformance with OAD  
policy at this domain.  Acceptance could be denied when OAD policy  
indicates exclusive use of DSDs, and the SD is not in conformance  
with this policy.

Drawback of solution C:
There is no reliable proactive means to identify cognitively similar  
message content when ascertaining the domain.  Being a niche problem,  
this would not likely have a specific policy expressed, and the lack  
of conformance with OAD policy may be prone to false positives.

-----

See Solution B.

=========

Problem 3: SMTP host-name are utilized within administrative domains  
by compromised systems for sending abusive messages, both signed and  
unsigned.

Solution D:
Authenticate the reverse DNS host-name or EHLO and then reference a  
host-name policy providing DSDs where the left-most host-name label  
is not used for the reference.  A valid DKIM signature by a DSD then  
validates the administrative' control of the message's introduction  
and demonstrates conformance with the policy.

Drawback of Solution D:
There can be an immense number of DSDs associated with an SMTP client  
host-name.  While there are techniques to efficiently resolve a large  
name:name relationship using DNS (query of <signing-domain>._policy- 
label.<publish-domain>), the maintenance of these relationships by an  
administrative domain may be daunting.

-----

Solution E:
Require that a DKIM sanctioned method be used to authenticate SMTP  
client host-names.  For example an Address RR must found at  
_dkim.<host-name> that validates the client. The EHLO could also  
encompass the _dkim.<hostname> to avoid replicate A records, and to  
signal use of dkim at the EHLO.

Drawback of Solution E:
This would only protect systems that never send email and thus would  
not have an assigned _dkim specific IP address.  However, a  
compromised system implementing DKIM signing seems unlikely protected  
by supplemental policies or records.  This protection would require  
some means to assert that host-names must provide SDs within the same  
domain, and hope that the private key was not also obtained.

=========

Problem 4: Replayed messages and bogus signatures are difficult to  
detect and effectively triage.

Solution F:
Publish a policy that returns DHNs at SDs.  After verifying the host- 
name, and finding a DHN association at the SD, invalid signature at a  
DHN can be considered bogus, and valid signatures at a DHN should not  
be considered the product of replay.

Drawback of solution F:
These relationships of possibly disparate administrative domains may  
be daunting.  These policies would not offer a basis to refuse a  
message when a DHN is not established.

=========

Problem 5: Spoofing of the CA, when the CA is not also the OA.

Solution G:
When the CAD is not within the SD, reference a specific CAD policy  
for DSDs and check for conformance.

Drawback of Solution G:
This may lead to additional loading of the DNS server when some  
verifiers attempt to validate additional header fields within the  
message.  As this field is not likely to be the target of a spoof,  
the added overhead may be considered unwarranted.

=========

Problem 6: Spoofing of the MFD.

See Solution F, except replace SD with MFD.

-----

Solution H:
Attempt to impose the OAD policy upon the MFD, in lieu of a policy  
specifically for the MFD.  This may short-cut some checks and prevent  
some possible handling delays.

Drawback of solution H:
Can only be used to bypass some checks.  Lack of an DSD association  
corresponding to the MFD can not be acted upon for refusing messages.

-----

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Aug 2006 23:54:20 +0100

Doug,

Maybe its just late in the evening here, but a mail that starts with
a list of 16 new, old, borrowed, and blue, acronyms is not IMO a way
to make what you want to say easier to understand.

I'll read it again in the morning though, maybe it'll seem worth it
then;-)
S.

Douglas Otis wrote:
> This explores a range of possible policy and auxiliary records and label 
> scenarios as a general exercise.  Rather than repeating the same phase 
> fairly often, acronyms are still used, but now are defined up front.  
> The expected drawbacks are retained to help with their eventual 
> disposition.
> 
> 
> Definitions of Terms
> --------------------
> 
> Resource Record (RR): The storage element selected by type used by DNS 
> containing structured content.
> 
> Resource Record Set (RRset): One or more Resource Records at a specific 
> domain name.
> 
> Current Address (CA): The latest dominant email-address introduced per 
> RFC2822. (The latest 2822.Resent-Sender, Resent-From, Sender, or From.)
> 
> Signing Domain (SD): The domain verified by a valid signature located by 
> DKIM-Signature header field 'd=' parameter.
> 
> In the case of IMSGs, OAD policy might provide a means to block spoofs 
> of DMSGs.  Acceptance could be denied when OAD policy indicates 
> exclusive use of DSDs, and the SD is not in conformance.
> 
> Drawback of solution A:
> a) A recipient can not differentiate DMSGs from IMSGs.  Exclusive use of 
> DSDs will not conform to common IMSG related services, such as 
> mailing-lists or e-invites.  Policy may be ignored (see Solution B), the 
> message may be annotated to indicate a level of policy assertion 
> b) The OA may not be visually apparent or may be visually misleading.  
> When just display-names are visible, or look-alike or international 
> domains are used, the recipient may be unable to discern the exact OA 
> being displayed.
> 
> -----
> 
> Solution B:
> then annotate messages matching an SAT.  This does not require policy be 
> obtained to prevent spoofing and this also resolves look-alike issues.
> 
> Drawback of solution B:
> Problem 2: Spoofs of visual content where the OA may also be contrived 
> to be visually misleading in phishing attempts.
> 
> Solution C:
> When a domain can be ascertained from the visual content of a message, 
> this domain can be checked for DSD conformance with OAD policy at this 
> domain.  Acceptance could be denied when OAD policy indicates exclusive 
> use of DSDs, and the SD is not in conformance with this policy.
> 
> Drawback of solution C:
> this would not likely have a specific policy expressed, and the lack of 
> conformance with OAD policy may be prone to false positives.
> 
> -----
> 
> See Solution B.
> 
> =========
> 
> Problem 3: SMTP host-name are utilized within administrative domains by 
> compromised systems for sending abusive messages, both signed and unsigned.
> 
> Solution D:
> host-name policy providing DSDs where the left-most host-name label is 
> not used for the reference.  A valid DKIM signature by a DSD then 
> validates the administrative' control of the message's introduction and 
> demonstrates conformance with the policy.
> 
> Drawback of Solution D:
> name:name relationship using DNS (query of 
> <signing-domain>._policy-label.<publish-domain>), the maintenance of 
> these relationships by an administrative domain may be daunting.
> 
> -----
> 
> Solution E:
> This would only protect systems that never send email and thus would not 
> have an assigned _dkim specific IP address.  However, a compromised 
> system implementing DKIM signing seems unlikely protected by 
> supplemental policies or records.  This protection would require some 
> means to assert that host-names must provide SDs within the same domain, 
> and hope that the private key was not also obtained.
> 
> =========
> 
> Publish a policy that returns DHNs at SDs.  After verifying the 
> host-name, and finding a DHN association at the SD, invalid signature at 
> a DHN can be considered bogus, and valid signatures at a DHN should not 
> These relationships of possibly disparate administrative domains may be 
> daunting.  These policies would not offer a basis to refuse a message 
> when a DHN is not established.
> 
> =========
> 
> When the CAD is not within the SD, reference a specific CAD policy for 
> DSDs and check for conformance.
> 
> Drawback of Solution G:
> message.  As this field is not likely to be the target of a spoof, the 
> added overhead may be considered unwarranted.
> 
> =========
> 
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 12:35:08 +0100

Doug,

I don't see how your problems, other than 1, are in scope for SSP.
Can you explain why they are, without recourse to any acronyms and
in a sentence or two each?

S.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Aug 2006 10:19:16 -0700

> in a sentence or two each?

For the most part, Problem 1 together with Solution A is currently  
being discussed, but this should not be seen as a forgone  
conclusion.  Solution A is generally related to an effort aimed at  
preventing spoofing by blocking messages.  The downside of this  
approach is that mailing lists and related services will no longer  
function.  This might be a reasonable solution for transactional  
messages related to commerce, but this would not be a reasonable  
solution for general use.  Such a (mis)application of policy would  
likely cause support related havoc.  Ignoring the disruptive aspect,  
the Threat draft also indicates Solution A has serious weaknesses.   
The disruption and these weaknesses are resolved by Solution B however.

As Solution B mentions, there is a more effective and less disruptive  
approach where policy information is also less frequently accessed.   
The requisite information for Solution B would be a list of  
designated signing domains.  This list overlaps much of the same  
information provided for Solution A.  Problem 2, which is both a  
common ploy and a serious problem, is not resolved by Solution A  
which is also why Problem 2 may seem out of scope.  The difference in  
the information presented to Solution A from that of Solution B is  
likely just a flag indicating an exclusive (disruptive) use of the  
designated signing domains.  Solution B however resolves Problem 2 by  
using virtually the same information as required for Solution A.

Solution B at first glance may seem to not require any policy  
information.  A designated signing domain list indicating which  
domains are considered authoritative for the rfc2822 From header  
identity allows smaller outfits an ability to leverage providers  
offering DKIM services signed under a common domain.  These DKIM  
providers should require users to both authenticate and demonstrate  
their reception of messages sent to email addresses they wish to  
use.  This would be little different than the techniques used to  
subscribe to a mailing list.  As indicated in the SAT definition, the  
tuple is qualified as being a member of a designated signing domain  
for the rfc2822 From header identity.  The infrequent need to qualify  
the tuple being retained and later used to annotate messages would be  
when this policy information is acquired.   This approach also does  
not require _any_ searching for policy and will _not_ disrupt email  
delivery.  Solution B will also be effective at resolving both  
Problem 1 and 2, whereas Solution A is not effective.

The remaining problems and solutions assume policy can be expressed  
by different records for different purposes.

Problem 3 is also a serious problem and is responsible for much, if  
not most, of the abusive email.  With DKIM's slightly higher  
overhead, concurrently curtailing some of this abusive traffic should  
help ensure DKIM introduction provides a positive experience.   
Solution D parallels a similar solution previously tried by a prior  
WG.  As the drawback for this approach indicates, the related policy  
information would be immensely difficult to manage.

Solution E however offers an approach that should be very easy to  
manage.  Even with this being easy, it is difficult to convince  
administrators of a need for this change.  Solution E announces the  
use of DKIM at the EHLO and indicates there is an assured method to  
authenticate the client beforehand.  When making modifications in DNS  
for keys and policy, introducing this change as a policy should also  
prove effective at quelling Problem 3.  To help promote this  
approach, a flag is the DKIM sender's policy might also indicate that  
this client method of authentication MUST be used by "this" domain.

Until Problem 4 actually becomes a problem, there is likely little  
desire to work through the details or consider other related  
solutions.  Solution F would also be difficult to manage.  Perhaps  
Solution E will prove effective and these issues will never warrant  
further consideration. : )

Problem 5 was raise by Tony.  It seems that it should be covered by a  
review.

Problem 6 is a real problem where I suspect unexpected application of  
policy may occur.  Although perhaps a rat-hole, some advice might be  
included in the draft regarding attempts a Solution H.

This was a review, where Solutions A, C, D, F, G, and H are not be  
recommended.  There should be greater focus on Problems 1, 2, and 3,  
and Solutions B and E.

-Doug

>> same phase fairly often, acronyms are still used, but now are  
>> defined up front.  The expected drawbacks are retained to help  
>> with their eventual disposition.
>> Definitions of Terms
>> --------------------
>> Originator Address (OA): An email address found within the  
>> 2822.From header field.
>> per RFC2822. (The latest 2822.Resent-Sender, Resent-From, Sender,  
>> or From.)
>> Signing Domain (SD): The domain verified by a valid signature  
>> located by DKIM-Signature header field 'd=' parameter.
>> Non-Designated Domain (NDD): A domain not contained within policy  
>> and not considered authoritative for the PPD.
>> Signature/Address Tuple (SAT):  The OA combined with either a  
>> valid signature by a DSD or a DMSG.
>> --------------------
>> =========
>> a) A recipient can not differentiate DMSGs from IMSGs.  Exclusive  
>> use of DSDs will not conform to common IMSG related services, such  
>> as mailing-lists or e-invites.  Policy may be ignored (see  
>> Solution B), the message may be annotated to indicate a level of  
>> policy assertion conformance, or the message may be refused when  
>> not conforming with policy assertions.
>> Track SATs at the MUA with an address book or correspondence log,  
>> and then annotate messages matching an SAT.  This does not require  
>> policy be obtained to prevent spoofing and this also resolves look- 
>> alike issues.
>> Drawback of solution B:
>> This introduces a new requirement for MUAs to annotate messages  
>> based upon SATs, where this information should also be exchanged  
>> between disparate MUAs for the same user.
>> =========
>> There is no reliable proactive means to identify cognitively  
>> similar message content when ascertaining the domain.  Being a  
>> niche problem, this would not likely have a specific policy  
>> expressed, and the lack of conformance with OAD policy may be  
>> prone to false positives.
>> -----
>> See Solution B.
>> =========
>> Problem 3: SMTP host-name are utilized within administrative  
>> domains by compromised systems for sending abusive messages, both  
>> signed and unsigned.
>> Solution D:
>> Authenticate the reverse DNS host-name or EHLO and then reference  
>> a host-name policy providing DSDs where the left-most host-name  
>> label is not used for the reference.  A valid DKIM signature by a  
>> DSD then validates the administrative' control of the message's  
>> introduction and demonstrates conformance with the policy.
>> Drawback of Solution D:
>> There can be an immense number of DSDs associated with an SMTP  
>> client host-name.  While there are techniques to efficiently  
>> resolve a large name:name relationship using DNS (query of  
>> <signing-domain>._policy-label.<publish-domain>), the maintenance  
>> of these relationships by an administrative domain may be daunting.
>> -----
>> Solution E:
>> encompass the _dkim.<hostname> to avoid replicate A records, and  
>> to signal use of dkim at the EHLO.
>> Drawback of Solution E:
>> This would only protect systems that never send email and thus  
>> would not have an assigned _dkim specific IP address.  However, a  
>> compromised system implementing DKIM signing seems unlikely  
>> protected by supplemental policies or records.  This protection  
>> would require some means to assert that host-names must provide  
>> SDs within the same domain, and hope that the private key was not  
>> also obtained.
>> =========
>> host-name, and finding a DHN association at the SD, invalid  
>> signature at a DHN can be considered bogus, and valid signatures  
>> at a DHN should not be considered the product of replay.
>> Drawback of solution F:
>> These relationships of possibly disparate administrative domains  
>> may be daunting.  These policies would not offer a basis to refuse  
>> a message when a DHN is not established.
>> =========
>> specifically for the MFD.  This may short-cut some checks and  
>> prevent some possible handling delays.
>> Drawback of solution H:
>> Can only be used to bypass some checks.  Lack of an DSD  
>> association corresponding to the MFD can not be acted upon for  
>> refusing messages.
>> -----
>> -Doug