Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-02.txt

From: [email-masked]
Date: Fri, 1 Feb 2008 13:15:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

	Title           : DKIM Sender Signing Practices
	Author(s)       : E. Allman, et al.
	Filename        : draft-ietf-dkim-ssp-02.txt
	Pages           : 19
	Date            : 2008-02-01

DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transport Agents (MTAs) or Mail
User Agents (MUAs).  The primary DKIM protocol is described in
[RFC4871].

This document describes the records that authors' domains can use to
advertise their practices regarding signing their outgoing mail, and
how other hosts can access, parse and interpret those records.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-dkim-ssp-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dkim-ssp-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 1 Feb 2008 13:49:04 -0800

This draft goes to the opposite extreme of the ASP draft and increases  
the restrictions for "all" compliance as well. This draft indicates  
_ALL_ messages are to include a signature with an i= parameter matches  
that of an identity within the From header.  This is not the defined  
use for RFC 4871.

The ASP approach creates fewer corner cases.  At least with the ASP  
draft, any risk of misuse remains within the control of a domain to  
rectify.

IMHO, unless the SSP draft is changed to comply with RFC 4871, the WG  
should consider adopting the ASP draft instead.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Fri, 01 Feb 2008 14:58:47 -0800

> that of an identity within the From header.  This is not the defined 

It is true that RFC 4871 does not require or define any binding between 
the i= parameter and the From header field (or any other header field, 
for that matter).  That is defined by *SP.  The question is really the 
nature of that binding:  whether it's the entire address (in cases where 
i= has a local-part) or whether it's just the domain.  That seems to be 
what's at the heart of issue 1519.
> draft, any risk of misuse remains within the control of a domain to 

This last statement I don't understand.  Can you give an example of 
"misuse within the control of a domain" that is introduced by matching 
the local-part?

-Jim

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Feb 2008 18:18:18 -0500

Douglas Otis wrote:
> that of an identity within the From header.  This is not the defined use 
> for RFC 4871.
> 

First, I don't agree that SSP did not comply with RFC 4871.

Second, I for one am tired of this stuff going on in this WG.

For all intent and purposes this ASP Adaptation is essentially the same 
document, the same copy of SSP with essentially the term Originator 
changed to Author. It has a removal of verifier semantics and 3rd party 
issues, and alters the SSP DKIM=ALL definition with a flawed concept of 
ASP DKIM=ALL having no failure potential.  It has the same issues as the 
SSP document. It offers no solutions to key issues discussed over the years.

In addition, bulk mailers, which this ASP documents attempts to focus 
on, are going to experience a negative exploitation by bad people using 
the suggested DKIM=ALL policy with fake signatures.

ASP::DKIM=DISCARDABLE is 100% the same as SSP DKIM=STRICT so I don't 
even know why it was even considered as "new."

ASP::DKIM=ALL attempts to enforce the idea that failure is an acceptable 
conclusion, even if comes with an unexpected 3rd party signatures.

If ASP is adopted or SSP-02 with its ASP twist is adopted, it is going 
to have a negative effect on receivers and domains in the general case. 
It envision when receivers see no payoff and are going to mostly reduce 
DKIM overhead by ignoring it completely.

I don't see any more hope in this WG for a policy technology that is 
going to help DKIM signers.   It appears Jim/Eric has succumbed to the 
pressure of a limited group of self-interest consortium that surely do 
not represent the entire community of domains and mail receivers.

-- 
Sincerely

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 1 Feb 2008 15:44:29 -0800

On Feb 1, 2008, at 2:58 PM, Jim Fenton wrote:

> Douglas Otis wrote:
>> This draft goes to the opposite extreme of the ASP draft and  
>> increases the restrictions for "all" compliance as well. This draft  
>> indicates _ALL_ messages are to include a signature with an i=  
>> parameter matches that of an identity within the From header.  This  
>> is not the defined use for RFC 4871.
>
> It is true that RFC 4871 does not require or define any binding  
> between the i= parameter and the From header field (or any other  
> header field, for that matter).  That is defined by *SP.  The  
> question is really the nature of that binding:  whether it's the  
> entire address (in cases where i= has a local-part) or whether it's  
> just the domain.  That seems to be what's at the heart of issue 1519.

You mean the i= binding is required by SSP.  ASP only requires domains  
to match.  IMHO, even that is too restrictive.  ASP should have  
permitted signing domains at or above the From header.  Only when the  
t=s parameter is asserted within the key, would there be a need for  
domains to match.

> "misuse within the control of a domain" that is introduced by  
> matching the local-part?

A domain using RFC 4871 as defined might wish to clarify which entity  
had been authenticated.  Such authentication information would help  
prevent intra-domain spoofing.  SSP essentially prevents a single  
signature from offering identity assurances when a message is being  
redirected (Resent-From header) or being sent on behalf of (Sender  
header) the From header.  Is it really reasonable for an MTA to add  
two signatures, one ambiguous and the other identity specific?  An  
additional signature is only needed because of the SSP definition for  
a compliant Author's signature.  There is enough information within a  
signature added on-behalf-of (i=) of the Resent-From header for  
compliance to be ascertained without also requiring an additional  
ambiguous signature (no local-part).

ASP seems like the better of the two approaches.  Eventually, MUAs  
will be doing there right thing.  Until then, it is important  
compliance requirements not lead to the use of falsified or ambiguous  
information.  The i= parameter could also be a temporal value not  
matching with any header when privacy is considered important.  A  
temporal value could provide a means to control abuse without exposing  
the provider's customer's identity.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 1 Feb 2008 15:52:52 -0800

On Feb 1, 2008, at 3:18 PM, Hector Santos wrote:

>> IMHO, unless the SSP draft is changed to comply with RFC 4871, the  
>> WG should consider adopting the ASP draft instead.
>

No. RFC 4871 does not comply with SSP.

> For all intent and purposes this ASP Adaptation is essentially the  
> same document, the same copy of SSP with essentially the term  
> Originator changed to Author.

I strongly disagree.  Please review the differences.

Per ASP:

2.8.  Author Signature

  An "Author Signature" is any Valid Signature where the *signing  
domain*
  (listed in the "i=" tag if present, otherwise its default value,
  consisting of the value of the "d=" tag) matches the domain of an
  Author Address.

Per SSP:

2.8.  Author Signature

  An "Author Signature" is any Valid Signature where the *identity* of
  the user or agent on behalf of which the message is signed (listed in
  the "i=" tag or its default value from the "d=" tag) matches an
  Author Address in the message.

IMHO, ASP is a far better definition and does not impose changes with  
respect to how RFC 4871 might be used.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Feb 2008 19:11:44 -0500

Douglas Otis wrote:
>  An "Author Signature" is any Valid Signature where the *signing domain*

So just a rephrasing of a sentence makes this a different a new and 
competing and better PROTOCOL?  You got to be kidding me.  No wonder we 
are not going to get anything done around here - at least not something 
that can only be cherished by a limited group.

It is basically all the same text just reworded. ASP is not different 
enough to view it as a alternative protocol - it is still SSP with 
SEMANTICS changes.

And for the matter, SSP-02 is ASP and ASP is SSP-02.  The question is 
who gets credit for the now flawed and watered down draft.

-- 
Sincerely

Hector Santos, CTO

---

From: Jim Fenton <[email-masked]>
Date: Fri, 01 Feb 2008 16:42:27 -0800

> ambiguous signature (no local-part).

SSP has no relationship with the Resent-From, Sender, and similar header 
fields.  Is the root issue here that you would like it to do so?  If I 
remember correctly, your draft proposes this, but I have seen no 
consensus to deviate from the requirements in this way.

On the other hand, matching the local-part of i= (when it is present) 
prevents a signature that may be associated with a Sender or Resent-From 
address that happens to be in the same domain as the From address, from 
being misinterpreted as an Author Signature when it's not.

-Jim

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 01 Feb 2008 20:03:57 -0600

The architecture of this new draft is hopefully acceptable to everyone.  
Good work here IMO.  I support these changes.

Arvel

---

From: Michael Thomas <[email-masked]>
Date: Fri, 01 Feb 2008 18:16:42 -0800

Arvel Hathcock wrote:
> The architecture of this new draft is hopefully acceptable to 
> everyone.  Good work here IMO.  I support these changes.

I think it's time for a group hug and buy Arvel a last call beer.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Fri, 01 Feb 2008 22:29:11 -0500

> No. RFC 4871 does not comply with SSP.

How so?

 From my standpoint, ASP/SSP-02 both provided unprotected considerations 
in DKIM-BASE.

ASP::DISCARDABLE completely changes the semantics of DKIM-BASE failures 
state change to "no signature" to one where a failed signature exist.

Likewise ASP::ALL offers no protection against fraudulent 3rd party 
signers.  This is not what I call adding a SECURITY WRAPPER around the 
DKIM-BASE signing expectations whether forged 1st or 3rd party.

--
HLS

---

From: Eliot Lear <[email-masked]>
Date: Sat, 02 Feb 2008 12:18:17 +0100

> should consider adopting the ASP draft instead.

Please indicate the paragraph in RFC 4871 that this draft would conflict 
with.

Thanks,

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Sat, 2 Feb 2008 09:34:45 -0800

On Feb 1, 2008, at 4:42 PM, Jim Fenton wrote:

>> A domain using RFC 4871 as defined might wish to clarify which  
>> entity had been authenticated.  Such authentication information  
>> would help prevent intra-domain spoofing.  SSP essentially prevents  
>> a single signature from offering identity assurances when a message  
>> is being redirected (Resent-From header) or being sent on behalf of  
>> (Sender header) the From header.  Is it really reasonable for an  
>> MTA to add two signatures, one ambiguous and the other identity  
>> specific?  An additional signature is only needed because of the  
>> SSP definition for a compliant Author's signature.  There is enough  
>> information within a signature added on-behalf-of (i=) of the  
>> Resent-From header for compliance to be ascertained without also  
>> requiring an additional ambiguous signature (no local-part).
>
> SSP has no relationship with the Resent-From, Sender, and similar  
> header fields.  Is the root issue here that you would like it to do  
> so?  If I remember correctly, your draft proposes this, but I have  
> seen no consensus to deviate from the requirements in this way.
>
> On the other hand, matching the local-part of i= (when it is  
> present) prevents a signature that may be associated with a Sender  
> or Resent-From address that happens to be in the same domain as the  
> From address, from being misinterpreted as an Author Signature when  
> it's not.

Both SSP and ASP establish policies that assure the presence of a  
domain's signature for all From email-addresses.  As some suggested,  
there might be a desire to extend policy protections to the Sender  
header as well.  Sender and From email-address protections can be an  
option without creating any RFC 4871 signing changes provided the  
definition of an "Author Signature" does not mandate use of specific  
identities.

When a signature by a domain is valid, the message can be assumed to  
comply with the domain's policies.  After all, messages that do not  
comply with a domain's signing policy must not be signed.  Signatures  
including the identity of the From header is not necessary to obtain  
an assurance of policy compliance.  However SSP's "Author Signature"  
definition adds an unnecessary local-part stipulation!  The ASP Author  
Signature definition acknowledges that policy is assured by the  
domain's signature.

The only caveat might be with restricted keys.  In this case, a domain  
is trusting those given restricted keys to not generate misleading  
messages.  For those that wish to give restricted keys to  
untrustworthy entities, the simplest solution would be to define  
Author Signatures as those matching domains (as does ASP's  
definition), but with an added condition that signatures for other  
identities with restricted keys are excluded.  At least, not adding  
the restricted key caveat will not reduce the information given  
receivers.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sat, 2 Feb 2008 12:57:20 -0800

On Feb 2, 2008, at 3:18 AM, Eliot Lear wrote:

> Please indicate the paragraph in RFC 4871 that this draft would  
> conflict with.

RFC 4871:
,---
3.5. The DKIM-Signature Header Field
...
i= Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed (dkim-quoted-printable;  
OPTIONAL, default is an empty Local-part followed by an "@" followed  
by the domain from the "d=" tag). The syntax is a standard email  
address where the Local-part MAY be omitted. The domain part of the  
address MUST be the same as or a subdomain of the value of the "d=" tag.
'___
RFC 4871 clearly indicates the i= parameter is _intended_ to identify  
the user or agent for which the message is being signed.  When a  
signature is added on-behalf-of an entity whose email-address is found  
within the Sender header, and where the message happens to include a  
 From address within the same domain, the definition for Author  
Signature within the SSP makes the signature specified by RFC 4871 non- 
compliant with an "all" or "discardable" policy assertions, however  
the definition within ASP does not.  SSP stipulations changes RFC 4871  
signature handling to not use the i= parameter when there might be  
such a conflict with the From header.  Not surprisingly, RFC 4871  
never suggested the i= parameter not be used when there might be a  
conflict with an address within the From header.  This definition  
ensures the i= parameter will:
1) be falsified to include the From header email-address.
2) exclude the local-part to remain ambiguous.
3) necessitate multiple signatures to overcome ambiguities created by  
option 2.

SSP-02:
,---
2.6.  Author Address

  The "Author Address" is an email address in the From header field of
  a message [RFC2822].  If the From header field contains multiple
  addresses, the message has multiple Author Addresses, which may
  potentially cause the Evaluator to perform multiple SSP Checks for a
  given message.

2.8.  Author Signature

  An "Author Signature" is any Valid Signature where the identity of
  the user or agent on behalf of which the message is signed (listed in
  the "i=" tag or its default value from the "d=" tag) matches an
  Author Address in the message.
  '___
The SSP Author Signature definition essentially makes use of the i=  
parameter when the identity is not found within the From header  
problematic.  As the i= parameter is the only field that pertains to  
actual agent, it might be obfuscated by the signing domains using  
temporal hashing, but could be useful for tracking, for example.  Per  
the Author Signature definition in SSP, this type of use will require  
multiple signatures.  The additional overhead of multiple signatures  
is not necessary and represents a waste of resources or the  
prohibition of many uses for the i= parameter.
-Doug

---

From: Hector Santos <[email-masked]>
Date: Sat, 02 Feb 2008 22:40:55 -0500

Douglas Otis wrote:

> Signature within the SSP makes the signature specified by RFC 4871 
> non-compliant with an "all" or "discardable" policy assertions, however 
> the definition within ASP does not.  

Sorry, I don't see it.  I am going to ignore ASP/SSP-02 and deal with 
SSP-01 because it is well understood and not subject to the majors 
security issues in ASP/SSP-02.

DKIM=ALL means ANYONE can sign, but it must be signed.
DKIM=STRICT it must be signed by the AUTHOR (ORIGINATING DOMAIN).

This would be a 1PS:

    From: [email-masked]
    Sender: [email-masked]
    DKIM-Signature:  d=domain1.com i=[email-masked]
                     h= may include Sender: binding

For a 1PS scenario, domain1.com SSP policy can be:

    DKIM=unknown    (weak protection)
    DKIM=ALL        (protection against non-signed mail)
    DKIM=STRICT     (protection against non-signed mail and 3PS)

This would be a 3PS:

    From: [email-masked]
    Sender: [email-masked]
    DKIM-Signature:  d=listdomain.com i=[email-masked]
                     h= SHOULD (good idea) include Sender: binding
                        since it was the signer.

For a 3PS scenario, domain1.com SSP policy can be:

    DKIM=unknown    (weak protection)
    DKIM=ALL        (protection against non-signed mail)

Per 4871, if i= is used, which is OPTIONAL, the domains of d= and i= 
must be the same or be a sub-domain of d=.

Per x822, Sender: is OPTIONAL and not a network required control header. 
  It is more information than anything else.  Furthermore, not everyone 
supports Sender: unlike From: which is a requirement.

I see no conflict.

 > SSP stipulations changes RFC 4871
> signature handling to not use the i= parameter when there might be such 
> a conflict with the From header.  

Per 4871, if i= is used, which is OPTIONAL, the domains of d= and i= 
must be the same

Per x822, Sender: is OPTIONAL and not a network required control header.

> Not surprisingly, RFC 4871 never 
> suggested the i= parameter not be used when there might be a conflict 
> with an address within the From header.  

What conflict?

It is clear in 4871 section 6.3:

    If the message is
    signed on behalf of any address other than that in the From: header
    field, the mail system SHOULD take pains to ensure that the actual
    signing identity is clear to the reader.

The logical association implies for this to be:

       ([i] == d) != From

which is the fundamental basis for a 3rd party Signing operation.  Like 
wise, the logical association for a 1st party signature is:

       ([i] == d) == From

We need to keep our eye on the prize here and that is DOMAIN protection, 
to assist it in keeping with its new asserted DKIM-BASE "social and 
ethical" responsibility.   SSP is basically a fraud detection or 
protocol consistency checker.  If everything is koshser, I believe no 
one has ever said SSP allows a message to pass or skip any other testing.

Traditionally, by far, the From: is the author of the message. It is 
reflective in all mail systems.  The author does not mean it has to be 
the signer, and I hope no one is claiming a 3rd party signer is an 
AUTHOR and/or copyright holder of the message content.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sun, 3 Feb 2008 09:42:23 -0800

On Feb 2, 2008, at 7:40 PM, Hector Santos wrote:

> Douglas Otis wrote:
>
>> RFC 4871 clearly indicates the i= parameter is _intended_ to  
>> identify the user or agent for which the message is being signed.   
>> When a signature is added on-behalf-of an entity whose email- 
>> address is found within the Sender header, and where the message  
>> happens to include a  From address within the same domain, the  
>> definition for Author Signature within the SSP makes the signature  
>> specified by RFC 4871 non-compliant with an "all" or "discardable"  
>> policy assertions, however the definition within ASP does not.
>
> Sorry, I don't see it.  I am going to ignore ASP/SSP-02 and deal  
> with SSP-01 because it is well understood and not subject to the  
> majors security issues in ASP/SSP-02.
>

FYI, DKIM=strict is now DKIM=discardable

So much for assertions based upon a perspective of what the signer  
does, and not attempting to dictate what an evaluator can do. : (

>                   h= SHOULD (good idea) include Sender: binding

Agreed.

But this 3PS type of message signature was the concern.

From: [email-masked]
Sender: other-person@.example.com
DKIM-Signature:  d=expample.com i=[email-masked] (g=*)

This message is clearly signed by example.com per RFC 4871, but where  
a SSP policy assertion of either "all" or "discardable" might cause  
this ABSOLUTELY valid message to be dropped as being non-compliant.   
(Hard to define compliance with the "discardable" assertion isn't it?   
Too bad this was not discussed on the WG list.)

>> SSP stipulations changes RFC 4871 signature handling to not use the  
>> i= parameter when there might be such a conflict with the From  
>> header.
>

Agreed, however the issue was with respect to the local-part [email-masked] 
  not meeting the requirements for "Author Signature" in SSP, however  
it does meet these requirements in ASP.

>> Not surprisingly, RFC 4871 never suggested the i= parameter not be  
>> used when there might be a conflict with an address within the From  
>> header.
>
> What conflict?
>
>  If the message is signed on behalf of any address other than that
>  in the From: header field, the mail system SHOULD take pains to
>  ensure that the actual signing identity is clear to the reader.

DKIM is silent upon what might be displayed.

> which is the fundamental basis for a 3rd party Signing operation.   
> Like wise, the logical association for a 1st party signature is:
>
>     ([i] == d) == From

You appear to be describing a comparison stated in ASP, and not the  
comparison in SSP.

> We need to keep our eye on the prize here and that is DOMAIN  

Agreed.

> protocol consistency checker.  If everything is koshser, I believe  
> no one has ever said SSP allows a message to pass or skip any other  
> testing.

It would seem better to describe this as a means to evaluate  
compliance with Sender assertions pertaining to what the transmitting  
indicates as their handling practices.  This view makes less sense  
when the assertion is "discardable".

> reflective in all mail systems.  The author does not mean it has to  
> be the signer, and I hope no one is claiming a 3rd party signer is  
> an AUTHOR and/or copyright holder of the message content.

The concern is when the message is signed by the author's domain, but  
on-behalf-of someone else with the author's domain.  When this domain  
applies their signature, their signing policy MUST evaluate whether "[email-masked] 
" is able to include "[email-masked]" with the From header.  It  
would be ridiculous to expect to have this policy applied by a  
possible verifier.  As you said, DKIM is about establishing  
responsibility _at_ the domain.  When the domain is held accountable,  
as designed in RFC 4871, the local-part introducing the message does  
not matter.  The local-part might be highlighted by the MUA to  
indicate who introduced the message, but as far as signing policy  
should be concerned, local-part is immaterial.

The local-part is only material when the key is g= restricted.  It  
seems reasonable for the the WG to make an exception for restricted  
keys.   Compliance could be defined as being met by a g= restricted  
key only when the associated identity is within the From header.  The  
use of g= restricted keys implies a signature added by an entity of  
limited trust where the domain may not be afforded an opportunity to  
establish compliance when the related identity is not within the From  
header.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 4 Feb 2008 02:44:15 +0100

Hector Santos wrote:

> Per x822, Sender: is OPTIONAL and not a network required
> control header. It is more information than anything else.

We are not reading the same copy of 2822upd.

| If the originator of the message can be indicated by a 
| single mailbox and the author and transmitter are identical,
| the "Sender:" field SHOULD NOT be used.  Otherwise, both
| fields SHOULD appear.
|
| Note: The transmitter information is always present.  The
| absence of the "Sender:" field is sometimes mistakenly
| taken to mean that the agent responsible for transmission
| of the message has not been specified.  This absence merely
| means that the transmitter is identical to the author and
| is therefore not redundantly placed into the "Sender:"
| field.

> Furthermore, not everyone supports Sender: unlike From:
> which is a requirement.

A Sender is recommended (SHOULD) when it is not redundant, 
and it is required (MUST) for more than one author:

| sender  |  0*  |  1  |  MUST occur with multi-address from

Your claim that Sender is "OPTIONAL" per x822 is wrong.

> Per x822, Sender: is OPTIONAL and not a network required

Two wrongs don't make this right.  With wrong premises your
conclusions can be anything you wish.

 Frank

---

From: Hector Santos <[email-masked]>
Date: Sun, 03 Feb 2008 21:51:36 -0500

> We are not reading the same copy of 2822upd.

You're right.  We are talking about the current standards, 822 and 2822, 
which ever you wish to follow.

PER RFC 822, the Minimum Requirement is:

      A.3.  COMPLETE HEADERS

      A.3.1.  Minimum required

      Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
      From:     [email-masked]   or   From:     [email-masked]
      Bcc:                                To:       [email-masked]

         Note that the "Bcc" field may be empty, while the  "To"  field
         is required to have at least one address.

If a system is running in legacy mode, that you are incorrect to state 
it is a required.  Are you ready to state that legacy systems do not 
exist or even modern systems who for some reason or another choose to 
run in legacy mode?

PER RFC 2822,

     The only required header fields are the origination date field and
     the originator address field(s).

Per section 3.6.2 SENDER SHOULD only be used when the FROM is not the 
actual transmitter of the message.   It is stated very clear:

    If the originator of the message can be indicated
    by a single mailbox and the author and transmitter are identical, the
    "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
    appear.

Therefore, as I said, it is not a REQUIRED field and only useful when 
the AUTHOR is not the actual transmitter.

For you to state it is a requirement in ALL cases and therefore implying 
it is a fundamentally essential for email operations, well, you know 
perfectly well it is not true.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 4 Feb 2008 08:26:06 +0100

Hector Santos wrote:
 
> If a system is running in legacy mode, that you are incorrect 
> to state it is a required.

I have not the faintest idea what "legacy mode" is.  The Sender
issue was answered on the rfc822 list:

<http://article.gmane.org/gmane.ietf.rfc822/12147> (Pete)
<http://article.gmane.org/gmane.ietf.rfc822/12148> (me)

As far as I'm concerned that's the last nail in the PRA coffin.

> Therefore, as I said, it is not a REQUIRED field

That's not what you said, you said OPTIONAL.  Sender is REQUIRED
for multiple authors, and RECOMMENDED for author != transmitter.

 Frank

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Feb 2008 03:15:25 -0500

Frank Ellermann wrote:
> I have not the faintest idea what "legacy mode" is.  

You're kidding me?

 > The Sender issue was answered on the rfc822 list:
> 

I read your post which appears to be an answer to your own question and 
also Pete's input.

Besides the fact you misquoted me, I don't agree with your implication 
that Sender is a MUST header. The fact is, both RFC 822 and RFC 2822 say:

    If the originator of the message can be indicated by a single
    mailbox and the author and transmitter are identical, the
    "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
    appear.

And the above is a two decade plus practice, you nor Pete is not going 
to change this.  Are you suggesting it was always wrong?

> for multiple authors, and RECOMMENDED for author != transmitter.

Read again.  Under ANY condition, for it to be REQUIRED, it must say 
MUST.  It does not say MUST. It says SHOULD, That is not a MUST, and 
even though 2119 says you should have a good reason to not follow the 
recommendation, it implication is such that it is and was always 
OPTIONAL regardless of what you or Pete says..  To not be OPTIONAL, is 
must be a MUST and that is not what we have here.  You can throw all the 
docs you want at me, it isn't going to change the reality.

Look at it this way:

What you are implying, and this is where docs people might ought to try 
not always be wearing designer hats as well, that SMTP receivers has 
this a mandate to alter the message for the purpose of adding a 
"Required" Sender: header by analyzing the 2822 headers during 
submission and automatically add the missing sender field if the x821 
return path does not equal x822 From header.

Well, this imply this mandate exist and to suggest this is the general 
case or even popular one, well, you would not be correct.

The only widespread standard requirement for SMTP receivers is to add 
the Received: line.  Period. Expecting anything more is dubious.

Look, Sender, if used, is typically added when its not the real author 
sending the original message. Period.  Not all systems add it simply 
because it was never a requirement.  Sender is what it is for the past 2 
decades, you nor Pete nor I is going to change that.   Even if current 
systems updated their wares to better support it,  you still need to 
deal with legacy systems, and in my view, this is not something to be 
forcing down people's throats.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Feb 2008 13:15:46 -0500

> DKIM-Signature:  d=expample.com i=[email-masked] (g=*)

But this isn't a 3rd party signature. The signing domain is the same as 
  the from domain, or did you try to throw in a "near-phish" domain, or 
is that a typo?  "exPample.com"  ???

> This message is clearly signed by example.com per RFC 4871, but where a 
> SSP policy assertion of either "all" or "discardable" might cause this 
> ABSOLUTELY valid message to be dropped as being non-compliant.  

I don't see what you are talking about here. Where is the problem?
Which specification are you talking about?   Is this really a valid 
message?

 > Too bad this was not discussed on the WG list.)

It like you forced a non-compliance a ASP. :-)

But if you really meant the above being a near-phish, exPample.com, then 
  this goes to illustrate how ASP will harm the primary domain.

Plus, you didn't indicate if the Sender= was bound to the signature or not.

>>> i= parameter when there might be such a conflict with the From header.
>>
> Agreed, however the issue was with respect to the local-part 
> [email-masked] not meeting the requirements for "Author 
> Signature" in SSP, however it does meet these requirements in ASP.

Its hard to continue a thought process in what is a flawed concept.

Even then, all I see above is either a typo or an intentional 3PS based 
on a near-phish.  If that is the case, then you just showed quite 
clearly, how the author domain EXAMPLE.COM has just been exploited with 
less means of protecting it.

> You appear to be describing a comparison stated in ASP, and not the 

Huh? the above logic has been the basis for 3rd vs 1rd party signature 
(respectively) since the beginning.

>> We need to keep our eye on the prize here and that is DOMAIN protection,

You do?  How can you support ASP when it doesn't help protect domains 
from 3rd party abuse?   You just illustrated this above.

> It would seem better to describe this as a means to evaluate compliance 
> with Sender assertions pertaining to what the transmitting indicates as 
> their handling practices.  This view makes less sense when the assertion 
> is "discardable".

Now you really lost me. :-)

Are you suggesting even DISCARDABLE is no good?   You want to further 
water down SSP or whatever you wish to call it ASP?

> applies their signature, their signing policy MUST evaluate whether 
> "[email-masked]" is able to include "[email-masked]" with 
> the From header.  It would be ridiculous to expect to have this policy 
> applied by a possible verifier.  As you said, DKIM is about establishing 
> responsibility _at_ the domain.  When the domain is held accountable, as 
> designed in RFC 4871, the local-part introducing the message does not 
> matter.  The local-part might be highlighted by the MUA to indicate who 
> introduced the message, but as far as signing policy should be 
> concerned, local-part is immaterial.

I think I agree with the statement but I am not seeing the problem, 
maybe because the above example had typos?

> The local-part is only material when the key is g= restricted. 

I'm going to take your word on this. It sound's reasonable, but I think 
overall, this is now really a moot point because ASP has made DKIM-BASE 
a less attractive idea to pursue.   Too much fraud is possible now.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Feb 2008 06:59:05 -0500

>>RFC 822 and RFC 2822 say:
>>
>>And the above is a two decade plus practice, you nor Pete is not
>>going to change this.
>
>Not only did my statement *not* change the above, I have no desire to
>change it. I wrote those words almost 7 years ago (as per the
>consensus of the DRUMS working group), and I still believe they
>reflect the consensus of the community.

Hmmm, Pete, the exact statement above has not changed since 1982 (RFC 
822).  Seems like DRUMS just confirmed what already preexisted in RFC 
822 and in common practice by 2001 for nearly 20 years and passed on to 
RFC 2822.

IMO, there is simply no practical reason for changing this to a MUST 
which I believe Frank is proposing (put it up for a vote).

Unless you are saying a SHOULD is really a MUST because no one will have 
a good reason to not honor a SHOULD, and therefore they would be 
considered "bad" implementations because they are miss reading the 
specifications by not following a SHOULD even if their reasons are not 
acceptable by their peers, then I think I will stick with the technical 
layman excuse that a SHOULD still falls within the whelms of a 
"optional" concept albeit less optional than a MAY, and I wouldn't be 
surprise when software exist that do not support SHOULD recommendations 
for whatever reason that may be.

Thanks for your comments.

-- 
Sincerely

Hector Santos, CTO

---

From: Pete Resnick <[email-masked]>
Date: Mon, 4 Feb 2008 22:57:10 -0600

Coming out of my lurking in the background...

So, as some folks are fond of saying, "I have no dog in this hunt." 
I'm really not entirely sure what bearing the existence or 
non-existence of the "Sender:" field has on the DKIM/SSP discussion 
(though I've been reading and trying to figure this out). But for 
purposes of clarifying:

In IETF protocols, requirements are not binary values like REQUIRED 
and NOT-REQUIRED. They are tri-valued: MUST, SHOULD, MAY (or, as 2119 
also calls the values: REQUIRED, RECOMMENDED, and OPTIONAL). And they 
are *not* about conformance; they are about interoperability and 
reflect actual practice, not some imagined desired goal. In the case 
of 2822, the DRUMS WG was specifically evaluating e-mail practice and 
what was required of folks implementing those protocols.

>Under ANY condition, for it to be REQUIRED, it must say MUST.  It 
>does not say MUST.

Those statements are all correct.

>It says SHOULD, That is not a MUST, and even though 2119 says you 
>should have a good reason to not follow the recommendation...

That's not all it says. In particular, something that one SHOULD do 
(in requirements-speak) may be "required for interoperation" and not 
doing so may be "behavior which has potential for causing harm", but 
it is recognized that "there may exist valid reasons in particular 
circumstances" not to do it. In particular, IETF protocols are 
written to distinguish things which one MUST and SHOULD do from 
things that are truly OPTIONAL. That is the conclusion regarding the 
"Sender:" field (and certain circumstances for its use) that those of 
us who worked on 2822 came to.

>it implication is such that it is and was always OPTIONAL

Nope. No implication. We were perfectly explicit when we wrote 2822, 
and we believed at the time (and I certain still believe) that this 
was the consensus of the community.

>To not be OPTIONAL, is must be a MUST and that is not what we have here.

That's simply false. This is why we have RFC 2119: We actually meant 
what is said in there, and that's why we used those words.

>You can throw all the docs you want at me, it isn't going to change 
>the reality.

And that is not what we judged the reality to be in 2001, and it is 
apparently not what the community believes the reality to be now. You 
may disagree with that, but that would put you in the "rough" part of 
the "consensus".

>What you are implying, and this is where docs people might ought to 
>try not always be wearing designer hats as well, that SMTP receivers 
>has this a mandate to alter the message for the purpose of adding a 
>submission and automatically add the missing sender field if the 
>x821 return path does not equal x822 From header.

That is *not* what this document says at all. The "Sender:" field is 
an MUA field, not an MTA field, and SMTP receivers are not supposed 
to be inserting their data into fields (other than "Received:" and 
"Return-Path:"). Now, a Submission server, with other knowledge, may 
modify those fields, but only because it straddles MUA and MTA. But 
even so, it's supposed to insert the "agent responsible for the 
actual transmission of the message", not the return path, and only if 
it differs from the mailbox in the "From:" field.

Lots of (maybe most?) MUAs do the right thing here: If you send a 
message on behalf of someone else where the someone else is the 
author and you use their address in the "From:" field, your address 
goes into the "Sender:" field.

>Look, Sender, if used, is typically added when its not the real 
>author sending the original message.

Let's be careful with our words here: There is *always* a "sender" of 
a message. ALWAYS. There is sometimes (i.e., not always) a "Sender:" 
field in a message. When a message does not have a "Sender:" field, 
the sender of the message is the thing in the "From:" field (i.e., 
the author).

So, if the DKIM/SSP world want to use the *value* of the sender of 
the message for some purpose, that's always there. Sometimes it 
appears in the "From:" field (if there is no "Sender:" field) and 
sometimes it appears in the "Sender:" field. If DKIM/SSP wants to 
require (or REQUIRE) the "Sender:" field, that would be a bad thing. 
But I haven't seen anything to that effect in what I've been reading.

I'll go back to lurking now, and the rest of you can go back to your 
regularly scheduled love-fest.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 4 Feb 2008 17:00:55 -0800

>> DKIM-Signature:  d=expample.com i=[email-masked] (g=*)

Sorry, this example needs correction. Should be-

From: [email-masked]
Sender: [email-masked]
DKIM-Signature: d=example.com i=[email-masked] (g=*)

> But this isn't a 3rd party signature. The signing domain is the same  
> as  the from domain, or did you try to throw in a "near-phish"  
> domain, or is that a typo?  "exPample.com"  ???

Agreed.  This is not _really_ a third-party signature.  The definition  
for "Author Signature" used in SSP might make a signature with the  
_same_ domain non-compliant (a third-party) when evaluating an SSP  
"all" or "discardable" assertions.

See SSP-02 section 2.8.  Author Signature

  An "Author Signature" is any Valid Signature where the *identity* of
  the user or agent on behalf of which the message is signed (listed in
  the "i=" tag or its default value from the "d=" tag) *matches* an
  *Author Address* in the message.

Compare this with ASP-00 section 2.8.  Author Signature

  An "Author Signature" is any Valid Signature where the signing  
*domain*
  (listed in the "i=" tag if present, otherwise its default value,
  consisting of the value of the "d=" tag) *matches* the *domain* of an
  Author Address.

You seem to have internalized the ASP "Author Signature" definition.   
This definition causes less astonishment.

>> This message is clearly signed by example.com per RFC 4871, but  
>> where a SSP policy assertion of either "all" or "discardable" might  
>> cause this ABSOLUTELY valid message to be dropped as being non- 
>> compliant.
>

The comparison with local-parts may cause messages signed per RFC 4871  
to be considered non-compliant.

> Which specification are you talking about?   Is this really a valid  

SSP-02.  The definition within ASP appears correct, whereas the Author  
Signature definition within SSP is not.

> But if you really meant the above being a near-phish, exPample.com,  
> then this goes to illustrate how ASP will harm the primary domain.

Sorry for the typo.  This issue was not about look-alike domains.

> Plus, you didn't indicate if the Sender= was bound to the signature  

The From email-address being protected by the policy scheme MUST BE  
included within the signature's hash per RFC 4871.  Although the  
display name of the Sender header should not be highlighted as being  
confirmed by the signature when the header is not included within the  
signature's hash, neither DKIM nor SSP is about how information is to  
be shown to the recipient.  DKIM is about determining the source  
domain and SSP should be about whether the message appears to be  
compliant with the domain's asserted actions.

>>>> SSP stipulations changes RFC 4871 signature handling to not use  
>>>> the i= parameter when there might be such a conflict with the  
>>>> From header.
>>>
>>> Per 4871, if i= is used, which is OPTIONAL, the domains of d= and  
>>> i= must be the same
>>  not meeting the requirements for "Author Signature" in SSP,  
>> however it does meet these requirements in ASP.
>
> Even then, all I see above is either a typo or an intentional 3PS  
> based on a near-phish.  If that is the case, then you just showed  
> quite clearly, how the author domain EXAMPLE.COM has just been  
> exploited with less means of protecting it.

Sorry about the additional "." and  "p".

> Huh? the above logic has been the basis for 3rd vs 1rd party  
> signature (respectively) since the beginning.

True, but this is not how SSP has defined a "first party" (author)  
signature.

> You do?  How can you support ASP when it doesn't help protect  
> domains from 3rd party abuse?

The example given had typos and I am truly sorry for that.  When the  
 From and Signature domains are the _same_, the signing domain still  
remains in control of their own protection.

>>> to assist it in keeping with its new asserted DKIM-BASE "social  
>>> and ethical" responsibility.   SSP is basically a fraud detection  
>>> or protocol consistency checker.  If everything is koshser, I  
>>> believe no one has ever said SSP allows a message to pass or skip  
>>> any other testing.
>> compliance with Sender assertions pertaining to what the  
>> transmitting indicates as their handling practices.  This view  
>> makes less sense when the assertion is "discardable".
>
> Are you suggesting even DISCARDABLE is no good?   You want to  
> further water down SSP or whatever you wish to call it ASP?

SSP assertions should not be viewed as "actions a verifier may take".   
The term "strict" and its definition was in keeping with a philosophy  
that assertions reflect the "actions of the signing domain".

Even when there is a desire to absolve a receiving system for  
discarding messages, discarding messages is not in keeping with SMTP.   
Discarding what appears to be possible fraud is counter intuitive when  
spoofing the domain potentially represents a criminal act.  At least a  
DSN per RFC 3464 might alert the domain of possible fraud or the  
failure of signature related infrastructure.  "Please sweep failures  
under the rug" is not in keeping with a desire to control abuse or to  
preserve delivery's integrity.  There is no need to encourage or  
absolve the use of an easy solution.  IMHO, "discardable" is  
shameful.  Why not also have "report all failures using RFC 3464" as  
an assertion as well?  "Strict" was a far better choice that concluded  
an extensive debate.

>> The concern is when the message is signed by the author's domain,  
>> but on-behalf-of someone else with the author's domain.  When this  
>> domain applies their signature, their signing policy MUST evaluate  
>> whether "[email-masked]" is able to include "[email-masked] 
>> " with the From header.  It would be ridiculous to expect to have  
>> this policy applied by a possible verifier.  As you said, DKIM is  
>> about establishing responsibility _at_ the domain.  When the domain  
>> is held accountable, as designed in RFC 4871, the local-part  
>> introducing the message does not matter.  The local-part might be  
>> highlighted by the MUA to indicate who introduced the message, but  
>> as far as signing policy should be concerned, local-part is  
>> immaterial.
>

Yes I think we are in agreement.

> I'm going to take your word on this. It sound's reasonable, but I  
> think overall, this is now really a moot point because ASP has made  
> DKIM-BASE a less attractive idea to pursue.   Too much fraud is  
> possible now.

What aspect of the ASP definition of the Author Signature permits fraud?

The example was in error and was not indicative of the definition.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 04 Feb 2008 23:24:58 -0500

Doug,

ASP cracks opens the door to DKIM abuse and your unintentional "typos" 
example proves it.   Do you think software is going to know the 
difference now if your 3rd party signature was a typo, syntactically 
valid but unexpected or otherwise?

ASP has removed a 100% ZERO FALSE POSITIVE PROTECTION mechanism and it 
will not help DKIM signers if they can buy into this ASP in its flawed 
state.

-- 
Sincerely

Hector Santos, CTO

Douglas Otis wrote:
>> as  the from domain, or did you try to throw in a "near-phish" domain, 
>> or is that a typo?  "exPample.com"  ???
> 
> _same_ domain non-compliant (a third-party) when evaluating an SSP "all" 
> or "discardable" assertions.
> 
>  An "Author Signature" is any Valid Signature where the signing *domain*
> included within the signature's hash per RFC 4871.  Although the display 
> name of the Sender header should not be highlighted as being confirmed 
> by the signature when the header is not included within the signature's 
> hash, neither DKIM nor SSP is about how information is to be shown to 
> the recipient.  DKIM is about determining the source domain and SSP 
> should be about whether the message appears to be compliant with the 
> domain's asserted actions.
> 
>> from 3rd party abuse?
> Even when there is a desire to absolve a receiving system for discarding 
> messages, discarding messages is not in keeping with SMTP.  Discarding 
> what appears to be possible fraud is counter intuitive when spoofing the 
> domain potentially represents a criminal act.  At least a DSN per RFC 
> 3464 might alert the domain of possible fraud or the failure of 
> signature related infrastructure.  "Please sweep failures under the rug" 
> is not in keeping with a desire to control abuse or to preserve 
> delivery's integrity.  There is no need to encourage or absolve the use 
> of an easy solution.  IMHO, "discardable" is shameful.  Why not also 
> have "report all failures using RFC 3464" as an assertion as well?  
> "Strict" was a far better choice that concluded an extensive debate.
> 
>>> "[email-masked]" is able to include "[email-masked]" 
>>> with the From header.  It would be ridiculous to expect to have this 
>>> policy applied by a possible verifier.  As you said, DKIM is about 
>>> establishing responsibility _at_ the domain.  When the domain is held 
>>> accountable, as designed in RFC 4871, the local-part introducing the 
>>> message does not matter.  The local-part might be highlighted by the 
>>> MUA to indicate who introduced the message, but as far as signing 
>>> policy should be concerned, local-part is immaterial.
>>

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 05 Feb 2008 11:51:48 -0000

>   consisting of the value of the "d=" tag) *matches* the *domain* of an

Yes, Doug is right, but he doesn't half make it hard for the rest of us to  
figure out what he is getting at.

So, if i= is present, its domain must be the (a sub-)domain of the d=.
If it has a local-part, that must be a subset of the g=, but it is  
otherwise merely informative and plays no part in validating a signature.  
If you really want to ensure that the Author has that local-part, then you  
need to write something in your g= tag.

So on that basis the SSP-02 definition above is inconsistent with RFC  
4871, whereas the ASP-00 definition is spot-on.

That makes the signature in the example above OK under all SSP rules,  
because the domain in the i= matches the domain in the From.

A more interesting question is the case:

  From: [email-masked]
  Sender: [email-masked]
  DKIM-Signature: d=example.com i=[email-masked] g=other-person
                  h=...,sender,...

Is that a 1st party signature? Surely 'yes' because no third party has got  
in on the act yet.

Does it satisfy SSP=strict/all?

Not as SSP is currently written, but IMHO it should (and even so in the  
case where the From was [email-masked]). It is just a matter  
of how you define "Author", or of writing "Author or Sender address",  
subject to some restrictions, in the definitions above.

-- 
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: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 5 Feb 2008 14:24:26 -0500

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Hector Santos
>Sent: Monday, February 04, 2008 11:25 PM
>To: Douglas Otis
>Cc: DKIM List
>Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt ASP/SSP section 2.8
>
>Doug,
>
>difference now if your 3rd party signature was a typo, 
>syntactically valid but unexpected or otherwise?
>
>ASP has removed a 100% ZERO FALSE POSITIVE PROTECTION 
>mechanism and it will not help DKIM signers if they can buy 
>into this ASP in its flawed state.
>
>--

Hector,

Could you elaborate on your comment re false positive protection?

Thanks.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 5 Feb 2008 11:11:25 -0800

On Feb 4, 2008, at 8:24 PM, Hector Santos wrote:

> ASP cracks opens the door to DKIM abuse and your unintentional  
> "typos" example proves it.

Typos prove one must not be in a hurry.

Per the ASP definition, the domain of the DKIM signature MUST BE  
authoritative for the domain within the From header email-address.   
The ASP definition even takes this a step further and says i= and  
email-address domains must match, which IMHO is being too strict.

The definition in the ASP draft allows the state of the signature to  
just include:
a) valid/invalid

The ASP definition could be expanded by using the domain within the  
signature's d= parameter, rather than the domain within the i=  
parameter.  When the i= domain is a sub-domain of a valid signature's  
d= domain, the key can not have a sub-domain restriction.  Therefore,  
it is safe to use the d= parameter of valid signatures instead and  
require the From domains in question to be at (match) or below the  
signature's d= domain.

The Author Signature Definition should change to:

An "Author Signature" is any Valid Signature where the signing domain
(listed in the "d=" tag) matches or is above the domain of an
Author Address.

> Do you think software is going to know the difference now if your  
> 3rd party signature was a typo, syntactically valid but unexpected  
> or otherwise?

If software were unable to extract the domain of the signature and  
compare this against a domain found in the From header, there would be  
no point in referencing SSP records.  So yes, software must be able to  
determine a difference between a third-party domain and that of the  
 From domain.  A typo within the signature would not provide a valid  
signature.  A typo in the From domain would exclude the signature as  
being authoritative, where the message where domains do not compare  
would have a third-party signature.  The policy obtained would be that  
of the From domain.

Reread the definition of the ASP Author Signature definition again.   
The term Author Signature is perhaps poorly considered.  To correlate  
with your perspective, "Author Signature" could be called "First Party  
Signature".  A "First Party Domain" would be the domain of an email- 
address within the From header.  A message would be considered "all"  
or "discardable" compliant when all First Party Domains are signed by  
a First Party Signature.  The only ignored element for compliance  
assessment would be that of the signature's i= parameter local-part.

> ASP has removed a 100% ZERO FALSE POSITIVE PROTECTION mechanism and  
> it will not help DKIM signers if they can buy into this ASP in its  
> flawed state.

I do not understand your statement.  How is the ASP definition  
flawed?  The ASP definition appears to be overly restrictive,  
especially for domains utilizing sub-domains to partition users.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Feb 2008 01:46:58 -0500

MH Michael Hammer (5304) wrote:

 >  Hector wrote:

Hi Michael,

Since SSP-00, SSP-01, including DSAP-00, these DKIM Policy drafts all 
provides three basic policies which provide a restrictive declaration by 
the domain of what it expected or doesn't expected in mail transaction 
purported to be from them (their domain  is used in the From: header).

In SSP-00, these were:

    o=-  STRONG  (signature required, 1st or 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)

These are 100% zero false positive because that is what the domain 
declared and any rejection based on these are 100% perfectly acceptable. 
  They do not care if there was an external employee using its domain on 
  hotels, eCard services, Bulk Mailers services, etc.   For them, 
Roaming Users is not an issue and they expect receivers to honor the 
stated policies by performing policy inconsistency checks and rejecting 
the messages conflicting with these policies. No questions asked.

In DSAP, it followed these same concepts.

In SSP-01, these policies were now defined in difference ways:

The SSP-00 NEVER policy was now done in SSP-01 by having a DKIM=STRICT 
plus a NULL DKIM domain public key.

The SSP-00 STRONG policy was now done in SSP-01 with a DKIM=ALL (Anyone 
can SIGN, but it MUST be signed).

The SSP-00 EXCLUSIVE was now DKIM=STRICT in SSP-01.

Both SSP-00 and SSP-01, offered DKIM signer who wished to operate in 
this mode, powerful 100% zero false positive protocol inconsistency and 
fraud protection.

With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection against 
3rd party fraud.

The NEVER concept can still be covered using DKIM=DISCARDABLE and a NULL 
DKIM public key.

The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.

But anything related to 3rd party signers was completely eliminated in 
SSP-02/ASP.  Even though SSP-02 DKIM=ALL is a "always sign for 1st party 
authors" concept, it is basically a DKIM=DISCARDABLE without semantics 
on REJECTION.  DKIM=DISCARDABLE failures is explicit with the REJECTION 
control.  DKIM=ALL failures are not.

In short, DKIM=ALL is the SPF version of SOFTFAIL where you can record 
it, but you do not take any REJECTION action on it.  Just like SPF.

I find this to be a hypocrisy that ASP is repeating the same design and 
same negative repercussions in ASP, but in my view in a much more worst 
way than SPF.

It will be a worst form of the same SOFTFAIL problem because with SPF it 
was a issue of a IP mismatch.   It was difficult to make any assessment 
on the sender IP not just because of some malicious usage, but because 
there were legitimate mail routing issues with SPF that not always in 
the form of a single hop MTA to MDA.

But that is not the case with DKIM.  Here we have 100% detectable fraud 
capabilities that is unrelated to legitimate multiple hope IP issues and 
ASP is mandating a flawed inherent policy that RECEIVERS should ignore 
certain kinds of obvious fraudulent messages.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Feb 2008 14:35:24 -0800

On Feb 5, 2008, at 10:46 PM, Hector Santos wrote:
> this mode, powerful 100% zero false positive protocol inconsistency  
> and fraud protection.
>
> With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection  
> against 3rd party fraud.

An "all" assertion never implied all unsigned messages should be  
rejected.  This assertion also never ensured receivers that third- 
party handling was avoided.  Any damaged signature must be handled as  
if not signed.  Otherwise, spoofed signatures permit a means to thwart  
policies that give credit for invalid signatures.

> The NEVER concept can still be covered using DKIM=DISCARDABLE and a  
> NULL DKIM public key.

Disagree.  This is attempting once again at establishing that no email  
is sent by the domain.  The rub being that this assertion does not  
require DKIM to be involved.  If done, this assertion should be made  
directly rather than requiring still more DNS transactions.

> The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.

Disagree.  Domains wishing to protect important transactional or  
commerce related messages are unlikely to consider their messages  
"discardable".  Rather than assuring receivers that their domain  
avoids services that might damage a signature, "discardable" permits  
discarding messages whenever a signature is not valid.

When was changing the assertion from "strict" discussed?

When would discarding a message be a recommended action?

Why is SSP attempting to define receiver actions?

> But anything related to 3rd party signers was completely eliminated  
> in SSP-02/ASP.  Even though SSP-02 DKIM=ALL is a "always sign for  
> 1st party authors" concept, it is basically a DKIM=DISCARDABLE  
> without semantics on REJECTION.  DKIM=DISCARDABLE failures is  
> explicit with the REJECTION control.  DKIM=ALL failures are not.

The assertion of "all" will likely result in few sources being  
considered acceptable sources for this domain's email.  When lacking a  
valid signature, it would be clear that some other domain is involved.

> In short, DKIM=ALL is the SPF version of SOFTFAIL where you can  
> record it, but you do not take any REJECTION action on it.  Just  
> like SPF.

Disagree.  SPF's SOFTFAIL essentially admits registration failures are  
beyond the control of the transmitting domain.  DKIM's ALL admits  
other domains might handle messages that should otherwise be signed.   
"Strict" suggested that the domain attempted to preclude any  
destructive handling, but this assertion has been removed.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Wed, 06 Feb 2008 19:11:24 -0500

> rejected.  

Not in SSP-02, but it was implied in all other previous drafts.

> This assertion also never ensured receivers that third-party 
> handling was avoided.  

Sure it did, in SSP-00, SSP-01, it was very clear.  We had policies that 
either expected it or did not expect it.

This was removed in SSP-02, *intentionally neglectful* of the security 
issues this removal creates.

> Any damaged signature must be handled as if not 
> signed.  

SSP-02 removes all semantics for REJECTION in policies other than 
DKIM=DISCARDABLE where there is a explicit statement for REJECTION.  The 
implication is sure the DISCARDABLE has clear instructions for REJECTION 
and all others do not.

When signature fails and the only different is the policy and one 
implies to receivers "These Failure is rejectable" for DKIM=DISCARDABLE 
and "The same failures are not rejectable" in DKIM=ALL, not only does 
this lack common sense, it is foolish to believe that this inconsistency 
will be tolerated by the general case receivers, thus making it much 
more difficult to consider DKIM in general.

I am not guessing here, I have a hard time accepting the idea of adding 
DKIM to our package because of this.  Its going to make life more 
difficult, not less, for my customers,  I would be irresponsible to add 
something filled with flaws, false hope and high potential for more 
support issues than less.   ASP is not helping the ANTI-SPAM problem, it 
  is adding to it.

> Otherwise, spoofed signatures permit a means to thwart policies 
> that give credit for invalid signatures.

Exactly, that is what SSP-02 now provides!

> is sent by the domain.  

No, it is establishing the reality in the world where real companies and 
people who have domains which are never meant and used for email but it 
is forged, exploited and abused by bad guys, bulk mailers, spammers 
anyway.  Is this not a reality?

> The rub being that this assertion does not 
> require DKIM to be involved.  

If this was a Return-Path domain for which there is an STANDARD 
ASSERTION of MX involvement, I can see your point. But we are not 
talking about the Return Paths, but From: header domains and in this 
case, it is a DKIM involvement to consider the From: domain for MX 
correctness.

 > If done, this assertion should be made

Two things:

First, I believe you were one of the principles in getting the 
questionable MX lookup within the SSP-01/SSP-02 steps.  It isn't even 
optional (SHOULD or MAY), but a MUST requirement.   You shouldn't be 
surprise if RECEIVER ignore this MUST for the same conflictive reason 
you stated above that it is could be done as a separate protocol or 
procedure outside of DKIM/SSP.

Second, how can you disagree with what is obviously possible where you 
have no control or ignoring the fact you accessed a PUBLIC key?

If th public key is NULL, the DKIM signature is automatically invalid 
and if an ASP DISCARDABLE policy is used, it means REJECTION.

> Disagree.  

But it is written in stone:

    discardable

    All mail from the domain is signed with an Author
    Signature.  Furthermore, if a message arrives without a valid
    Author Signature due to modification in transit, submission via
    a path without access to a signing key, or other reason, the
    domain encourages the recipient(s) to discard it.

Does it not mean what it says?  I never was for explicit statements like 
this and I don't think most WG participants ever was.  All previous 
documents provided guidelines as either being "Suspicious" or 
"non-compliant" which for the most part is essentially code for 
"rejection"  but IMV, its not normally good practice to be so direct 
with REJECTION statements in email.

> Domains wishing to protect important transactional or 
> "discardable".  

Exactly, which in the end of the day, we all know that ASP is just a 
white wash attempt to kill the entire idea of SSP.

> When was changing the assertion from "strict" discussed?

Other than the ASP group attempt to get rid of it, it never happen here 
openly in the WG.

> When would discarding a message be a recommended action?

When it is consistent with what was declared by the domain as unexpected.

> Why is SSP attempting to define receiver actions?

It not about telling the receiver what to do but to HELP the receiver 
determine with zero false positive factors of what is expected and not 
expected - its about protocol consistency.

If the DOMAIN says it doesn't expect 3rd party signatures, it would be 
incredibly dumb for a Receiver to ignore those factors, not just for the 
good of the domain which has implicitly stated it would not take 
responsibility for a message it did not write or sign,  but for the 
receiver and its users as well to not use this unique detections to get 
rid of something that is clearly fraud or unauthorized or unexpected by 
the domain.

> Disagree.  

Doug, you were militantly vocal against SPF for the same SOFTFAIL 
reasons.  As sure as the New York Giants are Super Bowl Champions, then 
you will be having belated recognized issues with ASP::DKIM=ALL failures 
as well.  :-)

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Wed, 6 Feb 2008 22:03:44 -0800

> Not in SSP-02, but it was implied in all other previous drafts.

The SSP-01 draft stated that at least an acceptable third-party  
signature is not present before a message is to be considered  
"suspicious".  Even so, SSP should not dictate to verifiers what they  
should think.  Removing the "MUST BE considered Suspicious" is a  
welcome change.  Too bad Jim, Eric, and Mark decided SSP should then  
dictate permitted actions instead.  Especially actions that seriously  
erode the integrity of email delivery. : (

> Sure it did, in SSP-00, SSP-01, it was very clear.  We had policies  
> that either expected it or did not expect it.

No. This assurance was limited to that of the now missing "strict"  
assertion.

SSP-01 strict:
All mail from the domain is signed; messages lacking signed a valid  
Originator (Author) Signature MUST be considered Suspicious.  The  
domain does not expect to send messages through agents that  may  
modify and re-sign messages.

> This was removed in SSP-02, *intentionally neglectful* of the  
> security issues this removal creates.

DKIM signatures might be damaged by various gateways.  Enterprise mail  
gateways may perform Content-Type header fix-ups which damage a  
signature, for example.  Information provided by SSP must be balanced  
against factors that are beyond the control of the signing domain.   
Nothing safely allows messages to be discarded.  The information  
needed to assess compliance does not result from a "discardable"  
assertion.  It is impossible to assess compliance against a  
"discardable" assertion, as no one knows what signer behaviour this  
assertion defines.

Suggested assertion definition-

strict:
  All mail from the domain is signed where agents that may damage  
signatures are avoided.

Whether the message is rejected, a DSN per RFC3464 is generated, etc.,  
there is no reason for SSP to define subsequent actions.  Least of  
all, actions where messages are silently discarded as a principal  
result.

>> Any damaged signature must be handled as if not signed.
>
> DKIM=DISCARDABLE where there is a explicit statement for REJECTION.   
> The implication is sure the DISCARDABLE has clear instructions for  
> REJECTION and all others do not.

Disagree. Suspicious never included clear instructions for rejection.

> implies to receivers "These Failure is rejectable" for  
> DKIM=DISCARDABLE and "The same failures are not rejectable" in  
> DKIM=ALL, not only does this lack common sense, it is foolish to  
> believe that this inconsistency will be tolerated by the general  
> case receivers, thus making it much more difficult to consider DKIM  
> in general.

It would be futile for an SSP draft to define all factors a verifier  
might use in deciding whether to reject or discard a message.  The SSP  
draft should be limited to clarifying the actions taken by the sending  
domain.  Those running the DKIM/SSP verification process will be  
adapting to changing conditions.  Verifiers actions can not be  
enumerated by a signer's policy assertions.

> I am not guessing here, I have a hard time accepting the idea of  
> adding DKIM to our package because of this.  Its going to make life  
> more difficult, not less, for my customers,  I would be  
> irresponsible to add something filled with flaws, false hope and  
> high potential for more support issues than less.   ASP is not  
> helping the ANTI-SPAM problem, it is adding to it.

DKIM is not an anti-spam technology.  Spammers can sign.  DKIM is an  
optional extension that is likely used by domains being spoofed or  
troubled by abuse.  To be successful, DKIM must not reduce the  
integrity of their email delivery of legitimate messages.

> Exactly, that is what SSP-02 now provides!

Disagree. DKIM/SSP offers a means accurately categorize messages into:

a) valid first-party signatures

b) without valid first-party signature from a domain that signs all

c) without valid first-party signature from a domain that guards their  
signature

d) valid third-party signature

e) valid third-party signature from a domain that signs all

f) valid third-party signature from a domain that guards their signature

SSP does nothing to promote a category of messages with invalid  
signatures.  The verifier is free to decide how they handle each  
category of messages based upon all factors at their disposal.  Surely  
you are not going to claim that DKIM offers value only for messages  
within category "a"?

>>> The NEVER concept can still be covered using DKIM=DISCARDABLE and  
>>> a NULL DKIM public key.
>>
> No, it is establishing the reality in the world where real companies  
> and people who have domains which are never meant and used for email  
> but it is forged, exploited and abused by bad guys, bulk mailers,  
> spammers anyway.  Is this not a reality?

This was to be handled by category "c" where SSP should mandate use of  
MX records when the domain is being used to send DKIM signed  
messages.  Not having an MX record can then replace your concept of a  
NULL public key.  After all, the location of a public key is not  
defined.

>> The rub being that this assertion does not require DKIM to be  
>> involved.
>
>> If done, this assertion should be made directly rather than  
>> requiring still more DNS transactions.
>
> Two things:
>
> questionable MX lookup within the SSP-01/SSP-02 steps.  It isn't  
> even optional (SHOULD or MAY), but a MUST requirement.

An MX record is used to determine a valid domain during SSP record  
discovery.  SSP still needs to make publishing an MX record mandatory  
for domains signing DKIM and publishing SSP records.  In this way, the  
lack of an MX record clearly delineates whether the domain is used to  
send email when SSP policy is published.

> You shouldn't be surprise if RECEIVER ignore this MUST for the same  
> conflictive reason you stated above that it is could be done as a  
> separate protocol or procedure outside of DKIM/SSP.

There is no valid reason that SSP not mandate the publishing of MX  
records at the domain publishing SSP policy.  If so, the ability to  
detect a domain that does not send email becomes a product of the SSP  
discovery process without costing any additional transactions.  It  
seems wasteful, if negligent, to not add this minor requirement.

> Second, how can you disagree with what is obviously possible where  
> you have no control or ignoring the fact you accessed a PUBLIC key?

Why a key is not found can not be assured.  The location should change  
every time the key is rolled.  Microsoft DNS may not update a CNAME  
references when being published subsequently by a different server, as  
example.  There are many reasons for an expectation of a public key to  
be unreliable.

> If th public key is NULL, the DKIM signature is automatically  
> invalid and if an ASP DISCARDABLE policy is used, it means REJECTION.

Does "discardable" mean rejection?

> Does it not mean what it says?

strict:
  All mail from the domain is signed where agents that may damage the  
signatures are avoided.

Would a domain that intended to publish strict also wish to encourage  
recipients to discard unsigned (or invalid) messages?  Most high value  
targets want to know about attempts to defraud their customers, and  
want these messages to generate a DSN at least.  Perhaps SSP should  
also have a "rejectable" assertion as well?  After all, this  
information could then help authorities compile evidence of a crime.   
Any suggestion to discard these messages would be a major blunder  
since DKIM is not an anti-spam technology.  DKIM is about ensuring the  
message source and improving delivery integrity.

> I never was for explicit statements like this and I don't think most  
> WG participants ever was.  All previous documents provided  
> guidelines as either being "Suspicious" or "non-compliant" which for  
> the most part is essentially code for "rejection"  but IMV, its not  
> normally good practice to be so direct with REJECTION statements in  
> email.

The actions taken can be defined in BCPs once DKIM and SSP have been  
around for awhile.  The motivation behind the "discardable" assertion  
is to hide problems.  This assertion will slow or halt progress in  
overcoming unexpected problems.

>> Domains wishing to protect important transactional or commerce  
>> related messages are unlikely to consider their messages  
>> "discardable".
>

This seems rather cynical, but you could be right.

> Other than the ASP group attempt to get rid of it, it never happen  
> here openly in the WG.
>

Why should unexpected situations be ignored and discarded?

> It not about telling the receiver what to do but to HELP the  
> receiver determine with zero false positive factors of what is  
> expected and not expected - its about protocol consistency.

Although a domain should be able to use SSP to indicate their  
behaviour, SSP should not be used to dictate verifier actions.  The  
verifier remains the arbiter of their actions based upon all related  
factors.  SSP assertions should be defined in a manner that might  
allow the verifier to determine whether the message received is  
consistent with the domain's asserted behaviour.  With that in mind,  
"discardable" means the signing domain does what exactly?

> If the DOMAIN says it doesn't expect 3rd party signatures, it would  
> be incredibly dumb for a Receiver to ignore those factors, not just  
> for the good of the domain which has implicitly stated it would not  
> take responsibility for a message it did not write or sign,  but for  
> the receiver and its users as well to not use this unique detections  
> to get rid of something that is clearly fraud or unauthorized or  
> unexpected by the domain.

Agreed.  That is what "strict" was about.  However, there may be other  
factors a verifier might apply in deciding the disposition of the  
message.  There is no reason SSP should enumerate actions that might  
involve extraneous factors.  That should wait for a BCP draft.

> reasons.  As sure as the New York Giants are Super Bowl Champions,  
> then you will be having belated recognized issues with ASP::DKIM=ALL  
> failures as well.  :-)

SOFTFAIL is never having to admit the protocol itself is broken. : )

-Doug

---

From: Graham Murray <[email-masked]>
Date: Thu, 07 Feb 2008 07:01:12 +0000

Douglas Otis <[email-masked]> writes:

> signature, for example.

In which case they SHOULD be validating the DKIM signature before
performing the fix-ups. They are the (incoming) border, so are the best
place to perform DKIM, SPF etc checks.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 07 Feb 2008 03:34:24 -0500

Douglas Otis wrote:

> DKIM is not an anti-spam technology.  

Yeah, right.  <wink> <wink>

Doug, how are you (speaking in general) going to stop vendors from 
putting it in Anti-Spam or Security sub-sections of their products?  Or 
stop them from advertising or marketing it as new "anti-spam/security 
features" Or stop the rags from speaking of it as the new "great" 
ANTI-SPAM solution?

You won't, you can't.  In fact, just read the abstract in the draft 
Deployment Guide by Dave Crocker and Tony Hansen:

      Such protection of email identity may assist in the global
      control of "spam" and "phishing".

> c) without valid first-party signature from a domain that guards 
 >    their signature

and yet fails to detect fraud and the bad guys doesn't have to do a thing.

>> If the public key is NULL, the DKIM signature is automatically 

Is this a rhetorical philosophical question, right?

 > behaviour, SSP should not be used to dictate verifier actions.

So why does it promote the idea of MX checking with a MUST action?

I fail to see why someone would invest in this where there is no payoff 
- a payoff of eliminating a high volume of BAD mail and at the same time 
enhance the quality of what it receives and passes on to users with a 
higher degree of confidence.  I think there might a flawed presumption 
that receivers are going to do things where there is little benefit in 
return.

>> incredibly dumb for a Receiver to ignore those factors, not just for 
>> the good of the domain which has implicitly stated it would not take 
>> receiver and its users as well to not use this unique detections to 
>> get rid of something that is clearly fraud or unauthorized or 

How can you agree here but disagree with other statements that basically 
said the same thing? <g>

I am not talking about nothing more but the three obvious frauds:

      No Mail Expected
      Signature Expected by anyone
      Signature Expected by the Primary/Author Domain only

IMV, these are indisputable 100% zero false positive first level 
protocol inconsistency detectable checks and will offer a high benefit 
to DKIM signers of all market types, specially exclusive high-value 
commodity domains that don't expect any other unauthorized usage of 
their domains and will offer an immediate impact of domain protection 
against fraudulent legacy transactions right out of the box.

Nothing more.  Really, nothing else. They are fundamental ideas that 
basically applies to a new level of transactions that is either true or 
false and nothing in between.

It is like the EHLO command. In normal Port 25 transactions, the BCP is 
that it is a weak consideration to apply strict compliance on this 
command.   But by raising the bar with the SUBMIT protocol (port 587), 
the SMTP receiver has new technical and legal rights that is not 
possible nor feasible with the public PORT 25 standard SMTP transaction. 
   So when a domain steps to this level, there is a new level of 
expected behavior with hardly any questions asked if the sender does it 
wrong!

DKIM + POLICY does the same by raising the bar at the x822 level with a 
new level of expectations that is either TRUE or NOT.  The above three 
policies provides this fundamental idea.  It moves the transactions 
beyond the 20+ year old relaxed legacy considerations that was the 
essence of the spam problem we have today.

> SOFTFAIL is never having to admit the protocol itself is broken. : )

Trademark it! <g>

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Feb 2008 09:56:38 -0800

On Feb 6, 2008, at 11:01 PM, Graham Murray wrote:

>> DKIM signatures might be damaged by various gateways.  Enterprise  
>> mail gateways may perform Content-Type header fix-ups which damage  
>> a signature, for example.
>
> performing the fix-ups. They are the (incoming) border, so are the  
> best place to perform DKIM, SPF etc checks.

Gateways might also forward the message or signatures might be checked  
at the MUA.  These situations make always following your good advice  
impossible.

When would it be safe to discard a message with an invalid DKIM  
signature?

What is accomplished by a "discardable" assertion?

Who is helped by the "discardable" assertion?

What does this assertion imply, that all messages with invalid  
signatures are to be ignored?

Is SSP getting ahead of itself and attempting to become a BCP?

Hector expressed a concern about lessening the value of SSP  
assertions.  In the case of "discardable", he would be absolutely  
right.  Perhaps the draft could call this the "sweep dirt under the  
rug" assertion.  It says nothing about what the signing domain does,  
only that they don't care about their domain's messages.  If someone  
did care, the assertion would be "reject and/or notify" with a  
reference to RFC 3464 at least.  The "discardable" assertion ensures  
most evidence of a crime or a problem becomes lost.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Feb 2008 10:37:42 -0800

On Feb 7, 2008, at 12:34 AM, Hector Santos wrote:

> putting it in Anti-Spam or Security sub-sections of their products?   
> Or stop them from advertising or marketing it as new "anti-spam/ 
> security features" Or stop the rags from speaking of it as the new  
> "great" ANTI-SPAM solution?
>

DKIM places bad guys into smaller categories.  This placement allows a  
greater amount of resources to be focused upon questionable categories  
such as "b", "c", "d", and "f", and of course "c" and "f" especially.   
The resources need to inspect for spam, phish, and malware is limited  
where triage is often required.  DKIM helps in better allocating  
limited resources.

> Is this a rhetorical philosophical question, right?

This is a serious question.

> So why does it promote the idea of MX checking with a MUST action?

This MX check is to determine the existence of a domain using a record  
likely to be present.  This just improves caching rates.

> I fail to see why someone would invest in this where there is no  
> payoff - a payoff of eliminating a high volume of BAD mail and at  
> the same time enhance the quality of what it receives and passes on  
> to users with a higher degree of confidence.  I think there might a  
> flawed presumption that receivers are going to do things where there  
> is little benefit in return.

DKIM reduces false positives for anti-phishing filtering.  DKIM also  
allows a high percentage of the messages to bypass more stringent  
checks when the source of the message is trusted and the message body  
is _fully_ signed.

>>> If the DOMAIN says it doesn't expect 3rd party signatures, it  
>>> would be incredibly dumb for a Receiver to ignore those factors,  
>>> not just for the good of the domain which has implicitly stated it  
>>> would not take responsibility for a message it did not write or  
>>> sign,  but for the receiver and its users as well to not use this  
>>> unique detections to get rid of something that is clearly fraud or  
>>> unauthorized or unexpected by the domain.
>> Agreed.  That is what "strict" was about.  However, there may be  
>> other factors a verifier might apply in deciding the disposition of  
>> the message.  There is no reason SSP should enumerate actions that  
>> might involve extraneous factors.  That should wait for a BCP draft.
>
> How can you agree here but disagree with other statements that  
> basically said the same thing? <g>

SSP must avoid becoming a BCP.  SSP should provide information about  
what the signing domain does.  FULL STOP.

> I am not talking about nothing more but the three obvious frauds:

You are right.  This is a common spoofing method.  The number of  
transactions used by DKIM validation in deflecting this abuse is  
critical.

Mandate the publishing of MX records whenever SSP records are  
published and when email is used by the domain.

By searching for SSP policy records, the question of email use can be  
determined without any additional transactions required.  It would be  
negligent to not mandate publishing MX records when also publishing  
SSP records.  Mandating the publishing of MX records in conjunction  
with SSP records reduces the number of DNS transactions expended on  
DKIM signature validation in the case of domain spoofing.  This  
mandate is easily justified as a resource safety issue at least.   
Publishing MX records for email is a good thing from both a policy and  
reliability perspective.

>     Signature Expected by anyone

Sorry, this is the default situation.   SSP is not needed here.  Be  
happy there is more verifiable information at least.

>     Signature Expected by the Primary/Author Domain only

This would be what the now missing "strict" assertion would have  
provided.  Unfortunately, this role can not be safely provided by  
"discardable" instead.

> protocol inconsistency detectable checks and will offer a high  
> benefit to DKIM signers of all market types, specially exclusive  
> high-value commodity domains that don't expect any other  
> unauthorized usage of their domains and will offer an immediate  
> impact of domain protection against fraudulent legacy transactions  
> right out of the box.

I agree with you on the last point.

-Doug

---

From: Eric Allman <[email-masked]>
Date: Thu, 07 Feb 2008 16:54:38 -0800

Hector,

Some of what you say is correct, but other descriptions of changes in 
SSP-02 don't match what we were trying to do.  It may well be that we 
didn't get the wording right yet.

First, a confession: most of the major changes in -02 are my doing. 
In particular, I think I pushed some things onto Jim that went 
further than he had wanted.  I think it's unfair to ask Jim to defend 
things that are basically my own responsibility.  I particularly 
apologize because I went in for major surgery just about the time 
this was hitting the fan, and I'm not yet fully functioning.

There's a certain philosophical difference between folks on this 
list.  Some want SSP to be extremely specific.  Others have gone on 
at length that the SSP spec has no right or authority to impose its 
own will on receivers.  I have sympathies for both positions, but I 
have to agree that there is no chance that we can successfully 
dictate how receivers operate.  I've said publicly many times that 
receivers will simply ignore the specs if it makes their lives better 
--- as we see today with intentional violations of RFC 2822.  SSP-02 
is an attempt to pare SSP down to appeal to the second set.  Yes, 
that weakens SSP, but that seems inevitable at this point.  In 
particular, I'm concerned that without giving receivers any guidance 
on how certain situations should be handled we'll end up in a fairly 
chaotic state.  However, I do agree that such guidance should 
probably go in a non-standards-track document.

A few specific points from your message:

--On February 6, 2008 1:46:58 AM -0500 Hector Santos 
<[email-masked]> wrote:
[...]

> With SSP-02/ASP, we lost the powerful SSP-01 DKIM=ALL protection

Speaking about SSP-02, I'm not sure how you see we've lost that 
"protection".  In -01, DKIM=ALL specifically allowed 3PS (Third-Party 
Signatures), so arguably it was weaker before.  Under SSP-02, a 
receiver could decide that 3PS should be treated more harshly (where 
"more harshly" doesn't necessarily mean "discard" --- it could just 
mean do content scanning on the message).

We did remove all discussion of 3PS.  The extended list discussion 
around them made it clear that we just don't have enough operational 
knowledge at this time to understand how they should work.  As such, 
we are now leaving all interpretation of 3rd party signatures up to 
the receiver.  That doesn't mean we've necessarily lost the ability 
to handle 3PS in a distinct way, but it will have to go into another 
document, at least for now.

> The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.

Except that DISCARDABLE doesn't prohibit 3PS.  It doesn't even say 
that messages without any signatures MUST or even SHOULD be 
discarded.  All it says is how the purported author domain views the 
messages that it sends out.  The furthest it goes is to say that the 
purported Author Domain "encourages the recipient(s) to discard it."

> explicit with the REJECTION control.  DKIM=ALL failures are not.

SSP-02 DKIM=ALL is not a "always sign for 1st party authors" concept. 
It doesn't even mention first parties, any more than it mentions 3rd 
parties.  All it says is "when the message left my control, I had 
signed it."  It says absolutely nothing about how the receiver should 
handle the message.

Similarly, and as noted above, DKIM=DISCARDABLE makes no normative 
assertions about what the receiver should do with the message.  It is 
impossible to say anything about when the receiver should reject 
messages without stepping into the forbidden territory of forcing a 
certain behavior on the receiver.

> record it, but you do not take any REJECTION action on it.  Just

There's nothing that prevents the recipient from rejecting messages 
under a DKIM=ALL condition.  In fact (if we did it as intended) there 
is no normative language anywhere in SSP-02 about how the receiver 
should process messages, be they signed, unsigned, or 3PS.

[...]

> But that is not the case with DKIM.  Here we have 100% detectable
> fraud capabilities that is unrelated to legitimate multiple hope IP
> issues and ASP is mandating a flawed inherent policy that RECEIVERS
> should ignore certain kinds of obvious fraudulent messages.

I'm not speaking to ASP, but SSP-02 makes (or is intended to make) NO 
normative restrictions on when the receiver should accept or reject 
any messages.

Another addition to SSP-02 was the concept of the Evaluator.  This 
was added purely to try to make it clear that SSP is merely one input 
into the decision process.  The Evaluator decides whether to reject a 
message, quarantine it, do additional content scanning on it, accept 
it without further scanning, redirect it to the FBI, post it on 
USENET, or anything else it cares to do.  My hope was that creating 
an explicit entity that makes the decision and clearly declare it out 
of scope we would clarify the limits of SSP.

It is my sincere hope that we will quickly gain enough experience 
that new documents can be produced providing further guidance (not 
requirements) for how the Evaluator should interpret SSP for broadest 
interoperability.

eric

---

From: Hector Santos <[email-masked]>
Date: Fri, 08 Feb 2008 06:28:05 -0500

Eric,

I sincerely appreciate your response and I do hope you are on your way 
to full recovery from your surgery. I had a hip replacement a few years 
back and it was the first time in a long time I was forced into a 
prolonged 'vacation' from work. :-)

It been a long road to where we are now.  A road where we tuned nearly 
every stone and discussed, and even worked out.  There were some 
remaining issues, but ones that I don't believe were not addressable.

The best I can describe the concerns is that we lost the potential for 
protocol consistency fraud.

For example, you pointed out SSP-01 DKIM=ALL offered 3rd party 
signatures and this could be deemed weaker,  I agree with that point.

However, I never indicated that a VALID 3rd party was ever classified as 
secured, but the lack of one is were the power of the concept is found.

The concept is really nothing new compare to other fraud detection 
concepts, things we all do in some form or another, include SMTP.

A simple example is a traffic cop requesting and analyzing your driver 
license.  The officer is first going to make sure that the attributes 
indicated on the card matches what he sees in person. If the driver is a 
20 year old woman and the license says 60 year old man, then this among 
other thing he can compare raises a red flag.

Anything that doesn't conform to expectations is always the first thing 
people notice.  As you know, this is a basic model in lots of things we do.

In our SMTP world, an excellent example is PORT 25 and its relaxed SMTP 
compliance versus PORT 587 and its strict SMTP compliance requirements. 
  i.e, EHLO checking under port 25 is recognized as low benefit for many 
historical reasons.  Under port 587, EHLO correctness is a requirement. 
  Same with other expects between the two protocols.   In short, PORT 
587 has less tolerance towards legacy operations - by design.  You must 
login.  You must have certain headers, etc.

Even in standard SMTP port 25 operations, we have basic x822 header 
requirements that some systems may be very strict about if they don't 
exist in the DATA block or post SMTP processing. But there is no BCP for 
this.

But with DKIM/SSP we can take control of this now and not allow it to 
become yet another "relaxed" protocol.

So again, the power here is in protocol inconsistency fraud detection. 
Once things are all "compliant" then the other things comes into play, 
because there is really not much more DKIM/SSP can do from this point.

This is where other layers may come into play, including reputation 
ideas and anything else.  I never argued against reputation. I just felt 
that one group was trying to based DKIM/SSP on it only and not even 
given the SSP concept a chance.  Unfortunately, the entire process has 
been commandeered in what appears to be a strategic goal to simply water 
it down to a level of total uselessness.

So to me the idea of an Evaluator would be first a fundamental protocol 
consistency Evaluator that would be part of the DKIM/SSP framework 
across all supportive/compliant systems.  It would be 100% independent 
from any subjective or heuristics or reputation analysis or any one 
group detecting their questionable inherent policies or implementations 
methods.

It really has nothing to do with good guys vs bad guys because as we 
know, bad guys too can exhibit compliant behavior.  But that is we want 
here - we want to make sure everyone (bad and good) are all playing in 
the same field of following the basic fundamental protocol.  Just like 
we expect with other any standard client/server communications protocol.

We want this model because if we can't expect compliance with the GOOD, 
than we can't expect it from the BAD, and if we allow DKIM/SSP to become 
this, we would be back to square one of relaxed SMTP legacy transactions 
where receivers lack enforcement and know hows but more importantly has 
no new information to rely on beyond the normal level of operations to 
consider.

DKIM/SSP changes all that, this is what lead me to technology and I of 
the belief this will be a major benefit for the SMTP industry.

But this is only going to work with a standard protocol "out of the box" 
all must follow if they wish to implement it.  I think this is all 
separate from having extra evaluators (i.e, reputations, spam-assassin, 
etc).   If we start with standard relaxed higher level system, then we 
will have lost an unique opportunity we haven't had in SMTP.

Thanks

-- 
Sincerely

Hector Santos, CTO

Eric Allman wrote:
> First, a confession: most of the major changes in -02 are my doing. In 
> particular, I think I pushed some things onto Jim that went further than 
> he had wanted.  I think it's unfair to ask Jim to defend things that are 
> basically my own responsibility.  I particularly apologize because I 
> went in for major surgery just about the time this was hitting the fan, 
> and I'm not yet fully functioning.
> 
> There's a certain philosophical difference between folks on this list.  
> Some want SSP to be extremely specific.  Others have gone on at length 
> that the SSP spec has no right or authority to impose its own will on 
> receivers.  I have sympathies for both positions, but I have to agree 
> that there is no chance that we can successfully dictate how receivers 
> operate.  I've said publicly many times that receivers will simply 
> ignore the specs if it makes their lives better --- as we see today with 
> intentional violations of RFC 2822.  SSP-02 is an attempt to pare SSP 
> down to appeal to the second set.  Yes, that weakens SSP, but that seems 
> inevitable at this point.  In particular, I'm concerned that without 
> giving receivers any guidance on how certain situations should be 
> handled we'll end up in a fairly chaotic state.  However, I do agree 
> that such guidance should probably go in a non-standards-track document.
> 
> Signatures), so arguably it was weaker before.  Under SSP-02, a receiver 
> could decide that 3PS should be treated more harshly (where "more 
> harshly" doesn't necessarily mean "discard" --- it could just mean do 
> content scanning on the message).
> 
> knowledge at this time to understand how they should work.  As such, we 
> are now leaving all interpretation of 3rd party signatures up to the 
> receiver.  That doesn't mean we've necessarily lost the ability to 
> handle 3PS in a distinct way, but it will have to go into another 
> Except that DISCARDABLE doesn't prohibit 3PS.  It doesn't even say that 
> messages without any signatures MUST or even SHOULD be discarded.  All 
> it says is how the purported author domain views the messages that it 
> sends out.  The furthest it goes is to say that the purported Author 
> Domain "encourages the recipient(s) to discard it."
> 
> SSP-02 DKIM=ALL is not a "always sign for 1st party authors" concept. It 
> doesn't even mention first parties, any more than it mentions 3rd 
> parties.  All it says is "when the message left my control, I had signed 
> it."  It says absolutely nothing about how the receiver should handle 
> the message.
> 
> under a DKIM=ALL condition.  In fact (if we did it as intended) there is 
> no normative language anywhere in SSP-02 about how the receiver should 
> process messages, be they signed, unsigned, or 3PS.
> 
> [...]
> 
> normative restrictions on when the receiver should accept or reject any 
> messages.
> 
> Another addition to SSP-02 was the concept of the Evaluator.  This was 
> added purely to try to make it clear that SSP is merely one input into 
> the decision process.  The Evaluator decides whether to reject a 
> message, quarantine it, do additional content scanning on it, accept it 
> without further scanning, redirect it to the FBI, post it on USENET, or 
> anything else it cares to do.  My hope was that creating an explicit 
> entity that makes the decision and clearly declare it out of scope we 
> would clarify the limits of SSP.
> 
> It is my sincere hope that we will quickly gain enough experience that 
> new documents can be produced providing further guidance (not

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Feb 2008 09:55:56 -0800

Eric,

Agreed.  This changes "strict" (the exclusivity) assertion into  
something that does not express a domain's intentions on exclusivity.   
This assertion simply increases the likelihood of having the domain's  
messages discarded.

You have previously mentioned the motivation was to accommodate high  
profile domains finding themselves victims of phishing attacks.  Using  
the term "discardable" appears to be sending the wrong message.  It  
seems unlikely these high profile domains want their messages silently  
discarded, as this assertion implies.  Discarding of messages does  
several things:

- Destroys evidence of a serious crime

- Reduces delivery integrity for important transactional messages

- Makes resolving compatibility far more problematic

Can you see changing this into terminology that does not attempt to  
suggest a verifier action?  Going out on limb, I'll add a modified  
furthermore statement.  (Frankly, this furthermore statement seems to  
belong in a BCP that happens later.)

Using Hector's term "exclusive"-

exclusive:
All mail from the domain is signed with an intent to avoid
agents that may damage or remove signatures.  Furthermore,
in lieu of a trusted third-party signature, if a message
arrives without a valid Author Signature due to
modification in transit, submission via a path without
access to a signing key, or other reason, the domain
encourages the recipient(s) to reject the message or issue
a DSN when the RFC 2821 MAILFROM domains match.

-Doug

---

From: "J D Falk" <[email-masked]>
Date: Fri, 8 Feb 2008 13:01:14 -0500

> requirements) for how the Evaluator should interpret SSP for broadest

+1

---

From: Eric Allman <[email-masked]>
Date: Fri, 08 Feb 2008 11:15:15 -0800

Hector,

I have to admit that I'm having a bit of problem understanding 
everything you are saying in your response, perhaps because I haven't 
been able to get through the nearly 500 messages that came in while I 
was recuperating.  I finally concluded that I had to just jump in, 
but I am missing some context.

Thanks for your example on SMTP vs SUBMIT --- that gives me a good 
handle on what you mean by "relaxed protocol".  But I'm not 
understanding "protocol consistency fraud".  I think they are 
connected, but I don't understand how, and how SSP-02 makes it easier 
vs. SSP-01.

So far as I am aware, the SSP-02 /protocol/ is no weaker than in 
SSP-01.  What is weaker normative requirements on how the receiver 
interprets that protocol, which is inevitable if you buy into the 
idea that SSP has no right to impose any requirements on the 
receivers.  If you're disagreeing with that premise then I fully 
understand; this is just a case where you have to choose one and go 
with it, because you can't have it both ways.  As I said before, my 
position is that as desirable as it may seem to put requirements on 
the receiver in order to guarantee consistent results, the reality is 
that the receivers will do whatever they want to in order to give the 
best results for themselves and their customers.  Hence, saying "no 
normative requirements for receivers" is in my mind just bowing to an 
inevitable reality.

This is at the root of eliminating the concept of 3rd Party 
Signatures.  They were only relevant in terms of how the receiver 
interprets the DKIM results, and hence inappropriate for discussion.

You say some things about the Evaluator that lead me to believe that 
you've got a different idea of what it should be than I do.  You say:

> So to me the idea of an Evaluator would be first a fundamental
> protocol consistency Evaluator that would be part of the DKIM/SSP
> framework across all supportive/compliant systems.  It would be
> 100% independent from any subjective or heuristics or reputation
> analysis or any one group detecting their questionable inherent
> policies or implementations methods.

This is the inverse of the model in my head, where the Evaluator is 
completely /dependent/ on "subjective or heuristics or reputation 
analysis" --- it is, in short, how the receiver decides how to 
process the message.  Indeed, the point of introducing the concept is 
an attempt to make explicit what is out of scope for normative 
definition in the SSP spec.

If I'm misunderstanding what you are trying to say (very possible) 
then I apologize and request further explanation.

eric

--On February 8, 2008 6:28:05 AM -0500 Hector Santos 
<[email-masked]> wrote:

> Eric,
>
> I sincerely appreciate your response and I do hope you are on your
> way to full recovery from your surgery. I had a hip replacement a
> few years back and it was the first time in a long time I was
> forced into a prolonged 'vacation' from work. :-)
>
> It been a long road to where we are now.  A road where we tuned
> nearly every stone and discussed, and even worked out.  There were
> some remaining issues, but ones that I don't believe were not
> addressable.
>
> The best I can describe the concerns is that we lost the potential
> for protocol consistency fraud.
>
> However, I never indicated that a VALID 3rd party was ever
> classified as secured, but the lack of one is were the power of the
> concept is found.
>
> A simple example is a traffic cop requesting and analyzing your
> driver license.  The officer is first going to make sure that the
> attributes indicated on the card matches what he sees in person. If
> the driver is a 20 year old woman and the license says 60 year old
> man, then this among other thing he can compare raises a red flag.
>
> Anything that doesn't conform to expectations is always the first
> thing people notice.  As you know, this is a basic model in lots of
> things we do.
>
> In our SMTP world, an excellent example is PORT 25 and its relaxed
> SMTP compliance versus PORT 587 and its strict SMTP compliance
> requirements.   i.e, EHLO checking under port 25 is recognized as
> low benefit for many historical reasons.  Under port 587, EHLO
> correctness is a requirement.   Same with other expects between the
> two protocols.   In short, PORT 587 has less tolerance towards
> legacy operations - by design.  You must login.  You must have
> certain headers, etc.
>
> requirements that some systems may be very strict about if they
> don't exist in the DATA block or post SMTP processing. But there is
> no BCP for this.
>
> But with DKIM/SSP we can take control of this now and not allow it
> to become yet another "relaxed" protocol.
>
> So again, the power here is in protocol inconsistency fraud
> detection. Once things are all "compliant" then the other things
> comes into play, because there is really not much more DKIM/SSP can
> do from this point.
>
> ideas and anything else.  I never argued against reputation. I just
> felt that one group was trying to based DKIM/SSP on it only and not
> even given the SSP concept a chance.  Unfortunately, the entire
> process has been commandeered in what appears to be a strategic
> goal to simply water it down to a level of total uselessness.
>
> So to me the idea of an Evaluator would be first a fundamental
> protocol consistency Evaluator that would be part of the DKIM/SSP
> framework across all supportive/compliant systems.  It would be
> 100% independent from any subjective or heuristics or reputation
> analysis or any one group detecting their questionable inherent
> policies or implementations methods.
>
> It really has nothing to do with good guys vs bad guys because as
> we know, bad guys too can exhibit compliant behavior.  But that is
> we want here - we want to make sure everyone (bad and good) are all
> playing in the same field of following the basic fundamental
> protocol.  Just like we expect with other any standard
> client/server communications protocol.
>
> We want this model because if we can't expect compliance with the
> GOOD, than we can't expect it from the BAD, and if we allow
> DKIM/SSP to become this, we would be back to square one of relaxed
> SMTP legacy transactions where receivers lack enforcement and know
> hows but more importantly has no new information to rely on beyond
> the normal level of operations to consider.
>
> DKIM/SSP changes all that, this is what lead me to technology and I
> of the belief this will be a major benefit for the SMTP industry.
>
> But this is only going to work with a standard protocol "out of the
> box" all must follow if they wish to implement it.  I think this is
> all separate from having extra evaluators (i.e, reputations,
> spam-assassin, etc).   If we start with standard relaxed higher
> level system, then we will have lost an unique opportunity we
> haven't had in SMTP.
>
> Thanks

---

From: Eric Allman <[email-masked]>
Date: Fri, 08 Feb 2008 11:18:15 -0800

Doug,

I am in no way married to the word DISCARDABLE.  We used it in SSP-02 
because it matched ASP.

It has occurred to me that we've spent FAR too much time arguing 
about exactly what word to use.  I'm deeply tempted to switch to 
numbers, special characters, or random gibberish strings so that 
people have to read the actual description.

eric

--On February 8, 2008 9:55:56 AM -0800 Douglas Otis 
<[email-masked]> wrote:

>> discarded.  All it says is how the purported author domain views
>> the   messages that it sends out.  The furthest it goes is to say
>> that the   purported Author Domain "encourages the recipient(s) to
>> discard it."
>
> Eric,
>
> something that does not express a domain's intentions on
> exclusivity.  This assertion simply increases the likelihood of
> having the domain's messages discarded.
>
>
> You have previously mentioned the motivation was to accommodate
> high profile domains finding themselves victims of phishing
> attacks.  Using the term "discardable" appears to be sending the
> wrong message.  It seems unlikely these high profile domains want
> their messages silently discarded, as this assertion implies.
> Discarding of messages does several things:
>
> furthermore statement.  (Frankly, this furthermore statement seems
> to belong in a BCP that happens later.)
>
>

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Feb 2008 11:28:10 -0800

On Feb 8, 2008, at 11:18 AM, Eric Allman wrote:

> Doug,
>
> I am in no way married to the word DISCARDABLE.  We used it in  
> SSP-02 because it matched ASP.
>

It's an assertion that the sender would prefer that the recipient not  
deliver some small fraction of legitimate email as well as some small  
fraction of illegitimate email, rather than delivering those small  
fractions of legitimate and illegitimate email.

In the senders opinion, it is more important that mail claiming to be  
from them not be delivered than for it to be delivered.

The english meaning of "discardable" matches the semantics pretty  
well. If we want implementors to easily understand and deploy the  
specification, and more importantly the limits of them doing so, thats  
fairly important.

Cheers,
   Steve

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 8 Feb 2008 15:18:50 -0500

>[mailto:[email-masked]] On Behalf Of Steve Atkins
>Sent: Friday, February 08, 2008 2:28 PM
>To: DKIM List
>Subject: Re: [ietf-dkim] draft-ietf-dkim-ssp-02.txt 
>Discardable/Exclusive
>
>
>It's an assertion that the sender would prefer that the 
>recipient not deliver some small fraction of legitimate email 
>as well as some small fraction of illegitimate email, rather 
>than delivering those small fractions of legitimate and 
>illegitimate email.
>

I'm not sure that I would agree with framing it as "some small fraction
of illegitimate email". Tracking phishing attacks against our brands
since we have started signing, a receiver checking DKIM and/or SPF would
have easily identified 100% of those fraudulent emails. 

>In the senders opinion, it is more important that mail 
>claiming to be from them not be delivered than for it to be delivered.
>

I think a more appropriate phrasing would be:

"In the senders opinion, it is more important that mail claiming to be
from them and not conforming to certain parameters not be delivered than
for it to be delivered - even at the risk of some legitimate mail being
discarded."

>The english meaning of "discardable" matches the semantics 
>pretty well. If we want implementors to easily understand and 
>deploy the specification, and more importantly the limits of 
>them doing so, thats fairly important.
>
>Cheers,
>   Steve
>

Whatever we decide to call it, SSP should allow a reasonable range of
assertions from both 1st party domains as well as 3rd party domains. As
long as there is clarity of the intended meaning of the assertions I'm
comfortable that the marketplace of receivers will sort things out.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Feb 2008 12:26:44 -0800

On Feb 8, 2008, at 11:28 AM, Steve Atkins wrote:

> It's an assertion that the sender would prefer that the recipient  
> not deliver some small fraction of legitimate email as well as some  
> small fraction of illegitimate email, rather than delivering those  
> small fractions of legitimate and illegitimate email.

This is not an assertion likely suitable in many cases where  
exclusivity is being attempted.  The recommendation of a verifier's  
actions happens to be wrong for many of these cases where exclusivity  
is being sought.

> In the senders opinion, it is more important that mail claiming to  
> be from them not be delivered than for it to be delivered.
>
> specification, and more importantly the limits of them doing so,  
> thats fairly important.

Disagree.  Not delivering a message does _not_ mean discard.

Return to terminology that describes the intended actions of the  
signing domain.  This avoids recommendations almost certainly wrong at  
this point.  Leave this for a later BCP.

Even if assertions were "SSP_X", the draft still needs to define the  
meaning of the assertion.  Defining the meaning in terms of verifier  
actions makes such definition incredibly premature.

Instead, define assertions based upon the signing domain's  
intentions.  Exclude verifier recommendations (leave this to Hector's  
BCP).  Assume verifiers are seasoned professionals.

Do not imply an assertion represents advice that removes RFC 2821  
delivery assurances.

exclusive:
  All mail from the domain is signed with an intent to
  avoid agents that may damage or remove signatures.

If the removal of delivery assurances happens to be the goal, make  
this a separate assertion at the very least.  Don't expect all high  
profile domains wish to suffer a reduction in delivery integrity when  
attempting to better protect their domain's recipients.

transitory:
  All mail from the domain is signed.  All information
  contained in messages is transitory and can be discarded
  when lacking a valid Author Signature.

  BCP to follow.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Feb 2008 12:29:01 -0800

On Feb 8, 2008, at 12:26 PM, Douglas Otis wrote:

> Don't expect all high profile domains wish to suffer a reduction in  
> delivery integrity when attempting to better protect their domain's  
> recipients.

Domains that do not with to suffer a reduction in delivery integrity  
are not candidates for use of any variant of SSP (and, as such, their  
needs are out of scope).

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Feb 2008 12:56:08 -0800

> have easily identified 100% of those fraudulent emails.

You're tracking at the wrong thing then, clearly.

Checking my personal mailbox for mails using your brand:

From: AmericanGreetings.com <[email-masked]>
From: americangreetings.com <[email-masked]>
From: "americangreetings.com" <[email-masked]>
From: "AmericanGreetings.Com" <[email-masked]>
From: "americangreetings.com" <[email-masked]>
From: "AmericanGreetings.Com" <[email-masked]>
From: "AmericanGreetings.Com" <[email-masked]>
From: "AmericanGreetings.Com" <[email-masked]>
From: "americangreetings.com" <[email-masked]>

There were also dozens of other mails that used the  
americangreetings.com brand in the body or subject of the message, but  
not in the From: field.

So, in the data I'm looking at, the "small fraction of illegitimate  
mail" that would have been caught by SSP or anything similar would be  
0%.

(None of the americangreetings related stuff is actually "phishing",  
of course, but many of the issues are quite similar to those of brands  
that actually are phished).

> for it to be delivered - even at the risk of some legitimate mail  

That's a less clear way of saying much the same thing. You want  
recipients to not deliver some small subset of the mail that uses your  
brand without your permission, even at the cost of not delivering some  
small subset of mail using your brand with your permission.

Cheers,
   Steve

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 8 Feb 2008 16:19:33 -0500

>Sent: Friday, February 08, 2008 3:56 PM
>To: DKIM List
>recipient not 
>> I'm not sure that I would agree with framing it as "some small 
>> fraction of illegitimate email". Tracking phishing attacks 
>against our 
>> brands since we have started signing, a receiver checking 
>DKIM and/or 
>> SPF would have easily identified 100% of those fraudulent emails.
>
>americangreetings.com brand in the body or subject of the 
>message, but not in the From: field.
>
>So, in the data I'm looking at, the "small fraction of 
>illegitimate mail" that would have been caught by SSP or 
>anything similar would be 0%.
>
>(None of the americangreetings related stuff is actually 
>"phishing", of course, but many of the issues are quite 
>similar to those of brands that actually are phished).
>

I'm referring to mail that would be checked by DKIM against the From
email address (not the pretty name). My bad for assuming the scope of
the discussion was limited to what DKIM and DKIM-SSP can actually
address. If that isn't the scope then we might as well say that
asserting something in SSP doesn't stop people from speeding in
automobiles. This isn't about silver bullets. DKIM addresses particular
issues. If you prefer a constraining "where" clause then consider any of
my comments on the list as constrained by "For those things addressed
through the use of DKIM signing and DKIM-SSP.....". Having said that,
there are receivers out there that do look for mismatches between From
pretty name and email address or mismatched links in the body of the
email. This is one of the reasons that we have structured our emails the
way we have. If there were a mechanism that allowed me to automatically
communicate this I would do a little jig. Instead I have one-on-one
discussions with various receivers.

I use the term phishing because APWG and others feel that the term is
inclusive of these sorts of activities (malware links, etc).  As with
other terminology I'm perfectly willing to use other terms that might be
commonly accepted.

>claiming to be 
>> from them and not conforming to certain parameters not be delivered 
>> than for it to be delivered - even at the risk of some 
>legitimate mail 
>> being discarded."
>
>That's a less clear way of saying much the same thing. You 
>want recipients to not deliver some small subset of the mail 
>that uses your brand without your permission, even at the cost 
>of not delivering some small subset of mail using your brand 
>with your permission.
>

The assertions you are looking at are not the ones we seek within
DKIM-SSP. I'd be perfectly willing to see a broader means of making
assertions that would protect against other forms of abus of our
brands....as far as I know those are out of the scope of the discussion
here.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Feb 2008 13:28:22 -0800

> discussions with various receivers.

You can't say "receiver checking DKIM and/or SPF would stop 100%
of fraudulent emails" and then redefine "fraudulent emails" as "mails
stopped by receiver checking of DKIM and/or SPF".

DKIM+SSP will only ever stop a tiny fraction of "illegitimate" emails,
and pretending otherwise doesn't lead to an honest evaluation of the
benefits and drawbacks of it.

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Fri, 08 Feb 2008 13:41:40 -0800

> benefits and drawbacks of it.

I dunno, you can also get paralyzed by the enormity of the problem too
and do nothing. DKIM and SSP chip away at a very large problem, and I
don't think we've ever tried to sell it as anything else. Instead of
restating the obvious about no silver bullets, perhaps it would be
better to think in terms what small little new thing we can do to
chip away at the problem? We are looking like we're getting close
to last call with nothing new left on our charter ;-)

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Feb 2008 13:49:00 -0800

> to last call with nothing new left on our charter ;-)

My original observation was that "discardable" was a reasonable term  
for mail for which the sender prefer the recipient not deliver a small  
fraction of legitimate email and a small fraction of non-legitimate  
email rather than deliver either.

There was an assertion made that the "small fraction" of non- 
legitimate email here was actually 100% of the non-legitimate email.  
That assertion was shown to be false, so we can ignore that digression  

Cheers,
   Steve

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 8 Feb 2008 17:03:30 -0500

>Sent: Friday, February 08, 2008 4:49 PM
>To: DKIM List
>My original observation was that "discardable" was a 
>reasonable term for mail for which the sender prefer the 
>recipient not deliver a small fraction of legitimate email and 
>a small fraction of non-legitimate email rather than deliver either.
>

Let's set aside your preference for a small fraction of all mail rather
than my preference to examine a larger percentage of a smaller subset
with regard to DKIM signing.

Flip the question around regardless of which view one chooses to take.
The question is really:

If a domain chooses to sign DKIM with respect to a From field email
address that purports to be from that domain and that domain has the
ability to make an assertion (of any sort) through SSP with regard to
it's practices:

Is the potential benefit afforded a receiver by checking that SSP
assertion AND taking whatever (unspecified) action worth the effort of
doing so? If receivers are likely to have little or no benefit/interest
in checking SSP then the rest of the discussion is moot.

In other words, is the juice worth the squeeze?

Mike

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Feb 2008 18:29:15 -0500 (EST)

> > specification, and more importantly the limits of them doing so,  

+1.

	Wietse

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Feb 2008 18:37:01 -0500 (EST)

> In other words, is the juice worth the squeeze?

Spammers can use DKIM and SSP too. Therefore and the juice is not
worth the squeeze unless the receiver actually knows the domain.
Perfect DKIM+SSP by a total stranger is relatively meaningless.

But we've already visted that station many times in the past.

	Wietse

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 8 Feb 2008 20:01:12 -0500

>[mailto:[email-masked]] On Behalf Of Wietse Venema
>Sent: Friday, February 08, 2008 6:37 PM
>To: [email-masked]
>> doing so? If receivers are likely to have little or no 
>> benefit/interest in checking SSP then the rest of the 
>discussion is moot.
>> 
>Spammers can use DKIM and SSP too. Therefore and the juice is 
>not worth the squeeze unless the receiver actually knows the domain.

I'm asking in terms of the overall implementation. In a world where all
domains are strangers the juice is definately not worth the squeeze.
That is the chicken and egg of kickstarting adoption. 

Is the same true where half (or pick a percentage of your choice)the
domains are strangers? At what point do the benefits of checking
outweigh the costs of checking?

>But we've already visted that station many times in the past.

While it may be absolutely correct with no context - relatively
meaningless at a micro level until behavior starts to be examined and
matched to that signature. At a macro level it may be that receivers
assign a reputation of newly signing domains based on general experience
with the class (or segments based on type of mail received from that
class) newly signing domains. It may be that DKIM+SSP will be matched to
previous mail flows by IP address or other characteristics associated
with a sender. Until DKIM+SSP is in the wild it is hard to say how that
will play out.

If we are trying to use DKIM+SSP to directly identify "bad" then I'm not
sure how useful it will be. There are plenty of ways for bad actors to
act bad. On the other hand, if DKIM+SSP allows some determination of
"good reputation" (tied to behavior of that signing domain) - even if
over time - then it may be useful in some cases. If that then enables a
comparison of the two (where bad is purporting to be the good actor
within certain parameters)it may be useful in other cases.

It will certainly be interesting to see what happens when DKIM+SSP "good
reputation" turns to "bad", especially when it involves subversion of a
domains own security processes. Much talk of how reputation is gained
but little of it's loss. How sticky will good reputation based on
DKIM+SSP or other metrics be?

Without SSP, how (or even why) will receivers choose to take advantage
of DKIM? I'm not talking a handful of domains, I'm talking more general
adoption by receivers. If potential 1st party or 3rd party legitimate
signers (not the bad guys) don't have some expectation as to how
receivers will interpret and act on their signing, how strong an
incentive do they have to begin signing? I'm also assuming that their
expectation has to be a positive outcome or they have a disincentive to
sign.

It's a given that spammers will try to use/abuse DKIM and DKIM+SSP to
cloak themselves with. It's the nature of the beast. This ties into
other issues surrounding mail,domain host compromise and other abuse. I
fully realize that even if DKIM+SSP can afford protection for certain
things it doesn't protect from all bad things. That's another given. 

My understanding with regard to DKIM and other authentication approaches
is that the goal is to stake out defined areas and practices which can
identify/protect legitimate (even if limited or only after reputation is
built) mail and hopefully drive out bad actors from those areas. 

So if it isn't 3PS (01) and it isn't ASP (02) then what is it that is to
be identified/protected by SSP?

There are at least three large receivers that are checking DKIM and
assigning pass/fail to those signatures, even if they may not currently
be taking action on those determinations . I have to assume that there
is a perceived potential benefit on their part to checking for
signatures as well as checking of signatures. 

Is DKIM checking sufficient in itself without SSP? How might DKIM-SSP
help receivers (the 3 aforementioned as well as others) leverage their
evaluation of received email whether signed (valid or not) or unsigned?

Mike

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Feb 2008 20:57:20 -0500 (EST)

MH Michael Hammer (5304):
> assertion AND taking whatever (unspecified) action worth the effort
> of doing so? If receivers are likely to have little or no
> benefit/interest in checking SSP then the rest of the discussion
> is moot.
>

Wietse:
> Spammers can use DKIM and SSP too. Therefore [..] the juice is
> not worth the squeeze unless the receiver actually knows the
> domain.  Perfect DKIM+SSP by a total stranger is relatively
> meaningless.

MH Michael Hammer:
> I'm asking in terms of the overall implementation. In a world
> where all domains are strangers the juice is definately not worth
> the squeeze.  That is the chicken and egg of kickstarting adoption.

The far majority of email is from strangers.  Specifically, there
is an awful lot of email with me as recipient from apparent senders
that I have no relationship with. I have no reason to believe that
my experience differs radically from that of other people.

> outweigh the costs of checking?

Honestly, I know of no reasons why spammers would start to send
less email. There is a lot of spam out there that has nothing to do
with domain spoofing and everything with gullible greedy recipients.

> be identified/protected by SSP?

It's primarily about whitelisting what's "known to be good". When
I get mail that claims to be from a total stranger then it does
not matter if it is 100% DKIM/SSP compliant.

> evaluation of received email whether signed (valid or not) or unsigned?

"known to be good" whitelisting can be done with DKIM-BASE alone.

SSP etc. is about the ABSENCE of valid signatures, and can help to
strengthen the "known to be good" whitelisting process.

When I get mail that claims to be from a total stranger then it does
not matter if it is 100% DKIM/SSP compliant.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Fri, 08 Feb 2008 18:13:59 -0800

> strengthen the "known to be good" whitelisting process.

   You've said this several times, but I don't think that's the range
   of all possibilities. Ag.com is a pretty good example of somebody
   that I as a receiver don't know but if they're willing to say
   "discard this if it's not signed", all other things being equal
   why wouldn't I?

   In any case, this is pretty squarely into the secret sauce of
   receiver filter logic, so I'm not sure what the point is about
   needing agreement; filters are certainly allowed to be more
   cautious which is how I read you.

		Mike

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Feb 2008 21:59:57 -0500 (EST)

>    "discard this if it's not signed", all other things being equal

You do what you want to do.

I would hope that receivers don't discard mail simply because the
domain owner says so. Instead, I would hope that their hint goes
into a weighting process together with other indicators.

	Wietse

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Feb 2008 19:11:00 -0800

>  "discard this if it's not signed", all other things being equal

Because a noticeable chunk of what you'd be discarding would be
legitimate mail that your users wanted. If an ISP pays more attention
to what senders want than what their paying users want, they don't
deserve to be in the business.

The driving factor for receivers is delivering mail that their users
want, and not delivering mail that their users object to.

That is at direct odds to the design of SSP (which is to not deliver
some small fraction of email both legitimate and otherwise).

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Feb 2008 01:35:53 -0500

> into a weighting process together with other indicators.

Look, if you want to design your own products based on these heuristics, 
thats fine, but don't tell us what or how we should implement technology 
  especially mandating via specs on methods that are without of doubt, 
highly questionable, subjective and puts systems and domains at risk for 
even greater abuse.

The system MUST be based on PURE TRUE OR FALSE LOGIC and not anyone's 
GUESS work.

-- 
Sincerely

Hector Santos, CTO

---

From: Michael Thomas <[email-masked]>
Date: Fri, 08 Feb 2008 22:38:21 -0800

> deserve to be in the business.

   This seems to presuppose that the owner of the author domain doesn't
   have any control over their own signing practices. If I publish
   discardable, and it's broken or unsigned that's pretty much my
   problem if it's legit.

   And I'd like to understand where you get a "noticeable" chunk as
   we've been running DKIM signing for almost 2 years now and even
   with diverse mail use patterns of your average mega-corp we still
   get 99%+ verification rates. And we most certainly do not fit the
   bill for "discardable". For somebody who really fits the bill
   for "discardable", I imagine that the false positives would be down
   in the noise of the other reasons you get false positives.

> want, and not delivering mail that their users object to.

   Sure. And a domain that tells me that I ought to consider tossing
   something that isn't signed is dropping a pretty big hint that your
   users are pretty likely to object to it. And if they're wrong, that's
   their own problem to correct.

		Mike

---

From: John Levine <[email-masked]>
Date: 9 Feb 2008 07:07:21 -0000

>   have any control over their own signing practices.

Not at all.  It means that the author domain has some control but not
perfect control over its signing practices, and there will always be
paths that break SSP, e.g., mail-an-article, roaming users sending
through hotel MTAs, mailing lists, forwarders that replace Sender
lines, we all know what they are.

>   get 99%+ verification rates.

I'm not sure how average a megacorp Cisco is.  I'll bet Cisco users
send way less HTML mail that most other businesses, for example.  What
do you do about lists like this one that mutate the headers in ways
that break signatures?  I gather you may have some kludge to patch it
up, but I don't think you can expect everyone else to do that.

>   their own problem to correct.

Look back at Steve's previous messages.  If the domain's bad advice
makes the ISP drop mail its users want, the users will blame the ISP,
not the SSP record.  This would make a reasonable ISP rather gunshy
about believing the advice in random SSP records.  

There are certainly heavily phished domains that merit discarding, but
given what a small fraction of the total universe of mail they are,
it's much more likely that most of the domains that publish SSP
discardable will instead be due to admins who don't understand what it
means.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Feb 2008 05:50:20 -0500

> lines, we all know what they are.

This is making an erroneous presumption that this may not be desirable 
by any segment of the domain market place.

> send way less HTML mail that most other businesses, for example.  

The #1 problem here is that we designing a protocol based on your, mime 
and anyone's guesstimates of numbers.  The protocol is flawed right out 
of the box.

 > What do you do about lists like this one that mutate the headers
 > in ways that break signatures?

They are not candidates for strong policies and getting any real benefit 
and the DOMAIN will know that. If it wishes to continue to allow its 
domain to be used in open and unknown highly exploitable manners, it 
can't expect it be safe from abuse.  That was established long ago.

 > I gather you may have some kludge to patch it

Exactly, which just reaffirms the fact anyone who is going to operate in 
this relaxed exploitable manner SHOULD not expect any much benefit from 
any of this.

But you wish to deny domains, and in my view a vast number of domains, 
the opportunity to get a high degree of benefit from DKIM+STRONG policy 
modes of operation.  This ASP model lowers the incentive to support DKIM 
where inherent default policy of domain abuse ignorance is the mantra.

> not the SSP record.  

So? This sort of stuff commonly happens today in other ways!  In fact, 
it is perfectly valid feedback in the support process to rectify the 
situation in whatever it takes to do so.

Certainly,  the DMA market has a right to do business with users in a 
vendor-user relationship.  CAN-SPAM established this valid relationship.

But, if the DMA market expects to raise the bar of standard SMTP 
transactions by marking its SPAM with DKIM signatures and expects these 
*highlighted* messages to help get their foot into the door, then they 
should also realized by making its mail "special" it also comes with 
special scrutiny as well. Can't have it both ways.  The DAC VBR-INFO 
advice is only going to help tell us, "So far So good."

However, if the DMA market wishes to really help themselves and tell 
receivers that their new form of SPAM are have DKIM signatures, they can 
help keep their reputation harm lower by exposing the idea received 
unsigned messages purported from them are no good and should be 
rejected, then we are all winners:

       "Sure, I send SPAM, but my own SPAM, not SPAM from others"

 > This would make a reasonable ISP rather gunshy about believing
 > the advice in random SSP records.

It seems you are in denial of the quickly involving fact that DKIM is 
becoming dubious with this ASP model.

I can imagine HIGH_VALUE_DOMAIN.COM, a paying member of DAC is being 
told by DAC to sign all its mail with DKIM and more importantly add the 
VBR-INFO header too.

But bad guys see this and say:

      "Hmmmmm, I better stay away from DKIM or any VBR-INFO and see
      what happens."

So now receivers get HIGH_VALUE_DOMAIN.COM messages with no DKIM 
signature, no policy information that one is required and no one to ask 
about it.

Who is harmed?

   - Receivers with abused of their system,
   - Domains with increased reputation harm of sending bad mail,
   - End users who may be phishing victims,

What's your answer to this?

The only reasonable answer I see is SSP-02/ASP DKIM=DISCARDABLE or a 
SSP-01 DKIM=STRICT|ALL set of policies that will provide a BIG hint to 
the receiver unsigned message where it is expected is obviously fraud.

But you want to deny this to any domain because you feel domains are 
still going to allow ROAMING usage of their domain from any site or service.

> discardable will instead be due to admins who don't understand what it

The last time a protocol stated such insightful "small numbers" case:

    RFC 2821:

    7. Security Considerations
    7.1 Mail Security and Spoofing

    ...

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail.

Got it so wrong to the tune of a 10's of billions dollars world wide 
industry problem.  Its no longer a small margin of ignorant users but a 
world wide industry problem.

I hope we can keep flawed subjective policies like the above and being 
repeated here, out of the DKIM POLICY protocol design process.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Sat, 09 Feb 2008 14:25:27 -0500

> understanding "protocol consistency fraud".  I think they are connected, 
> but I don't understand how, and how SSP-02 makes it easier vs. SSP-01.

I'm not sure which part is not understood. The phrase? the usage of 
consistency? combine with fraud?

Consistency in this technical sense deals with protocol logic, it means 
that everything you measure (or get, receive) is "consistent" with what 
expected to be true.

Some definitions in the field:

- "propositions are consistent if they can all be true. A system of 
propositions can be shown to be inconsistent if it contains a 
contradiction (a proposition and its negation). Consistency and 
completeness are two key concerns of modern logic."

- "a harmonious uniformity or agreement among things or parts"

SSP-02, as I read it, does not allow a receiver or lets say removes the 
incentive to perform a consistency check because the specification 
allows for the inconsistent state to exist.

> interprets that protocol, which is inevitable if you buy into the idea 
> that SSP has no right to impose any requirements on the receivers.  If 
> you're disagreeing with that premise then I fully understand; this is 
> just a case where you have to choose one and go with it, because you 
> can't have it both ways.  

Well, I don't think SSP is impose any requirements on the receiver.  It 
is allowing the receiver to make the final decision with known facts 
about what is inconsistent transactions.

Most Receivers don't want any more junk than it has to take on. If it is 
told "Hey, this is junk. I don't care if you get rid of it." then what 
is the final outcome is really up to the receiver.

But just consider that you just said.  Aren't you inherently imposing 
rules on the receiver by indicating SSP should not telling what the 
receiver can or can not do?

> As I said before, my position is that as 
> desirable as it may seem to put requirements on the receiver in order to 
> guarantee consistent results, the reality is that the receivers will do 
> whatever they want to in order to give the best results for themselves 
> and their customers.  

Exactly, but I believe SSP-02 has removing vital information from the 
decision table, and therefore, in virtue of that decision to do this in 
SSP-02, you are negatively imposing your own rules and policies on how 
receivers should behave.

 > Hence, saying "no normative requirements for
> receivers" is in my mind just bowing to an inevitable reality.

Don't you don't you will have a SPF SOFTFAIL like consequent with SSP-02 
DKIM=ALL?

> This is at the root of eliminating the concept of 3rd Party Signatures.  

Sorry, I still don't follow the logic.  The decision is still not based 
on technical merits but subjective policy making on the receiver.

> They were only relevant in terms of how the receiver interprets the DKIM 
> results, and hence inappropriate for discussion.

Do you think everyone is going to implement DKIM as a stand-alone 
appliance "proxy" box engine where it can be fed millions of messages 
and its sole job to process these messages?

If so, then I pity the general case receivers if you believe they are 
going to tolerate such high volume overhead and abuse with little payoff 
in return.

Remember, DKIM eliminates the problem we had with SPF SOFTFAILS.  I 
believe you have stated so yourself in DKIM Media Interviews. But if you 
want results to be treated in the same way via SSP-02, people are going 
to find that, unlike SPF, just REJECTING these "softfails" is a pretty 
reliable bet

As you said, you have no control of the receivers, but you are not 
leaving them any choice either and as far as I am concern, DKIM is sure 
to come out of the gate with a thorn on its side and a black eye with 
this SSP-02 model

> analysis" --- it is, in short, how the receiver decides how to process 
> the message.  Indeed, the point of introducing the concept is an attempt 
> to make explicit what is out of scope for normative definition in the 
> SSP spec.
> 
> If I'm misunderstanding what you are trying to say (very possible) then 
> I apologize and request further explanation.

The standard track SSP protocol should have a protocol consistency check 
before you subject the system with unknown out of scope evaluators.

We had that before, now we don't and there is really no solid 
engineering logic behind the removal.

But its your bag and ball and I guess thats it.  ASP wins!  SSP is dead 
and DKIM will be isolated to a limited market but not the general case, 
where it will begin to be taken advantage of because of all the include 
DKIM forge the SSP-02/ASP people don't want receivers to worry about - 
right!

-- 
Sincerely

Hector Santos, CTO

---

From: Eliot Lear <[email-masked]>
Date: Sat, 09 Feb 2008 21:27:50 +0100

> into a weighting process together with other indicators.

Ain't nothing wrong with this approach.  If someone wants to zero out 
the other indicators, it's up to them.  I for one will want to consider 
reputation of the sender along with SSP results (to say the very 
least).  The rest of this thread seems to me moot based on the current 
direction of SSP-02.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Sun, 10 Feb 2008 12:48:24 -0500

>> Well I think that's perfectly prudent too. What I was reacting to is this
>> notion that I have to "know" the domain in question to assign those
>> weights -- whatever  it means to "know". The ag example is a good
>> one where I'm nearly certain that I don't "know" them <= layer 7, but
>> I'm happy having them give me SSP advice for those layers to act on.
>> I don't need to have some prior relationship with them to make that
>> negative assertion be useful.
> 
> I admit, the "need to know" is mainly for whitelisting, which I
> view as the primary purpose of DKIM and what's built on top of it.

When do whitelist them?  After you manually review the rejection or 
acceptance logs or "On Hold Logs?" or for the lack of a complaint from 
user? Or are you relying on an automated 3rd party whitelist system?

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked] (Wietse Venema)
Date: Sun, 10 Feb 2008 11:10:34 -0500 (EST)

Michael Thomas:
> Eliot Lear wrote:
> > the other indicators, it's up to them.  I for one will want to 
> > consider reputation of the sender along with SSP results (to say the 
> > very least).  The rest of this thread seems to me moot based on the 
> > current direction of SSP-02.
> 

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Sun, 10 Feb 2008 06:42:05 -0800

Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 11 Feb 2008 12:47:34 -0000

> to make explicit what is out of scope for normative definition in the  

I think Hector's model (AIUI) is nearer what I want.

Call it a "DKIM Evaluator". Its function is to examine all the available  
signatures (including the precise forms of their tags), to compare them  
with the various From, Sender, Whatever-Else headers that one would expect  
to be matched by those signatures, and to report where that matching is  
deficient having regard to the SSP policies and their severities  
appropriate to those headers.

Armed with this "DKIM evaluation report", the verifier now knows how the  
sender(s) would like their messages to be treated. On top of this, the  
verifier can also consider other evidence in its possession, its clients'  
preferences and its own internal policies and then proceed as it sees fit.  
But that process should be called the "Local Evaluator", and should not be  
described in the SSP document beyond a mention that it will likely exists.  
But the "DKIM evaluator" can and should be fully described.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Feb 2008 13:13:49 +0000

If you (or Hector, or whoever) have suggested changes for ssp-02 please
raise an issue, including suggested new text and we can process that.

Thanks,
Stephen.

Charles Lindsey wrote:
>> the message.  Indeed, the point of introducing the concept is an 
>> attempt to make explicit what is out of scope for normative definition 
>> in the SSP spec.
> 
> with the various From, Sender, Whatever-Else headers that one would 
> expect to be matched by those signatures, and to report where that 
> matching is deficient having regard to the SSP policies and their 
> severities appropriate to those headers.
> 
> verifier can also consider other evidence in its possession, its 
> clients' preferences and its own internal policies and then proceed as 
> it sees fit. But that process should be called the "Local Evaluator", 
> and should not be described in the SSP document beyond a mention that it 
> will likely exists. But the "DKIM evaluator" can and should be fully 
> described.
>

---

From: <[email-masked]>
Date: Mon, 11 Feb 2008 10:58:15 -0500

Tend to agree, a heavily phished site that I know thru diligence or
communication that prefers a drop in the case of a broken signature
would be accommodated. The rest of the world would be presented to the
unsigned hoops to jump thru.
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Levine
Sent: Saturday, February 09, 2008 2:07 AM
To: [email-masked]
Subject: Re: [ietf-dkim] DEAD HORSE: SSP failure scenarios

R's,
John