ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Lists "BCP" draft review

2010-06-01 16:19:59
On 6/1/10 12:24 PM, Murray S. Kucherawy wrote:
-----Original Message----- From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim- bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas 
Otis

See section 4.3, third paragraph:
,---
[ADSP] presents an additional challenge.  Per that specification,
when a message is unsigned or the signature can no longer be
verified, the verifier must discard the message.  There is no
exception in the policy for a message that may have been altered
by an MLM.  Verifiers are thus advised to honor the policy and
disallow the message.  Furthermore, authors whose ADSP is published
as "discardable" are advised not to send mail to MLMs as it is
likely to be rejected by ADSP-aware recipients.  (This is discussed
further in Section 5.3 below.)
'---

There is no MUST discard, only "encourage".

 Correct, and as has been discussed on the list already, this document
 is avoiding making normative assertions.

This draft is incorrectly translating ADSP as making a normative 
statement when saying:

"Per that specification, when a message is unsigned or the signature can 
no longer be verified, the verifier must discard the message.

Secondly, there is no clear definition for discard, although it is
generally understood to mean silently delete.

 Can you point me to such a definition someplace?

IIRC, Sendmail defined DISCARD in their Access Database Format, where to 
override rejection, assert OK; to permit relaying, assert RELAY; to 
always reject the message, assert REJECT; and to discard the message 
completely, assert DISCARD.  Unfortunately, ADSP  did not define what 
was meant by "discardable".  This draft could add clarity with a section 
that defines its meaning.

This recommendation appears to be making deliver-ability
distinctions between "discardable" and "all", that does not exist
in the ADSP specification.

 Yes, that is precisely the problem.

Is the intent to modify normative language which did not make any 
statement where deliver-ability is to be viewed differently between 
"all" and "discardable"?

The term "discardable" is related to whether a message that was not 
rejected and not delivered may then not return a NDN.

Please add a statement indicating this concept is in conflict with
ADSP.  Such as:

ADSP is in conflict with the Message Stream concept, since An
Author Domains Signature must match exactly with the email-address
domain.

 I fail to see how those two are in conflict.  ADSP works just fine to
 nail down the use of one particular message stream while leaving
 others less restricted.

ADSP does not encompass mail streams, it only covers specific domains, 
not sub-domains.  Although the ADSP's Author Domain Signature definition 
is a bit unclear, section 3.1, among other sections, adds the following:

Section 3.1 "ADSP as defined in this document is bound to DNS. For this 
reason, ADSP is applicable only to Author Domains..."

ADSP has no bearing on mail streams that are defined as having 
sub-domains of the same domain.   In other words, a parent domain can 
not produce a valid Author Domain signatures for a sub-domain.  As such, 
the concept of mail stream is incompatible with the definition for 
Author Domain Signature which specifically excludes references by a 
parent domain.  An indication of these being incompatible concepts could 
prevent some confusion, and help avoid inappropriate terminology when 
referring to ADSP.

How would the concept of mail stream be used in conjunction with ADSP 
which is silent on the presence of a parent signature?

-Doug

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