Subject: [ietf-dkim] ISSUE: SSP-02: MX Record publishing mandate to reduce DNS overhead for SSP Discovery and to detect fraudulent messages

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Feb 2008 19:24:29 -0800

To better ensure the minimum number of DNS transactions occur while  
processing DNS SSP and key TXT records, especially for domains that do  
not implement email, the SSP draft should mandate publishing MX  
records whenever an SSP record is also published.  Since the SSP  
discovery process makes use of MX record queries to determine whether  
the domain exists, then when an SSP record is returned for a domain  
that has not published an MX record, this thereby signals that both  
email and DKIM are NOT used for email addresses at this domain.  This  
strategy affords a better cache hit rate during the SSP discovery  
process, the detection of fraudulent uses of the domain, and a means  
to protect second level domains.

3.2.2. SSP Lookup Algorithm

4th & 6th Sentence Was:

For the purposes of this section a "valid SSP record" is one that is
both syntactically and semantically correct; in particular, it must
match the ABNF for a "tag-list" and must include a defined "dkim=" tag.

This query MAY be done in parallel with the query made in step 2.

If the result of this query is an "NXDOMAIN" error, the SSP Checker
MUST return an appropriate error to the Evaluator and terminate the
algorithm.

4th & 6th Sentence Change to:

For the purposes of this section a "valid SSP record" is one that is
both syntactically and semantically correct; in particular, it must
match the ABNF for a "tag-list", and MUST include a defined "dkim=" tag
and MUST be accompanied by an MX record at the Author Domain.

This query MAY be done in parallel with the query made in step 2.

If the result of this query is an "NXDOMAIN" error, the SSP Checker
MUST return an appropriate error to the Evaluator and terminate the
algorithm.  When the SSP record is returned without there also being
an MX record at the Author Domain, the signature SHOULD BE considered
fraudulent without further DNS transactions being attempted.

Item 2 Was:

2.  _Verify Domain Exists._ The SSP Checker MUST perform a DNS query
  for a record corresponding to the Author Domain (with no prefix).
  The type of the query can be of any type, since this step is only
  to determine if the domain itself exists in DNS.

Item 2 Change to:

2.  _Verify Domain Exists._ The SSP Checker MUST perform a DNS query
  for a record corresponding to the Author Domain (with no prefix).
  The type of the query SHOULD BE for an MX record.  This step can
  depend upon other record types as the response is only to determine
  whether the domain itself exists in DNS.

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 12 Feb 2008 10:54:05 -0000

> fraudulent without further DNS transactions being attempted.

+1

-- 
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: [email-masked] (Wietse Venema)
Date: Tue, 12 Feb 2008 10:23:01 -0500 (EST)

> to protect second level domains.

-1.

Per the draft, an NXDOMAIN reply for an Author domain lookup already
terminates the SSP algorithm with "failure". This is good enough.

DKIM and SSP are not appropriate vehicles for making other records
mandatory where now they are not.

> When the SSP record is returned without there also being

_1. 

I oppose the re-introduction of "suspicious", "fraudulent", etc.
Those are overly-specific interpretations of failures that will
more often than not have non-malicious causes.

	Wietse

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 12 Feb 2008 16:53:25 +0100

Douglas Otis wrote:

> the SSP draft should mandate publishing MX records whenever
> an SSP record is also published.

-1  

SSP (or ASP) have no business to "mandate" MX records, that's
not their job.  MX records are not required for (2)821(bis)
interoperability, and RFC 2119 has a very clear policy about
arbitrary MUSTard.

> Since the SSP discovery process makes use of MX record
> queries to determine whether the domain exists

It could as well use A, AAAA, NS, TXR, RP (FWIW), etc.  AFAIK
it uses MX because that might be also used (i.e. cached) for
other tasks of the MTA. 

> then when an SSP record is returned for a domain that has 
> not published an MX record, this thereby signals that both  
> email and DKIM are NOT used for email addresses

If there are no mail authors in this domain a statement that
these mails from the "non-existing" authors is always signed
suffices to reject unsigned mails from these "non-existing"
authors.  For a domain without users this is a no-brainer,
and unrelated to the non-existence of MX records.  

For a domain with existing users who are not "permitted" to
be mail authors removing any MX records does not suffice to 
educate stubborn users.  

DKIM by design does not depend on SMTP.  Your proposal mixes
unrelated layers.  I like your general MX idea, but is is no
SSP "feature".

 Frank

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Feb 2008 12:18:37 -0500

+1

> unrelated layers.  I like your general MX idea, but is is no

MAJOR +1,   The MX throw in was a major shock to me, just like this 
(__________) SSP-02 draft!

At the very least, it should not be a MUST.

-- 
Sincerely

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 Feb 2008 13:32:09 -0500

> more often than not have non-malicious causes.

That clearly hasn't been shown in the non-DKIM world, and you will 
clearly be wrong in the DKIM world where there a new "SPECIAL" level of 
x822 considerations.  You either get it right or you don't.

The only thing that will be probably remain in doubt are Mail Integrity 
issues as it is with similar digital signature email designs

But after the all the i's are dotted and the t's crossed, this is why 
restrictive policies and protocol consistency checks are important 
because they reduce the concerns regarding possible mail integrity 
breakdowns.

Look, if you want this ASP model to be for just MUAs, why don't you just 
say so.  It so obvious this what is desired by the ASP group.  If not, 
that is not what the document is showing.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Feb 2008 10:36:41 -0800

On Feb 12, 2008, at 7:23 AM, Wietse Venema wrote:

>> processing DNS SSP and key TXT records, especially for domains that  
>> do not implement email, the SSP draft should mandate publishing MX  
>> discovery process makes use of MX record queries to determine  
>> whether the domain exists, then when an SSP record is returned for  
>> a domain that has not published an MX record, this thereby signals  
>> that both email and DKIM are NOT used for email addresses at this  
>> domain.  This strategy affords a better cache hit rate during the  
>> SSP discovery process, the detection of fraudulent uses of the  
>> domain, and a means to protect second level domains.
>
> -1.
>

Disagree.

> mandatory where now they are not.

SSP already suggests querying MX records to facilitate discovery.  
(Even though an MX record does not need to be published.)  What  
prevents SSP making the publication of this record mandatory?  Is  
there any valid reason for a domain that implements DKIM not to also  
publish an MX record?  This record is _essential_ for truncating all  
sorts of policy discoveries that might become associated with the  
introduction of DKIM.

When a domain does exist, there is currently no means for the domain  
owner to truncate a policy discovery processes walking up to the next  
domain and then requesting any number of key records.  In addition,  
there is also no positive means for this domain owner to disavow  
messages inducing undesired policy and DKIM transactions to prevent  
these additional transactions.  Without this convention, there will be  
two or more transactions that this convention could prevent,  
significantly transactions at parent domains.  In addition, this  
convention also makes it explicit any message related to this domain  
has been disavowed by this convention.  Juice worth the squeezing.  : )

>> When the SSP record is returned without there also being an MX  
>> record at the Author Domain, the signature SHOULD BE considered  
> Those are overly-specific interpretations of failures that will more  
> often than not have non-malicious causes.

Agreed.  However, having an SSP record while not having an MX record  
seems like a rare failure mode.   Perhaps the message result could be  
called "disavowed" or "unsupported".  The important aspect of the  
definition is to avoid there being any implied message handling  
without knowing the reliability of this convention.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Feb 2008 10:57:32 -0800

On Feb 12, 2008, at 7:53 AM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> the SSP draft should mandate publishing MX records whenever an SSP  
>> record is also published.
>
> -1
>
> SSP (or ASP) have no business to "mandate" MX records, that's not  
> their job.  MX records are not required for (2)821(bis)  

The MUST only occurs in conjunction with publishing SSP records.  This  
does not mandate publishing of MX records when SSP is not used.

>> Since the SSP discovery process makes use of MX record queries to  
>> determine whether the domain exists
>
> It could as well use A, AAAA, NS, TXR, RP (FWIW), etc.  AFAIK it  
> uses MX because that might be also used (i.e. cached) for other  
> tasks of the MTA.

Agreed, however by querying for the MX record, there are no wasted  
transactions to find an SSP record without an MX record.  Importantly,  
this result can also truncate policy discovery processes to improve  
protections of the parent domains as well as disavowing these messages  
to truncate any number of possible signature validation attempts as  
well.

>> then when an SSP record is returned for a domain that has not  
>> published an MX record, this thereby signals that both email and  
>> DKIM are NOT used for email addresses
>
> If there are no mail authors in this domain a statement that these  
> mails from the "non-existing" authors is always signed suffices to  
> reject unsigned mails from these "non-existing" authors.  For a  
> domain without users this is a no-brainer, and unrelated to the non- 
> existence of MX records.

SSP still mandates a query at the parent domain as well as any number  
of queries for key records.  Once this convention becomes more widely  
adopted, it would allow use of A records for purposes other than SMTP  
without subsequently causing call back verifications, or policy and  
key discoveries.  In other words, this lays the foundation to defend  
against possible abuse.

> For a domain with existing users who are not "permitted" to be mail  
> authors removing any MX records does not suffice to educate stubborn  
> users.

Still, this convention offers a level of protection otherwise lost  
from the number of transactions added by DKIM and SSP.

> unrelated layers.  I like your general MX idea, but is is no SSP  
> "feature".

Agreed.  There should be a stipulation that only SMTP messages will  
have been disavowed.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Feb 2008 11:18:39 -0000

On Tue, 12 Feb 2008 18:57:32 -0000, Douglas Otis <[email-masked]>  
wrote:

>> SSP (or ASP) have no business to "mandate" MX records, that's not their  
>> job.  MX records are not required for (2)821(bis) interoperability, and  
>> RFC 2119 has a very clear policy about arbitrary MUSTard.
>

Exactly. An SSP record is published using the DNS system. One of the  
functions of the SSP draft is to specify the precise means of such  
publication.

So there is no reason why it should not say "An SSP record MUST NOT be  
published unless there also exists a corresponfing MX record". So if  
someone publishes one contary to that, then  it is not a valid SSP record,  
and hence may be ignored by evaluators.

I son't see any problem with doing that, provided of course that the  
technical benefits warrant it.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Feb 2008 10:52:18 -0800

> does not mandate publishing of MX records when SSP is not used.

-1 to this proposal, for the reasons that Wietse and Frank have 
mentioned.  Furthermore, if the domain publishes an SSP record, the SSP 
lookup algorithm never gets to the step that might benefit from the 
publication of an MX record.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Wed, 13 Feb 2008 11:09:14 -0800

> publication of an MX record.

+1 to your -1.  In other words, I agree with you.
d/

-- 

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

---

From: Jon Callas <[email-masked]>
Date: Wed, 13 Feb 2008 12:17:16 -0800

I'd like to add a big -1 to mandating publishing MX, conflating DKIM  
and SMTP and so on.

	Jon

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 13 Feb 2008 15:25:50 -0500

I'll add a -1 to mandating publishing of MX as well.

Do we have enough votes to put this to bed and move on? 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Jon Callas
>Sent: Wednesday, February 13, 2008 3:17 PM
>To: DKIM List
>Subject: Re: [ietf-dkim] Re: ISSUE 1547: SSP-02: MX Record 
>publishing mandateto reduce DNS overhead for SSP Discovery and 
>to detectfraudulent messages
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I'd like to add a big -1 to mandating publishing MX, 
>conflating DKIM and SMTP and so on.
>
>	Jon
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP Universal 2.6.3
>Charset: US-ASCII
>
>wj8DBQFHs1BPsTedWZOD3gYRAsftAKC6GbS3EfXP+8j1dKpe2o8uSwGYsACgjEfs
>SE8mHyOtaH6SvrUKFbxSkJI=
>=irVG
>-----END PGP SIGNATURE-----

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 13 Feb 2008 14:37:01 -0600

> Do we have enough votes to put this to bed and move on?

In case we don't, here's one more.  -1

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Feb 2008 12:48:22 -0800

On Feb 13, 2008, at 10:52 AM, Jim Fenton wrote:

>>>> the SSP draft should mandate publishing MX records whenever an  
>>>> SSP record is also published.
>>>
>>> -1
>>>
>> The MUST only occurs in conjunction with publishing SSP records.   
>> This does not mandate publishing of MX records when SSP is not used.
>
> mentioned.  Furthermore, if the domain publishes an SSP record, the  
> SSP lookup algorithm never gets to the step that might benefit from  
> the publication of an MX record.

Jim,

There appears to be confusion regarding the impact of this  
requirement.  A requirement to publish an MX record when also  
publishing SMTP policy does _not_ impact RFC 2821, which had been the  
basis for these objections.  When the concern is that DKIM Signing  
policy records apply to other types of message traffic, then  
_different_ policy records must be published for each of the different  
protocols or a scope parameter is needed.  There should be a general  
stipulation that the scope of _asp, _ssp, _adsp, or whatever it is  
called is limited to SMTP.  When the policy affects other types of  
message traffic, such as IM or UUDP, the policy records MUST BE  
specifically defined for the type of traffic covered by the policy.

Email policy discovery _will_ impact domains being forged in  
fraudulent email.  These domains may not be either sending or  
accepting SMTP traffic as well.  By establishing a convention that  
SMTP/DKIM policy is only valid in conjunction with a published MX  
record does not change how SMTP or any other message handling protocol  
operates.  This requirement only affects the publishing of SMTP  
related policy.

It is rather unlikely there will be only one policy implemented for  
SMTP, NNTP, UUCP, etc.  In addition, policy discovery adds to the DNS  
burden caused by an undefined number of subsequent key look-ups,  
existence tests, and tree walking for policy.  There may be any number  
of signatures within different sub-domains contained within a  
message.  The MX record mandate, in the case of SMTP policy, provides  
a means to truncate subsequent SMTP transactions to both protect the  
domain and to disavow any related traffic purportedly covered by policy.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 13 Feb 2008 13:52:46 -0800

> specifically defined for the type of traffic covered by the policy.

I'm not confused about the impact of this requirement.  But I don't see 
the benefit of this requirement, not even the efficiency benefit that 
you claim.  I see it as an unnecessary requirement, and I oppose it on 
that basis.
> domain and to disavow any related traffic purportedly covered by policy.

I see that you have opened a separate issue regarding scope.  Good.  
Let's discuss it there.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 Feb 2008 19:50:59 -0500

> In case we don't, here's one more.  -1

And in case that doesn't count, I raise your -1 to my -1, which means -2 
or I agree or no mandate.

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Fri, 15 Feb 2008 18:49:38 -0500

Just in case we need a tie breaker...
 -1

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Fri, 15 Feb 2008 18:28:05 -0800

> Just in case we need a tie breaker...

To summarize, as a bunch of -1 says so little, the push back generated  
by this concept had to do with DKIM policy being applicable to other  
transport protocols that might be bridged into SMTP.  Protocol  
bridging could become problematic when email is not supported natively  
by the transmitting domain.  Of course, this also creates problems  
with respect to DSNs as well.  Ignoring the problem of DSNs, mandating  
support of SMTP when accepting an SMTP message bridged from a  
different transport would be rather problematic when SMTP is not also  
supported.  However, accepting such messages into an SMTP represents a  
choice that opens up an avenue likely to permit abuse.  So this  
concern seems somewhat ill founded.

Determining support of the relevant transport protocol could have been  
generally stated as using the absence of the protocol discovery  
record, (MX in the case of SMTP) in conjunction with the presence of  
the DKIM policy record.  This offered a means to indicate the support  
of a specific protocol, and if not supported, a means to truncate the  
policy discovery process and subsequent validation transactions.  This  
would have better protected existing domains that are not involved in  
email from the traffic generated by spoofed messages.  In addition,  
this would have offered extremely strong refutation of fraudulent  
messages made against any existing domain.  Strong evidence is a good  
thing in general.

To settle the issue as to what protocol is covered by a DKIM policy,  
Jim suggested a policy scope tag instead.  This would permit domains  
to indicate which transport protocols have implemented DKIM and to  
signal when DKIM policy can be applied.  For gateways into SMTP, a  
means to disavow support of a transport protocol could be important as  
a means to better limit avenues of abuse.  In any case, any message  
bridged over into SMTP is likely find SMTP policy applied, and IMHO,  
that can't be helped.  With a protocol scope parameter, DKIM policy  
could then do for IM, what it did for SMTP.  Abuse is not just limited  
to SMTP.

The ability to clearly indicate whether any message is fraudulent  
without incurring additional transactions is also important from a  
general domain protection standpoint.  Jim is right.  Policy can be  
made to include scope, and that also offers a more flexible and  
workable solution.  Message abuse will demand negotiated changes  
accommodated to some extent by policy assertions.  Keeping a lid on  
the the added overhead represents the remaining challenged.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Feb 2008 02:05:17 -0500

Douglas Otis wrote:
>> Just in case we need a tie breaker... -1
> 
> To summarize, as a bunch of -1 says so little, ...

I know, don't you hate that. :-)  I call it the "Follow the Chieftain 
Syndrome"   In my opinion, if "votes" came with some reason or 
explanation for the position, it might help sway others.

> .... the push back generated 
> transport protocols that might be bridged into SMTP.  

Doug, for the record, I was more against the MX lookup MUST in the SSP 
record discovery setup.   IMO, I prefer it to be a MAY or even a SHOULD 
only because historically it was not a requirement and therefore highly 
possible that the MX did not exist.

Keep in mind the steps in SSP is only a recommendation. As long as the 
end result is the same, people don't have to follow those steps. It is 
very possible the MX lookup was already been done in other places.

Look at this way, the way I view it, if we keep the MUST MX lookup 
requirement for the SSP discovery steps, then +1, I would agree there 
should also be a MUST for adding/having a MX record for any x822.From 
domain used in a domain's new DKIM signing mail operations.

So I have less of a problem with the idea from a general DKIM deployment 
recommendation for domains to consider and even possibly a SHOULD 
recommendation for having an MX record for x822.From from the standpoint 
of "DKIM/SSP protocol consistency" especially when it differs from the 
return path or sender domains.

> general domain protection standpoint.  Jim is right.  Policy can be made 
> to include scope, and that also offers a more flexible and workable 
> solution.  Message abuse will demand negotiated changes accommodated to 
> some extent by policy assertions.  Keeping a lid on the the added 
> overhead represents the remaining challenged.

+1, You're right. This is a very important part (for me) in the 
implementation considerations.

But consider, before you can mandate an x822.From MX with a MUST, you 
also have to, at the very least, allow for verifier policy based 
handling and that has been removed in the current emasculated model.

Since policies allowed implementators to optimize and scale DKIM 
processing, its removal reduces the MDA adoption incentive for DKIM 
verification. Thus, with little to no payoff resulting from the 
additional overhead, there is less reason to even bother with the 
overhead.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sat, 16 Feb 2008 05:20:15 -0800

On Feb 15, 2008, at 11:05 PM, Hector Santos wrote:

> I know, don't you hate that. :-)  I call it the "Follow the  
> Chieftain Syndrome"   In my opinion, if "votes" came with some  
> reason or explanation for the position, it might help sway others.
>
>> .... the push back generated by this concept had to do with DKIM  
>> policy being applicable to other transport protocols that might be  
>> bridged into SMTP.
>
> Doug, for the record, I was more against the MX lookup MUST in the  
> SSP record discovery setup.   IMO, I prefer it to be a MAY or even a  
> SHOULD only because historically it was not a requirement and  
> therefore highly possible that the MX did not exist.

While the horse died before leaving the barn, the MX mandate  
(discovery record) would have been imposed only on domains that:

  1) implemented DKIM and
  2) published a DKIM policy record.

This scheme did not impact domains not publishing DKIM policy  
records.  You are correct, MX record may never be published in some  
cases, but it would be nice to impose a simple limitation on domain  
tree walking for polices.

By mandating that a discovery record (MX in the case of SMTP) be  
published along with policy records, just the existence of these two  
records provides a means to detect fraudulent use of a domain without  
examining record content.  This approach tolerates policy record  
format changes, while still safely minimizing the impact of a daily  
onslaught of spoofed references to existing domains that do not even  
handle messages.  The mandate would have offered a means to squelch a  
series of policy and key transactions in such cases.  An invalid  
signature may occur for many reasons, which leaves this result  
category significantly weaker than finding a domain publishing a  
policy record without also publishing a discovery record.

Technically, this approach creates a problem when the domain uses DKIM  
and publishes the policy record, but then does not support SMTP.  When  
their messages are converted by a protocol gateway to SMTP, a policy/ 
discovery record check would detect SMTP is not supported.  While the  
return path instantiated by the protocol gateway could provide a  
conversion for DSNs, the domain of the return path would be unrelated  
to the DKIM signature.  So yes, while this might be seen as a  
disadvantage, it also closes an avenue for abuse not controlled by  
DKIM.  This limitation would induce an assurance of a direct return  
path or the domain would be indicating they don't want a protocol  
translation.  This gives the originating domain greater control, where  
dummy records might be published to achieve the desired effect.

> Keep in mind the steps in SSP is only a recommendation. As long as  
> the end result is the same, people don't have to follow those steps.  
> It is very possible the MX lookup was already been done in other  
> places.

An MX (or some record) was to be queried when a policy record is not  
found to check the existence of the domain.  If an MX record had been  
accessed recently, then it could be in the cache.  Had there been a  
mandate to publish policy and discovery records together, then there  
would be a greater advantage in checking the MX record.

> requirement for the SSP discovery steps, then +1, I would agree  
> there should also be a MUST for adding/having a MX record for any  
> x822.From domain used in a domain's new DKIM signing mail operations.

The logic would be the other way around, but it would seem the WG  
wishes to keep all options open.  By adding scope to the policy  
record, the same effect is possible with somewhat larger policy records.

> So I have less of a problem with the idea from a general DKIM  
> deployment recommendation for domains to consider and even possibly  
> a SHOULD recommendation for having an MX record for x822.From from  
> the standpoint of "DKIM/SSP protocol consistency" especially when it  
> differs from the return path or sender domains.

This represents the minority view however. : (

> But consider, before you can mandate an x822.From MX with a MUST,  
> you also have to, at the very least, allow for verifier policy based  

By pairing policy/discovery records, the content of the policy record  
does not matter in preventing the spoofing of existent domains that do  
not support SMTP.  On the other hand, the term "discardable" instead  
of "strict", "sole", or "exclusive" or words to that effect, means  
transactional domains wishing to thwart spoofing are instead likely to  
find too much of their communications lost.  It will take some time  
for signature integrity to mature.  This problem is not just due to  
mailing-lists.  The "discardable" term will likely ensure the needed  
level of integrity never occurs.  Much of the essential feedback on  
whether the domain is being spoofed, or whether there is a signature  
integrity problem is likely to be lost.

> additional overhead, there is less reason to even bother with the  

DKIM has value at the MUA where scaling and overhead is much less of a  
problem.  The triage process at the MTA could be guided by policy  
assertions.  DKIM validation at the MTA may be limited to domains with  
a history of being targeted by abuse.  When these domains are  
unwilling to make signature assurances, filtering must be relaxed to  
reduce the rate of false positives.  In this regard, there appears to  
be agreement SSP-01 was a better in that respect.  There does not seem  
to be a problem when signatures are added by third-parties however,  
while admitting to not understanding all of that thread.

-Doug

---

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

Douglas Otis wrote:

> and publishes the policy record, but then does not support SMTP.  

Well, I saw that thread. My input: Since the 80s we had multi-mail 
format networking/gateway products that has served millions over the 
course of that time. I think we have a pretty good idea of the practical 
aspects of it.  Primarily, the idea of attempting to obtain gateway 
perfection and persistent mail integrity, DKIM or not, during 
transformation processes is expecting a bit much. :-)

This is just a small part, but on our system, we have a major framework 
user option:

      Preserve MIME: Yes/No

Preserving MIME tells our gateway to import and save mail in raw (as is) 
or save it in our local proprietary format (text with separated 
attachments).  Preserving MIME has only become important over the years 
as our customers as their user's began to use offline readers more, e.g. 
POP3 and News Readers.   As the era of HTML mail is more acceptable, 
that is another reason users are turning on this option.   But there are 
customers, for security reasons, who don't even offer the option to 
their users and save the user's mail in our native format.  This is 
important when it comes the type of MUA question.

Keep focus. DKIM is for a x822 mail system and IMV regardless of how 
x822 mail is sent, moved, gated, transformed, and re-transformed, it 
still has to be a x822 system when it finally gets to where ever.

 > When
 > their messages are converted by a protocol gateway to SMTP, a
 > policy/discovery record check would detect SMTP is not supported.

I think if you are proposing a method for a domain to declare a policy 
that says:

   "Do not expect any mail purported to be from me to originate
    from a QWK, Fidonet, NEWS (NNTP) or XYZ protocol posted system"

while it sounds like a good idea, I think it is an overkill and I 
believe you can the same benefits by using policies that restrict 3rd 
party signatures.

> problem.  

It depends. What kind of MUA are you referring to?  Online or Offline?

You see, some vendors have to deal with design implementations for many 
  mail reading device methods, online and offline.   An Offline MUA has 
different considerations than an Online MUA.

Should we ignore DKIM for users who want to pickup their mail via POP3? 
and just think about the online users?

I think a good reason for the chaotic discussions here is that we 
subjective product designs that is imposing their own feature list on 
everyone else!!

We should instead focus on the functional and logical points of the 
fundamental protocol and let implementators decide how it best fits 
their product lines.  Instead we get people mandating you can't do this 
or that, which might be ok, if it made sense and had considerations for 
the general case of systems out there.

It really isn't that hard.  Either you sign or you don't.  That idea is 
vendor product independent.  All I want to know is what the domain 
intended and expected when we are asked to begin looking at this new 
level of mail information.

        "ok, I looked, I see, now what? What I am doing this for?"

It is really a simple concept.

Did you always expect a 1st signature?  Yeah? Ok, well I don't see one, 
so reject the message.  Sometimes?  Ok, fine. Status Quo.

Did you expect a 3rd party signature?  No?  Ok, reject it.  Don't care? 
ok, fine. Status Quo.

etc, etc.

I really don't see why it matters from where it sent and how.  Do you 
have a preferred type of burglar knocking on your door? <g>

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Sun, 17 Feb 2008 12:32:40 -0500

Douglas Otis wrote:

> Many different doors could be helped by DKIM.  While there might be an 
> expectation that those knocking at the front door will validate their 
> affiliation, there may be different expectations for those at the back 
> door.  The difference might be as simply as not buying wares from those 
> at the back door.  When someone escorts them to the front door, they 
> might be asked to validate their affiliation, although likely unprepared 
> to do so.  While moving everyone to a common doorway may seem ideal, 
> this creates a significant problem when the front door carries a greater 
> obligation.  Different doors need different policies when there are 
> different levels of trust based upon the door used.  At some distant 
> point in the future, perhaps all doors will be treated the same, but 
> time has not arrived.

Doug,

That time came long ago.

Remember, this is predominately about anonymous vs non-anonymous 
transactions and systems have always treaty anonymous and non-anonymous 
transactions differently.

An anonymous back door is the last thing we want, although this strongly 
appears what the ASP model is promoting. :-)

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Sun, 17 Feb 2008 16:24:09 -0500

Douglas Otis wrote:

> It would be safer and less work for policy scoping to list the domain's 
> supported protocols.

Sorry, I just don't see how this will help nor see how it will be less 
work.  I see more complexity with little benefit or value behind it.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Sun, 17 Feb 2008 05:19:57 -0800

On Feb 16, 2008, at 8:24 AM, Hector Santos wrote:

>>
>> Technically, this approach creates a problem when the domain uses  
>> DKIM and publishes the policy record, but then does not support SMTP.
>
> course of that time. I think we have a pretty good idea of the  
> practical aspects of it.  Primarily, the idea of attempting to  
> obtain gateway perfection and persistent mail integrity, DKIM or  
> not, during transformation processes is expecting a bit much. :-)

Other "public" protocols may implement DKIM where messages do not  
enter into SMTP infrastructure.  As a result, the future may require  
policy be based upon which "public" transport carrying the message,  
and not treat DKIM as only protecting messages related to SMTP+  
infrastructure.

> Preserving MIME tells our gateway to import and save mail in raw (as  
> is) or save it in our local proprietary format (text with separated  
> attachments).  Preserving MIME has only become important over the  
> years as our customers as their user's began to use offline readers  
> more, e.g. POP3 and News Readers.   As the era of HTML mail is more  
> acceptable, that is another reason users are turning on this  
> option.   But there are customers, for security reasons, who don't  
> even offer the option to their users and save the user's mail in our  
> native format.  This is important when it comes the type of MUA  
> question.

A less secure means to deal with "delivery" corruption would be to  
rely on something like the Authentication-Results headers assured to  
have been filtered at border MTAs.  It will be awhile before this  
approach can be trusted by generally distributed applications.

> still has to be a x822 system when it finally gets to where ever.

Domains may wish to declare "all" of their SMTP messages will be  
signed, but at the same time are not sign their News or IM messages.   
Domains may also wish to declare News or IM messages are not sent to  
limit a risk caused when gateways apply a different policy for  
messages carried over different "public" transports that are then  
introduced into SMTP+ infrastructure.  As such, "all" needs to be  
qualified.   Either policy records scope the "public" transport, or  
the policy record must be limited to messages destine for SMTP  
infrastructure, where all other "public" transport policies that do  
not enter into SMTP infrastructure are published separately.  Keeping  
policy in one record would help simplify the application of policy at  
"public" protocol gateways, otherwise DKIM policy must be published  
separately and likely will be structured differently.

With the scoping information, gateways bridging other "public"  
protocols would need to:

  a) apply policy based upon the destination protocol (likely, but  
might cause some messages to be considered non-compliant)

  b) internally track and display the "public" reception protocol  
(unlikely, but the most tolerant approach)

>> When their messages are converted by a protocol gateway to SMTP, a   
> I think if you are proposing a method for a domain to declare a  
> policy that says:
>
>  "Do not expect any mail purported to be from me to originate from a  
> QWK, Fidonet, NEWS (NNTP) or XYZ protocol posted system"
>
> believe you can the same benefits by using policies that restrict  
> 3rd party signatures.

When an expectation of seeing a First-Party signature causes a message  
to be categorized as non-compliant, then this expectation needs to be  
calibrated with the "public" transport or communication will become  
disrupted needlessly.  Policy based upon the "public" transport  
appears to be essential, otherwise DKIM is not DKIM when signing an IM  
or News message.

>> DKIM has value at the MUA where scaling and overhead is much less  
>> of a problem.
>
> You see, some vendors have to deal with design implementations for  
> many  mail reading device methods, online and offline.   An Offline  
> MUA has different considerations than an Online MUA.
>
> Should we ignore DKIM for users who want to pickup their mail via  
> POP3? and just think about the online users?
>
> subjective product designs that is imposing their own feature list  
> on everyone else!!

An extension supporting off-line message validation could offer an  
Authentication-Results header that includes a declaration of the  
"public" transport, related public keys, and policy.  Whether that  
ever happens depends upon the marketplace.  Most of free and low cost  
solutions are "on-line", where a "check it yourself" plug-ins is  
already available.

> their product lines.

Agreed.

> Instead we get people mandating you can't do this or that, which  
> might be ok, if it made sense and had considerations for the general  
> case of systems out there.

DKIM may provide a basis for reputation, replacing use of the IP  
address.  This becomes more important as IPv6 use increases.

<rant>
DKIM should have provided a simple autonomous means to authorize Third- 
Party providers.  Expecting Third-party providers to hold thousands of  
domain's private keys within on-line servers is unwise from a security  
standpoint.  As most domains are using third-party providers, setting  
up DNS delegations, CNAMEs, exchanging keys, and applying customer  
specific signatures are expensive to manage, error prone, in addition  
to being unsafe.
</rant>

> It really isn't that hard.  Either you sign or you don't.  That idea  
> is vendor product independent.  All I want to know is what the  
> domain intended and expected when we are asked to begin looking at  
> this new level of mail information.
>
> Did you always expect a 1st signature?  Yeah? Ok, well I don't see  
> one, so reject the message.  Sometimes?  Ok, fine. Status Quo.

An assurance of guarding the original signature had been the "strict"  
assertion.  This changed into "Discardable, don't even bother to  
reject" and is worthless for the category of messages where a "strict"  
assertion could have been beneficial.

> Did you expect a 3rd party signature?  No?  Ok, reject it.  Don't  
> care? ok, fine. Status Quo.

This statement is confusing.  Do you mean:

a) that a signature added to an already signed message leads to  
rejection?

b) that the domain signed, and when this signature is damaged or  
removed, there should be an acceptable Third-Party signature added?

If you meant "b", then I would agree.

> etc, etc.
>
> I really don't see why it matters from where it sent and how.  Do  
> you have a preferred type of burglar knocking on your door? <g>

Many different doors could be helped by DKIM.  While there might be an  
expectation that those knocking at the front door will validate their  
affiliation, there may be different expectations for those at the back  
door.  The difference might be as simply as not buying wares from  
those at the back door.  When someone escorts them to the front door,  
they might be asked to validate their affiliation, although likely  
unprepared to do so.  While moving everyone to a common doorway may  
seem ideal, this creates a significant problem when the front door  
carries a greater obligation.  Different doors need different policies  
when there are different levels of trust based upon the door used.  At  
some distant point in the future, perhaps all doors will be treated  
the same, but time has not arrived.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sun, 17 Feb 2008 12:51:51 -0800

On Feb 17, 2008, at 9:32 AM, Hector Santos wrote:

>> Many different doors could be helped by DKIM.  While there might be  
>> an expectation that those knocking at the front door will validate  
>> their affiliation, there may be different expectations for those at  
>> the back door.  The difference might be as simply as not buying  
>> wares from those at the back door.  When someone escorts them to  
>> the front door, they might be asked to validate their affiliation,  
>> although likely unprepared to do so.  While moving everyone to a  
>> common doorway may seem ideal, this creates a significant problem  
>> when the front door carries a greater obligation.  Different doors  
>> need different policies when there are different levels of trust  
>> based upon the door used.  At some distant point in the future,  
>> perhaps all doors will be treated the same, but time has not arrived.
>
> Doug,
>
> That time came long ago.
>
> transactions and systems have always treaty anonymous and non- 
> anonymous transactions differently.
>
> An anonymous back door is the last thing we want, although this  
> strongly appears what the ASP model is promoting. :-)

DKIM is not about identifying the individual, so in that sense it is  
not about anonymity.  DKIM establishes an affiliation with a domain.   
The identification of individuals depends upon how each domain handles  
and marks their messages, where this is fully determined by what  
messages the domain signs.   *SP policy allows the purported author's  
domain to establish domain affiliation requirements.

Do not suggest that *SP includes identification requirements.  This  
was declared out-of-scope when the WG charter was formed, and remains  
a good recommendation.  By establishing domain affiliation  
requirements, the question of identification depends _completely_ upon  
what messages the domain signs.

It is pointless for DKIM policy to impose requirements that a  
signature validate a From header identity.  RFC 4871 indicates that  
signatures are valid when associated with _any_ header and can even  
remain ambiguous with respect to who introduced the message.    
Identification is clearly a decision of the signing domain that is  
made when the signature is applied.  It should not be the role of  
verifiers to second guess whether the domain made the proper choice.   
This choice is fully within the prerogative of the signing domain.

Nonetheless, DKIM will not be implemented across all message protocols  
for practical reasons.  Until such time, when a domain's policy states  
that "all" messages are signed, in all practicality, this currently  
means "all" SMTP messages are being signed.  Over time, it would be  
wrong to assume DKIM policy only pertains to SMTP.  However, as far as  
protocol gateways into SMTP are concerned, messages should be treated  
"as if" the transport were SMTP, which may become problematic in some  
cases.  So in that sense, there is agreement.

So how can DKIM policy be structured to permit message protocols not  
related to SMTP a means to separately announce when DKIM policy can be  
applied?  One solution suggested by Jim was to introduce a transport  
scoping parameter within the policy record.  Unlike the service  
parameter within the key, policy scoping should also indicate which  
protocols are used that do not support DKIM.  It would be unreasonable  
to assume all protocols will have implemented DKIM when policy is  
published.  It would be unreasonable for the policy record to change  
as DKIM protocol adoption in the wild changes.

It would be safer and less work for policy scoping to list the  
domain's supported protocols, and protocols the domain has implemented  
DKIM.  This listing could allow abuse to be blocked that might be  
introduced through protocol gateways.   This listing can also prevent  
the undesired blocking of messages intended for non-SMTP  
infrastructure when it is known the domain has not implemented DKIM  
for that protocol.  Such policy scoping would permit other message  
protocols an ability to introduce DKIM policy independently from that  
of SMTP, and to improve protections ASAP.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sun, 17 Feb 2008 19:09:47 -0800

On Feb 17, 2008, at 1:24 PM, Hector Santos wrote:

>> domain's supported protocols.
>
> Sorry, I just don't see how this will help nor see how it will be  
> less work.  I see more complexity with little benefit or value  
> behind it.

You many feel *SP is limited to transport protocols delivering  
messages into SMTP related repositories, including messages bridged  
into SMTP.  In other words, *SP governs SMTP message compliance.

Several may balk at this suggestion, and insist DKIM policy extends to  
other protocols.  The categorization of messages permitted by *SP  
could occur for other transport protocols, without their messages  
being delivered to the same location as would SMTP email.  The number  
of message transport protocols that might eventually use DKIM is  
sizeable.  If so, an assertion of "all" messages being DKIM signed  
means what exactly?

Listing protocols where DKIM policy applies, as well as listing  
protocols the domain does not support would be beneficial when  
messages are received over non-SMTP related protocols and:

1) message are delivered to an SMTP related repository.

2) messages are delivered to a non-SMTP related repository.

In both cases, such a list permits:

a) detection of fraudulent sources without reliance upon invalid DKIM  
signatures, and

b) makes an expectation of DKIM signature explicit for non-SMTP  
related protocols to ensure proper message categorization.

By including scope within the policy record, the verifier is then free  
to:

i) assume policy applies to SMTP and ignore it.

ii) detect non-complaint transport protocols.

iii) be assured that DKIM had been implemented for the transport  
protocol in question.

This is not really that different from being able to determine whether  
all messages have been signed.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 18 Feb 2008 12:29:02 -0500

Douglas Otis wrote:
> You many feel *SP is limited to transport protocols delivering messages 
> into SMTP related repositories, including messages bridged into SMTP.  
> In other words, *SP governs SMTP message compliance.

Well, I didn't say that. Practically speaking, DKIM is x822 and the 
design issue is not delivering messages, but how it was originally 
created, transmitted, gated, what have you.

You wish to have protocol management on creation, transportation and 
transformations.  What I said and I believe Charles also alluded to, it 
is very difficult to accurately determine with any high reliability how 
message were originally created or how they were transported and/or 
GATED all of which may be transparent operations.

> all messages have been signed.

Only that it another more complex data point you have to reliably 
confirmed, and you won't be able to.  You can't compare this to a 
straight forward SSP DNS lookup with a TRUE/FALSE explicit policy 
declaration which can be easily confirmed.

IMO, you're asking a bit too much and practically speaking, not worth 
the effort.  Besides, whats the point when the more important part of 
the policy question has been brushed aside by the poison pill ASP/SSP-02?

-- 
Sincerely

Hector Santos, CTO

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Feb 2008 12:02:04 -0000

> possible that the MX did not exist.

However, having an MX record has always been regarded as Best Practice (as  
opposed to relying on just a naked A record). So all we are now saying is  
that if you are now proposing to publish SSP, then you MUST henceforth  
start accepting that Best Practice by publishing an MX as well. If you are  
not prepared to do that, then Do Not publish an SSP.

What could be simpler than that?

As for people who still send their mail by UUCP, it has always been the  
case that if they include a From (or Reply-To) with an address on RFC 2822  
format (i.e. local-part@domain), then they are supposed to arrange with  
some friendly internet site somewhere to act as a gateway for them, and to  
publish an MX accordingly. That has always been the case.

A message that simply contains "From: foo!bar!baz" is not an RFC 2822  
message.

And if your message contains "From:[email-masked]", then there is no way  
to publish an SSP for it, even if some smart sendmail system can still  
figure out how to send replies back to it. So I don't think UUCP systems  
pose any real problem for SSP.