Subject: [ietf-dkim] Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP

From: The IESG <[email-masked]>
Date: Thu, 12 May 2011 08:02:17 -0700

The IESG has received a request from the Domain Keys Identified Mail WG
(dkim) to consider the following document:
- 'DKIM And Mailing Lists'
  <draft-ietf-dkim-mailinglists-10.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-05-26. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   DomainKeys Identified Mail (DKIM) allows an administrative mail
   domain (ADMD) to assume some responsibility for a message.  Based on
   deployment experience with DKIM, this Best Current Practices document
   provides guidance for the use of DKIM with scenarios that include
   Mailing List Managers (MLMs).

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dkim-mailinglists/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dkim-mailinglists/

No IPR declarations have been submitted directly on this I-D.

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

---

From: SM <[email-masked]>
Date: Fri, 13 May 2011 00:15:50 -0700

>[email-masked] mailing lists by 2011-05-26. Exceptionally, comments may be

 From Abstract Section:

   "Based on deployment experience with DKIM, this Best Current
    Practices document provides guidance for the use of DKIM
    with scenarios that include Mailing List Managers (MLMs)."

Although one can extrapolate from experience and provide some 
guidance, I would not call it "Best Current Practices".  I suggest a 
change to that sentence:

    Based on deployment experience with DKIM, this document provides
    guidance for the use of DKIM with scenarios that include Mailing
    List Managers (MLMs).

Quoting the Introduction Section:

   "The goal for this document is to explore the use of DKIM for
    scenarios that include intermediaries, and recommend Best
    Current Practices based on acquired experience."

The Intended Status of this document is BCP.  I cannot support a 
recommendation for "Best Current Practices" that is not based on 
existing practices.  If the IETF wants a stick to tell the outside 
world what to do, it can publish this document as a BCP.  If the IETF 
would like to provide guidance, leave it to the outside world to 
adopt that and then document the current practice, it should not 
publish this document as a BCP.

 From Section 2.5:

   "Each of these could have different security policies imposed
    against them, or there might be a desire to insulate one from
    the other (e.g., a marketing campaign that gets reported by
    many spam filters could cause the marketing stream's reputation
    to degrade without automatically punishing the transactional or
    user streams)."

Shouldn't that be sending policies instead of "security 
policies"?  If we go a stretch further, a marketing campaign might 
end up be labelled as a terrorist act and that falls under the Security Area.

I'll translate that paragraph for a wider audience.  Some companies 
send out spam; it keeps businesses happy if it is called a marketing 
campaign.  These companies also send out messages that the receiver 
actually wants to read.  On the receiving side, there is a lot of 
zealotry that goes on.  One way to mitigate the effects of that 
zealotry is to provide the receiver a means to separate the spam from 
other mail.

In Section 3.3:

   "Some lists prepend or append a few lines to each
    message to remind subscribers of an administrative URL for
    subscription issues, or of list policy, etc."

It's funny to see how some MUAs adapted to that by hiding these lines 
thereby rolling back that "fix".

In Section 4.1:

   "In an idealized world, if an author knows that the MLM to which a
    message is being sent is a non-participating resending MLM, the
    author SHOULD be cautious when deciding whether or not to send a
    signed message to the list."

The author generally does not have any control over that decision as 
DKIM signing is not done at the MUA level.  The usage of a key word 
is somewhat excessive here as the ideal world is out of scope for RFC 2119.

   "This problem can be compounded if there are receivers that apply
    signing policies (e.g., [ADSP]) and the author publishes any kind
    of strict policy, i.e., a policy that requests that receivers reject
    or otherwise deal severely with non-compliant messages."

The "definition of insanity is doing the same thing over and over and 
expecting different results".   There are parallels between ADSP and SPF.

In Section 5.1:

   "It is RECOMMENDED that periodic, automatic mailings to the list are
    sent to remind subscribers of list policy."

This is currently being done by the IETF under the guise of mailman day.

In Section 5.5:

   "In that case, authors SHOULD create a mail stream
    specifically used for generating signatures when sending traffic to
    MLMs."

I suggest using "DKIM signatures".

   "This suggestion can be made more general."

Shouldn't that be recommendation?

In Section 5.8:

  "DKIM-aware authoring MLMs MUST sign the mail they send according to
   the regular signing guidelines given in [DKIM].

   One concern is that having an MLM apply its signature to unsigned
   mail might cause some verifiers or receivers to interpret the
   signature as conferring more authority or authenticity to the message
   content than is defined by [DKIM].  This is an issue beyond MLMs and
   primarily entails receive-side processing outside of the scope of
   [DKIM].  It is nevertheless worth noting here."

Removing the MUST and saying:

   DKIM-aware authoring MLMs signs the messages they send according to
   the regular signing guidelines given in [DKIM]

gives more weight to the last two paragraphs, especially with the 
note about the concern.

In Section 5.10:

   "An FBL operator might wish to act on a complaint from a user about a
    message sent to a list."

Shouldn't that be FBI? :-)

In Section 5.11:

   "Receivers SHOULD ignore or remove all unsigned externally-applied
    Authentication-Results header fields, and those not signed by an ADMD
    that can be trusted by the receiver."

Quoting Section 5 of RFC 5451:

   "For security reasons, any MTA conforming to this specification MUST
    delete any discovered instance of this header field that claims to
    have been added within its trust boundary and that did not come from
    another trusted MTA."

   "For simplicity and maximum security, a border MTA MAY remove all
    instances of this header field on mail crossing into its trust
    boundary."

The MUST and the MAY are aggregated into a SHOULD.  Is that intentional?

 From Section 5.11:

   "Upon DKIM and ADSP evaluation during an SMTP session (a common
    implementation), an agent MAY decide to reject a message during an
    SMTP session.  If this is done, use of an [SMTP] failure code not
    normally used for "user unknown" (550) is preferred; therefore, 554
    SHOULD be used."

This falls under policy decision.  The usage of a 554 code is 
inappropriate.  From Section 3.6.2 of RFC 5321:

   "If it [SMTP server] declines to relay mail to a particular address
    for policy reasons, a 550 response SHOULD be returned."

 From the same section of this document:

   "SMTP servers doing so SHOULD also use appropriate wording in
    the text portion of the reply, perhaps explicitly using
    the string "ADSP" to facilitate searching of relevant data
    in logs."

I wouldn't put a SHOULD in there.  The working group made the 
argument.  Leave it at that.

Quoting two sentences from the same section to provide better context:

   "In such cases where the submission fails that test, the receiver or
    verifier SHOULD discard the message but return an SMTP success code,
    i.e. accept the message but drop it without delivery.  An SMTP
    rejection of such mail instead of the requested discard action
    causes more harm than good."

I would remove the SHOULD as the argument (second sentence) is 
clear.  The usage of the SHOULD raises the question about whether 
this is a SMTP receiver action and whether it is appropriate to 
create a black hole (silent drop of message).

I found the document well-written.  In places where the document 
advocates a particular approach, it provides an explanation for 
that.  This document can be published as Experimental or 
Informational.  Please note that such an intended status is not a 
dilution of the value of the document.

As there has been some discussion about an Applicability Statement 
experiment, I'll quote some text from RFC 2026:

   "An Applicability Statement specifies how, and under what circumstances,
    one or more TSs [Technical Specifications] may be applied to support a
    particular Internet capability."

This document covers RFC 4871 (4871bis actually), RFC 5451 and RFC 
5617.  The document specifies the circumstances under which the 
capabilities discussed here are applicable.  If the DKIM working 
group decides on taking that path, it could ask for publication of 
the document as Proposed Standard.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 13 May 2011 11:17:02 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Friday, May 13, 2011 12:16 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP
> 

Hi SM,

By my read, the bulk of your comments fall into these categories:

(1) Remove the normative language, publish as Informational

As I said to John, I'd be fine with this.  The document started out as Informational but there was working group momentum in the direction of a BCP instead, hence the conversion to use of RFC2119 language.  I personally don't have strong feelings about that so if the preferred course of action is to go back to that, I'd be fine.

As for the idea of using PS instead, that doesn't seem appropriate to me given we're not standardizing a protocol here, and at best we don't have enough implementation experience to back up the claims.

(2) Editorial changes

I'd be fine with all of the changes you proposed.

(3) RFC5451 discussion

> The MUST and the MAY are aggregated into a SHOULD.  Is that

Yes, I believe they are consistent.  The citation you made from RFC5451 directs implementations to delete forgeries (the MUST) and optionally delete everything else as well (the MAY).  The citation from this document does not dispute the MUST, and provides further guidance for this particular application (which is also consistent with other parts of RFC5451) in terms of how to deal with what's left after the MUST part is done.

>     for policy reasons, a 550 response SHOULD be returned."

3.6.2 applies to relays, not recipients.  A relay might try DKIM validation and ADSP evaluation, but that's not the model this document discusses.

However, if that doesn't matter, unfortunately this makes the distinction we're trying to make impossible without using enhanced status codes, which aren't universally used.  But to be conformant, I suppose 550 5.7.0 would be appropriate.

> create a black hole (silent drop of message).

If we are leaving the normative language in (for BCP, should that status stay) then I think the SHOULD is appropriate in the sentence that defines the normative action.

Thanks for the review!

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 May 2011 20:12:02 +0200

> is somewhat excessive here as the ideal world is out of scope for RFC 2119.

+1, should be lowercase.

> expecting different results".   There are parallels between ADSP and SPF.

As a corollary, it is sane to do slightly different things over and
over until one catches the one that works.  SPF is slightly better
than ADSP, though.

> This is currently being done by the IETF under the guise of mailman day.

Yes, the time-distributed database...

> Removing the MUST [...]

+1, the MUST is in DKIM's specs and thus is redundant here.

> Shouldn't that be FBI? :-)

+1 (smiley not taken), FBL is a specific mechanism.  As much of the
advice is also valid for other mechanisms, I suggest to change the
title to "Abuse Reporting Issues" or similar.

>     for policy reasons, a 550 response SHOULD be returned."

-1, although it is a policy question, it has nothing to do with relaying.

> create a black hole (silent drop of message).

This should have been explained more clearly in RFC 5617.  Perhaps, we
should say that "discardable" means "droppable" in general?

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 13 May 2011 22:40:44 +0200

On 5/13/11 8:12 PM, Alessandro Vesely wrote:

[...]

> should say that "discardable" means "droppable" in general?

The problem what 'discardable' means has been introduced in RFC5617 and 
I don't think draft-ietf-dkim-mailingslists-10.txt has to 'fix' that 
problem. The meaning of 'discardable' has been discussed on this list at 
least two times (see for example 
http://mipassoc.org/pipermail/ietf-dkim/2008q1/009557.html) and this has 
AFAIK not resulted in one unambiguous conclusion. Furthermore, as it's 
not primarily an MLM issue (but an ADSP issue), I don't think we should 
re-open the discussion again. Don't get me wrong, I agree with you that 
it's important to define what we mean with discardable, but not here, 
not now.

I'd propose to put this item ('writeup a definition of 'discardable') on 
the to-do list of a successor of RFC5617, if there ever will be one. Or 
on another future 'policy' document.

/rolf

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 May 2011 18:01:15 -0400

Rolf E. Sonneveld wrote:
> problem. 

Nothing wrong with DKIM=DISCARDABLE.  What is wrong is trying to 
dictate to others MLM should ignore ADSP.

As a MLM vendor, I have technical and ethical engineering obligation 
not to cause problems when taking on a new inherently incompatible 
technology that doesn't naturally fit with a MLM.

Hence, there are two general solutions for the MLM:

    MLM-LEVINE: Ignore all DKIM ADSP restrictive policies
    MLM-SANTOS: Preempt all DKIM ADSP restrictive policies

I know as a matter of fact MLM-SANTOS is a better DKIM mail 
integration fit because we implemented it.

Also, you can't dictate to receivers they should ACCEPT and DROP. 
Although that could be feasible solution to solve MLM ignorance to 
support ADSP, its a very difficult issue when increasing receiver 
practice is rejecting bad mail at the DATA level.

What I had proposed is is method (rule) at the DATA filter:

   if message fails ADSP and has a LIST-ID,
      then respond 250 and discard the message

   if message fails ADSP and has no LIST-ID,
      then reject with 55x

The problem is the MLM that is *ignoring* ADSP and passing on the buck 
to ADSP ready member receivers adding the overhead to receivers and 
also creating new MLM problems for itself.  A repeated SMTP level 
rejection will cause harm to list member by the MLM sender creating 
false automated unsubscribing notifications when the attempts are 
exhausted. So if the receivers can detect its a MLM sender incorrectly 
sending ADSP protected mail, then the only recourse, in the name of 
not causing problems and backing up the ignorant MLM, is to accept 
(250) and then drop the message.

But the real solution is for the MLM to follow proper DKIM mail 
integration considerations when adding something new it hasn't done in 
40 years.

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 May 2011 19:18:07 -0400

> integration fit because we implemented it.

Keep in mind that I recognize MLM-LEVINE solution but that is based on 
ignoring all originating DKIM information - pass, fail or unknown. 
The theory is based on:

   A) The Member is already authorized based on being a list member
      already,  CONCUR

   B) No expectation of getting fraud submissions, and if so, a
      negligible amount, CONCUR

   C) Ignorance for DKIM failure promoting a relaxed atmosphere of
      DKIM unknown signer mail, OBJECT.

   D) Trust the single signer domain at the SYSTEM LEVEL (global), OBJECT.

Assuming this MLM-LEVINE is the acceptable solution, then the 
optimized, lower overhead receiver operation is to first check to see 
if the signer(s) are known before even trying to verify any signature.

> What I had proposed is method (rule) at the DATA filter:
> 

Note, by fails ADSP, it is presumed the policy is DKIM=DISCARDABLE

To complete the logic for always accept systems:

    if message fails ADSP then discard the message

You got to understand there is a split of how systems operate; many 
systems for scalability reasons, especially in earlier days, always 
accepted the message and then applies any mail filters.  As hardware 
and software (multi-threaded OSes) improved, and also to address the 
bounce problem, more systems began to do more dynamic rejections at 
the DATA level.  The technical responsibility to issues bounces is 
very strong.  The idea of discarding was largely frown upon.

This multi-decade BOUNCE requirement mindset, which touches base with 
1986 US EPCA provisions for avoid censorship claims, has changed for 
the first time in RFC5321 with new semantics that recognizes the 
contemporary needs to "drop mail" when reasonable non-frivolous new 
considerations are appropriate.  I pushed for this recognition known 
new technology like Sender-ID and ADSP was on the horizon.

In short, Levine did a good thing by technically "legalizing" 
discarding of mail.

---

From: SM <[email-masked]>
Date: Fri, 13 May 2011 21:57:08 -0700

Hi Murray,
At 11:17 13-05-2011, Murray S. Kucherawy wrote:
>As I said to John, I'd be fine with this.  The document started out 
>as Informational but there was working group momentum in the 
>direction of a BCP instead, hence the conversion to use of RFC2119 
>language.  I personally don't have strong feelings about that so if 
>the preferred course of action is to go back to that, I'd be fine.

Ok.

>Yes, I believe they are consistent.  The citation you made from 
>RFC5451 directs implementations to delete forgeries (the MUST) and 
>optionally delete everything else as well (the MAY).  The citation 
>from this document does not dispute the MUST, and provides further 
>guidance for this particular application (which is also consistent 
>with other parts of RFC5451) in terms of how to deal with what's 
>left after the MUST part is done.

Ok.

>3.6.2 applies to relays, not recipients.  A relay might try DKIM 
>validation and ADSP evaluation, but that's not the model this 
>document discusses.
>
>However, if that doesn't matter, unfortunately this makes the 
>distinction we're trying to make impossible without using enhanced 
>status codes, which aren't universally used.  But to be conformant, 
>I suppose 550 5.7.0 would be appropriate.

You can use 550 5.7.1.  The enhanced status code used in the draft is 
appropriate.

Thanks for the quick response.  BTW, I forgot to the "best current 
practices" in Section 8.  It's an editorial nit.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 14 May 2011 12:22:03 +0200

On 13/May/11 20:17, Murray S. Kucherawy wrote:
>> From: On Behalf Of SM

My reading of SM's comments is for replacing "Best Current Practices",
not normative language in general (but in particular, where it is
redundant.)  I consider his thoughts in accord with what another John
noted:

   When we make that sort of recommendation in a BCP, we expose
   ourselves to the criticism that the recommendation is neither
   best (as distinct from a bad compromise), nor current (as
   distinct from a recommendation about future behavior), nor
   actively practiced.

> the preferred course of action is to go back to that, I'd be fine.

-1, I'd favor AS/PS or even experimental over BCP, but still prefer
BCP over informational.

> As for the idea of using PS instead, that doesn't seem appropriate
> to me given we're not standardizing a protocol here, and at best we
> don't have enough implementation experience to back up the claims.

How about running a test?  I guess many of us can configure their MTAs
for signing/verifying as it requires...

> validation and ADSP evaluation, but that's not the model this

Yes, my understanding of that SMTP snippet is that it concerns
responses to RCPT TO:<particular address>, while DKIM and ADSP can
only be evaluated after <CRLF>.<CRLF>.  (In this respect, mentioning
"user unknown" in the MLM spec may cause some confusion in readers not
familiar with SMTP.)

> status codes, which aren't universally used.

+1 for keeping 554 as is.

>  But to be conformant, I suppose 550 5.7.0 would be appropriate.

Conformant to what?

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 May 2011 08:14:04 -0400

Alessandro Vesely wrote:

>> SM wrote:

Which is not always used.  RFC2554 (ESMTP AUTH) allows the usage of 
530 when you want to show an unauthorized state considition applicable 
to RCPT TO:

        530 Authentication is required for relaying.

A quick log grep of RCPT TO relay rejections show a unique set of these:

   501
   530
   550
   550 5.1.1
   550 5.1.2
   550 5.4.1
   550 5.7.1
   551
   553
   554 5.7.1
   554
   571

>> validation and ADSP evaluation, but that's not the model this

For the record, unauthorized relay rejects can be done at the data 
level as well.  RFC5321 3.3:

    However, in practice, some servers do not perform recipient
    verification until after the message text is received.

> +1 for keeping 554 as is.

+1

>>  But to be conformant, I suppose 550 5.7.0 would be appropriate.

Well RFC5321 does has open-ended 550 text that includes policy semantics:

    550  Requested action not taken: mailbox unavailable (e.g.,
         mailbox not found, no access, or command rejected for
         policy reasons)

But 554 or 552 is technically correct for a DATA EOD reject.

You can clearly see this in section 4.2.2 showing Reply Codes by 
Function Groups. The wo codes next to each other:

    354 Start mail input; end with <CRLF>.<CRLF>
    554 Transaction failed (Or, in the case of a connection-opening
        response, "No SMTP service here")

And you also have section 4.3.2

    DATA
       I: 354 -> data -> S: 250
                         E: 552, 554, 451, 452
       E: 451, 554, 503

552 and 554 are the technically correct permanent reject codes for the 
end of data state. Since 552 is related to storage, 554 is the more 
appropriate response.

Ideally, if Murray wishes to support Jeff McDonald's Anti-Spam ID that 
is intended to update RFC3463, he might use (since this is all new 
anyway):

    554 5.8.0 Undefined Policy detail
    554 5.8.1 Message refused by local policy

or perhaps Murray can propose to Jeff to add a 5.8.27 status code 
specifically for ADSP related policy rejects:

    554 5.8.27 Message refused by ADSP From.Domain=<IDENTITY-ODID>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 May 2011 11:32:21 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Saturday, May 14, 2011 3:22 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP
> 

If the document status changes to Informational, which is what I expect, I don't think we can use normative language at all.

> "user unknown" in the MLM spec may cause some confusion in readers not

I don't think it refers to any specific phase of SMTP; could be post-DATA (per DKIM), could be RCPT for some other method.
 
> >  But to be conformant, I suppose 550 5.7.0 would be appropriate.

RFC5321, as cited.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 May 2011 11:35:15 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Saturday, May 14, 2011 5:14 AM
> Cc: IETF General Discussion Mailing List; Alessandro Vesely

I don't have an opinion on that draft yet, but I don't want to delay MLM's publication by referring to Jeff's, whose future is indeterminate right now.

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 May 2011 14:43:40 -0400

>> Alessandro Replied:

> RFC5321, as cited.

See section 4.3.2

     DATA
        I: 354 -> data -> S: 250
                          E: 552, 554, 451, 452
        E: 451, 554, 503

I don't see 550 there.

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 May 2011 14:49:53 -0400

>>>>  But to be conformant, I suppose 550 5.7.0 would be appropriate.

Correction, I was looking at 2821.  5321 updated it to:

       DATA
          I: 354 -> data -> S: 250
                            E: 552, 554, 451, 452
                            E: 450, 550 (rejections for policy reasons)
          E: 503, 554

550 would be correct for update software.

---

From: SM <[email-masked]>
Date: Sat, 14 May 2011 11:59:02 -0700

Hi Hector,
>         E: 451, 554, 503

 From http://www.rfc-editor.org/rfc/rfc5321.txt

DATA

          I: 354 -> data -> S: 250

                            E: 552, 554, 451, 452

          E: 503, 554

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 May 2011 16:16:44 -0400

Hi SM,

Updated 5321 noted. I had the 2821 doc open.

Lets keep in mind that these DATA EOD temporary or permanent reject 
codes are almost always local policy reasons, including 552 and 554. 
Since 550 is quite often used at RCPT TO or even at in DATA are for 
"unknown users" semantics, something other than 550 is preferred.  We 
must remain backward compatible for clients who are not supporting 
RFC3463 and receivers as well not issuing RFC3463 status codes.

I recommend (prefer) text that reflects receiver w/o RFC3463 support.

   554 Messages refused by ADSP violation, 
From.Domain=<RFC5322.From.domain>
   554 5.7.0 Messages refused by ADSP violation, 
From.Domain=<RFC5322.From.domain>

(Note, I don't care if its From=<RFC5322.From> and/or ADSP changed to 
Signing Practice)

The reasons are:

1) We got more ~30 years under 821/2821 with the EOD 552, 554 possible 
code, only 2 years with RFC3521, and even if we want to promote the 
modern recommendations using 550,

2) The client could be a MLM MTA not reading extended codes or the 
receiver not sending extended codes and the 550 may not be enough to 
preempt false automated unsubscribed notifications.

We can not presume that adding DKIM support also means adding RFC34563 
support.

Practically coding, a DKIM aware MLM adding this conditional check 
might look for three or five triggers:

    554
    5.7.0
    5.8.0 or 5.8.1
    "ADSP" or "POLICY" or some other recommended work that could be used.

I think that the I-D should not lock in and be more general about this.

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 May 2011 19:59:39 -0400

Nits and Comments:

In Section 3.1.

    author:  The agent that provided the content of the message being
       sent through the system.  The author delivers that content to the
       originator in order to begin a message's journey to its intended
       final recipients.  The author can be a human using an MUA (Mail
       User Agent) or a common system utility such as "cron", etc.

What is "cron?" and how does it interface with the originator defined as
the MSA?  is cron an MTA or MUA?

I suggest to remove the "or a common .." text since we already know 
what MUA implies - a mail creation application or replace the text with:

       or any other message creation application [with an MTA component].

I personally say take it out. Not needed. Thats an *nix idea.  Windows 
people generally do not know what that is.

In Section 3.1.

    verifier:  Any agent that conducts DKIM signature analysis.

I know this is a semantical nit, but RFC4671 uses verification, never 
analysis and it (analysis) is only stated as an out of scope boundary 
layer concept (in section 3.11).   Perhaps the intent is to suggest 
the verifier does both:

    verifier:  Any agent that conducts DKIM signature validation and 
perhaps
               [results|TRUST and ADSP] analysis.

In Section 3.1 for receiver, it is very clear with stating the agent 
for "final delivery", so why not add the MDA labeled terminology as it 
was done with originator with MSA?

    receiver: ..... This agent can be often referred to as the
       Mail Delivery Agent (MDA).

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 15 May 2011 13:48:24 +0200

Ok.

> I recommend (prefer) text that reflects receiver w/o RFC3463 support.

+1, and we have to mandate a precise format for the text, I mean a
production rule including %x41.44.53.50, or forget this whole idea
that a receiver could make a better job by signaling ADSP violations.

>     "ADSP" or "POLICY" or some other recommended work that could be used.

Indeed, a gateway on a Mac that forwards by means of the AppleTalk
Data Stream Protocol, may signal a failure of the latter stack by
554 ADSP failure.

-- 
http://www.all-acronyms.com/ADSP

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 15 May 2011 09:36:00 -0700

> Sent: Saturday, May 14, 2011 5:00 PM
> Cc: [email-masked]

It's a daemon that runs on UNIX systems which can be told to run specific programs at specific periodic times.  It is neither an MTA nor an MUA; it is an example of something that is an "author" in this context but is not also a human.

>        or any other message creation application [with an MTA

That doesn't make sense in the case of cron because it doesn't have an MTA component.  It invokes a local MTA.

> people generally do not know what that is.

I think it's best to have an example.  "cron" seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one.  If not, changing 'such as "cron"' to 'such as the "cron" UNIX utility' seems a better change to me.

>     verifier:  Any agent that conducts DKIM signature validation and perhaps

The verifier does not do both.  An external module deals with ADSP and "trust" or other evaluation of the delivered domain name.

I would be fine with changing "analysis" to "validation" though, to make that clear.

>        Mail Delivery Agent (MDA).

Works for me.

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 15 May 2011 13:04:05 -0400

> I think it's best to have an example.  "cron" seems to be an ideal one, though I'd be happy to add a second, Windows-specific, example if there is one.  If not, changing 'such as "cron"' to 'such a…

Anyone who's ever managed a Unix or linux system knows what cron is. 
It's a fine example.

Indeed, on my own servers, there are cron scripts that push out daily 
digests which are DKIM signed on the way out.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Sun, 15 May 2011 12:51:24 -0500

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 May 2011 15:04:51 -0400

Murray S. Kucherawy wrote:

> It's a daemon that runs on UNIX systems which can be told to 
> run specific programs at specific periodic times.  It is neither an 
> MTA nor an MUA; it is an example of something that is an "author" in 
> this context but is not also a human.

It was a rhetorical question.  I don't think its necessary and IMO, 
unprecedented.

> That doesn't make sense in the case of cron because it doesn't 
> have an MTA component.  It invokes a local MTA.

Exactly my point Murray. For the level of knowledge this document 
needs, people are presumed to be aware what is a MUA, MSA, MTA, MDA 
and how they are used and invoked is independence of specific OS details.

> I think it's best to have an example.  "cron" seems to be an 
> ideal one, though I'd be happy to add a second, Windows-specific, 
> example if there is one.  If not, changing 'such as "cron"' to 'such 
> as the "cron" UNIX utility' seems a better change to me.

In principle, examples are good, but IMO this particular one seems out 
of place. Think in terms of the context of where it is applied to author:

If the intent is to suggest to the readers there is something special 
"cron" when it comes to the author, i.e. may not be real author or not 
exist, then I can see it may apply. Bu I don't think that is what you 
were trying to say here.

I think what you are essentially saying here is the distinction
between a Human (UI) Agent and Automated (no UI) Mail Agent. So
perhaps the last sentence could be restated :

       The author can be a human using an MUA (Mail User Agent) or
       an automated mail robot with an MTA.

I just think for this MLM I-D which already requires a high-level of 
intelligence, makes that part unnecessary. Perhaps you can also state 
also like you did with originator (and may for verifier):

    author: The agent that provided the content of the message being
       sent through the system.  The author delivers that content to the
       originator in order to begin a message's journey to its intended
       final recipients.  This authoring process is often referred to as
       the Mail User Agent (MUA) or MTA sending mail to the MSA or MDA.

Anyway, its a nit and just thought it was not necessary nor correctly
applied here.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 15 May 2011 22:42:30 -0400

>>> the MSA?  is cron an MTA or MUA?
...
> It was a rhetorical question.  I don't think its necessary and IMO,

I'd be very surprised to find that mention of "cron" in an RFC is
"unprecedented".  Maybe I'll download the RFC set, have Google do a
word index on it, and see.

In any case, I think it *is* useful, and should stay.

> of place.

I think it's not at all out of place, and that it's an excellent
example, because it's frequently used to send automated messages based
on system events and state.  Which might be signed, and which
sometimes go to mailing lists.

>       an automated mail robot with an MTA.

I don't see that "automated mail robot with an MTA" is right at all.
But I see what you're getting at, and I'd support a change such as
this:

       The author can be a human using an MUA (Mail User Agent) or
       an automated process that may send mail (for example, the "cron"
       Unix system utility).

Barry

---

From: "John R. Levine" <[email-masked]>
Date: 15 May 2011 23:09:24 -0400

> word index on it, and see.

RFCs 2123, 2839, 4833, and 5427 refer to cron and cron jobs.  There may be 
others, but I found those with a simple grep.  (If anyone was planning to 
ask what grep is, don't.)

>       an automated process that may send mail (for example, the "cron"

There's no need to change the current language.  RFCs have been referring 
to cron jobs since 1997.

R's,
John

---

From: SM <[email-masked]>
Date: Sun, 15 May 2011 20:12:57 -0700

Hi Barry,
>word index on it, and see.

 From RFC 3834:

   "The auto-generated keyword:

    -  SHOULD be used on messages generated by automatic (often periodic)
       processes (such as UNIX "cron jobs") which are not direct
       responses to other messages"

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 May 2011 23:48:26 -0400

Barry Leiba wrote:
>> It was a rhetorical question. �I don't think its necessary and IMO,
>> unprecedented.
> 

What did you find?

It is unprecedented to see such specific product or special tools like 
this for general "global" oriented technical documents like protocols 
or mail software based RFCs, and if so, it a good and "fair" document 
would cover all audiences, not just unix.  Unless the RFC is 
specifically for some environment, it would be unprecedented  for a 
document like this MLM I-D.

But thats me, it would be my style to consider the whole and not just 
the part of it.  Like the first google search:

http://www.google.com/search?hl=en&rlz=1C1CHMG_enUS291US310&q=cron+RFC+IETF&aq=f&aqi=&aql=&oq=

with RFC3164 showing cron/at.

>  � � � The author can be a human using an MUA (Mail User Agent) or
>  � � � an automated process that may send mail (for example, the "cron"
>        Unix system utility).
> 

I was hoping to use something more general, like automated process, 
but somehow got lost in this need to specialize (hmmm, maybe they will 
like the word mailbot).

I still fail to see how "cron" is related to mail? its a scheduling 
tool, like "at" in Windows.  At least show both. But I still fail to 
see why here, for author, and nothing else.  In theory the same 
"scheduling" idea applies to verifiers and/or signers, i.e. scheduled 
a process/thread to eyeball queues to batch sign and/or verify mail. 
We can also do event drive work that runs spawns processes/threads to 
process mail queues.  Talk about slippery slopes.  Anywho, I just 
don't get it. Very different mindsets/thinking here. But hey, if 
people think it helps unix people....

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 May 2011 23:53:57 -0400

John R. Levine wrote:
> 
> There's no need to change the current language.  RFCs have been 
> referring to cron jobs since 1997.

But this is 2011 for G-d sake!

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 May 2011 00:04:44 -0400

>        responses to other messages"

But its not directly related to MAIL - its for scheduling automatic 
jobs, and the above case "Often Periodic."  That has nothing to do 
with mail per see or the Mail AUTHOR as the MLM I-D sentence implies:

     The author can be a human using an MUA (Mail
     User Agent) or a common system utility such as "cron", etc.

This is not correct. The author is not a "common system utility" or 
anything close to the scheduling tool unless you are saying the 
RFC5322 author is also the OS logged in username which "cron" uses as 
a default as an environment variable for any mail scripting events.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 15 May 2011 21:09:51 -0700

> Sent: Sunday, May 15, 2011 9:05 PM
> To: SM
> Cc: Barry Leiba; [email-masked]

"cron" sends mail, if the periodic job it executes has any output, to the user that requested the job.  The UNIX "at" utility is the same.

The job it executes might also send mail of its own accord.

In both cases, there's mail generated by a non-human author.

> a default as an environment variable for any mail scripting events.

Precisely.

---

From: Hector Santos <[email-masked]>
Date: Mon, 16 May 2011 00:31:03 -0400

> "cron" sends mail, if the periodic job it executes has any output, 
> to the user that requested the job.  The UNIX "at" utility is the same.
> 

All scheduling tools have a mail component, but why not say "such as 
php, perl, etc" like any other tool or language, at least these are 
portable tools and more universal than "cron"

>> a default as an environment variable for any mail scripting events.

But you didn't say that.  You didn't say "or any automated mail 
sending tool where the author is used for sending mail to an originator."

Do you hate windows or know that Windows is still a major OS? or that 
even other OSes may exist with the same "scheduling tools" ideas?  MLM 
is not exclusive to Unix systems.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 16 May 2011 11:14:15 +0200

>        an automated mail robot with an MTA.

Both the human and the robot use an MTA (or an MSA.)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 16 May 2011 08:22:26 -0400

>> on another future 'policy' document.

-1

RFC 5617 has a perfectly good definition of discardable:

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

I realize there are people who wish it meant something else, typically 
simultaneously saying "this mail is very important" and "throw this mail 
away", which is absurd, or perhaps "if there's no signature, handle it 
based on some complicated set of instructions of no benefit to the 
receiver, even though the apparent sender probably isn't the actual 
sender, because the message is so very important".

The definition in the RFC was hammered out after a great deal of debate, 
and I see no evidence that the definition is defective.  ADSP has plenty 
of problems, but the definition of discardable isn't one of them.

Regards,

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 16 May 2011 07:34:54 -0500

+1

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 May 2011 09:03:08 -0400

...
> and I see no evidence that the definition is defective.

+1 to the -1.

d/

-- 

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

---

From: "Mark Delany" <[email-masked]>
Date: 16 May 2011 06:51:04 -0700

> >       an automated process that may send mail (for example, the "cron"

I've got a few of these left so I may as well use 'em while I have 'em.

+1.

Mark.

---

From: SM <[email-masked]>
Date: Mon, 16 May 2011 06:27:09 -0700

>away", which is absurd, or perhaps "if there's no signature, handle it

Yes.

>of problems, but the definition of discardable isn't one of them.

I don't see any value in reopening a discussion about the definition.

Regards,
-sm

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 16 May 2011 11:37:31 -0400

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of SM
> Sent: Monday, May 16, 2011 9:27 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] discardable, was Last Call: <draft-ietf-dkim-
> mailinglists-10.txt> (DKIM And Mailing Lists) to BCP
> 

+1

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 May 2011 10:51:03 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Monday, May 16, 2011 5:35 AM
> To: IETF list; DKIM List

Works for me.

---

From: "John R. Levine" <[email-masked]>
Date: 21 May 2011 18:43:46 -0400

>   2. Should this be Informational or BCP?
>      a: BCP, making it clear when we're insufficiently certain about something.
>         Last Call will sort out any objections.

Well, I couldn't afford to go, so I can't say you're wrong, and I don't 
know why I didn't see that on the list.

I guess on procedural grounds, you win, even though we all know that 
there's nothing B or C about this document.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 21 May 2011 17:59:55 -0400

> As chair, I can say that consensus was to make this normative, not experimental.

With the best will in the world, I was there, and I saw no such consensus.

The closest thing I can find in a quick search of the archive is this 
note, which says that the group agreed on one thing (that lists should 
sign their mail) but not on anything else:

http://mipassoc.org/pipermail/ietf-dkim/2010q4/014630.html

This document does not describe existing signing practice.  It makes a 
variety of highly speculative recommendations unsupported by experience. 
It is an experiment.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Sat, 21 May 2011 18:22:26 -0400

> With the best will in the world, I was there, and I saw no such consensus.

We discussed it live at IETF 80, and I posted the following minutes to
the mailing list on 28 March:

3. Discussion of mailinglists document:
Murray listed some questions he has...
   1. Should we include an appendix discussing what we see as useful
changes to MUAs?
      a: No; out of scope.  Perhaps an MUA BCP done at another time.
   2. Should this be Informational or BCP?
      a: BCP, making it clear when we're insufficiently certain about something.
         Last Call will sort out any objections.
   3. Should we remove discussion about dealing with broken DKIM
implementations?
      a: No.
   4. Should we put advice in about what header fields re-signing MLMs
should sign?
      a: No.
   5. Should explicitly reference ESPs?  They're different from MLMs.
      a: No.
   6. Should we change advice about subdomains, creating "streams"?
      a: No.

That reflects strong consensus in the room in Prague, and there was no
objection on the mailing list after the minutes were posted.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sat, 21 May 2011 17:18:40 -0400

On Thu, May 12, 2011 at 8:38 PM, John Levine <[email-masked]> wrote:
> I'd suggest publishing it as Informational or Experimental rather than
> BCP.

As DKIM chair, I'd like to reply to this and other messages in this
thread that discuss the status of the subject document:

There was extensive discussion in the DKIM working group about what
the status here should be.  The charter item covering this is here:
  5. Consider issues related to mailing lists, beyond what is
  already documented. This includes considerations for mailing
  list software that supports or intends to support DKIM, as well
  as considerations for DKIM/ADSP deployment in the presence of
  mailing lists that do not have such support. Include
  recommendations in the informational documents, or produce a
  new informational document about mailing-list considerations.

Despite that this says "new informational document", the working group
has long referred to it as "the mailing list BCP".  The language was
originally written as informational, and was changed to normative
language, and BCP status, after discussion and consensus.  Clearly, it
was rough consensus, not unanimity.

There is, indeed, much in the document that isn't so much "current
practice" as "recommended practice".  Some of it is our best current
recommendation, and that might change over time (as implementations
change in general) and experience (as we find what actually works
best).

Personally, I think what this amounts to is a "proposed standard" for
how to deal with maling list managers that have not yet been changed
to support DKIM.  Whether that is published as BCP or Proposed
Standard, it's definitely not "experimenta" so much as "proposed".

Barry, DKIM working group chair
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked]
Date: Sun, 22 May 2011 15:59:10 -0700 (PDT)

> there's nothing B or C about this document.

I cannot comment on the process issues, but I'm afraid I have to agree with
John's technical assessment of this document.

				Ned

---

From: SM <[email-masked]>
Date: Mon, 23 May 2011 15:06:01 -0700

At 11:03 23-05-2011, Dave CROCKER wrote:
>Then you are using criteria that go beyond the requirements of a BCP.
>
> From RFC 2026:
>
>    "5.  BEST CURRENT PRACTICE (BCP) RFCs
>
>         The BCP subseries of the RFC series is designed to be a way to
>         standardize practices and the results of community deliberations.
>         ...
>         The BCP subseries creates a smoothly
>         structured way for these management entities to insert proposals into
>         the consensus-building machinery of the IETF while gauging the
>         community's view of that issue."
>
>Nothing in the definition of BCPs require that it be limited to 
>covering existing practice.

This creates debates along the lines of "the RFC says so" or "the 
IETF says that this should be the practice".

>Perhaps the wording is a bit more coarse than one would like, but at 
>base, "telling the community what to do" is what standards-track and 
>BCP documents do, whether based on existing practice or not.

A RFC is a way of telling the community what you did and how you did 
it.  If people believes it is a good idea, they will pick it up.

I'll diverge from the topic.  Let's say that you are writing a 
proposal and there is a controversial issue.  You are technically 
correct in your arguments but there are several people who disagrees 
with you on the issue.  Your options are:

  (i)  Don't make a change (assuming the IESG is fine with that)

  (ii) Make a change to gain goodwill (they will implement your proposal)

I leave it to the IETF to determine which option to pick.

>Not really.  The latter paragraph merely notes that there are 
>receivers that do not understand what a DKIM signature means.

I'll stick to my previous comments on this to avoid further 
distractions to the draft.

>You country has one of those, too?

No, but I came across abuse reports where the people mentions that 
they will contact one of those about the matter. :-)

>Again, we seem to have an attempt to impose a more stringent 
>requirement on qualifying for BCP status than exists in IETF formal 
>documentation.

At 11:43 23-05-2011, John Levine wrote:
>But since this argument seems to be all about proving that we've
>followed the official process rather than about publishing something
>accurate and useful rather than speculative and misleading, who cares?
>Now that I understand the rules, I plan to publish all of my
>experiments as BCPs.

One little gem from an I-D which will be published as a BCP is that 
the information is intended to reflect "consensus on the ground".  A 
RFC is not worth a pinch of salt if it override that.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Mon, 23 May 2011 19:46:24 -0400

Dave CROCKER wrote:
?> In Section 5.8:
> Not really.  The latter paragraph merely notes that there are receivers 
> that do not understand what a DKIM signature means.

Something is amiss if after 6 years of development, after countless 
repeated explanations and messages over the years, it still seems very 
a difficult feat to describe in one or two sentences to the layman 
what DKIM is suppose to do for them, today or in the some distance future.

The fact is DKIM has many conflictive semantics.  While the above says 
its out of scope, it says the opposite in RFC 46751bis 6.3:

    Once the signature has been verified, that information MUST be
    conveyed to the Identity Assessor (such as an explicit allow/
    whitelist and reputation system) and/or to the end user.  If the SDID
    is not the same as the address in the From: header field, the mail
    system SHOULD take pains to ensure that the actual SDID is clear to
    the reader.

See the SHOULD? See the technical association highlighted between the 
signer domain (SDID) and the the originating, copyright holder/author 
of the Message?

Now, look at the conflict in the Abstract and repeated again in 
Section 1.2 defining the Signing Identity:

    DKIM separates the question of the identity of the signer of the
    message from the purported author of the message.

What question is that?  RFC4871 never quite clearly defined thee 
"question."

Lets think about what that question may be. Answer this:

     Do Electronic Mail Author Domains have any security
     rights and controls over who DKIM signs their mail?

Be nice for someone to answer that question.

Then of course, we have augmented RFC productions, such as RFC5585 
that describes the "DKIM Service Architecture" and the illustration 
has that Author Domain "Checking Signing Practices" process component 
displayed in the diagram:

                              |- RFC5322 Message
                              V
+--------+    +--------------------------------+
| Private|    |  ORIGINATING OR RELAYING ADMD  |
| Key    +...>|  Sign Message with SDID        |
| Store  |    +---------------+----------------+
+--------+                    |
  (paired)                 [Internet]
+--------+                    |                     +-----------+
| Public |    +--------------------------------+    | Remote    |
| Key    |    |  RELAYING OR DELIVERING ADMD   |    | Sender    |
| Store  |    |  Message Signed?               |    | Practices |
+----+---+    +-----+--------------------+-----+    +-----+-----+
      .              |yes                 |no              .
      .              V                    |                .
      .        +-------------+            |                .
      +.......>|  Verify     +--------+   |                .
               |  Signature  |        |   |                .
               +------+------+        |   |                .
                  pass|           fail|   |                .
                      V               |   |                .
               +-------------+        |   |                .
               |             |        |   |                .
      +.......>| Assessments |        |   |                .
      .        |             |        V   V                .
      .        +-----+--+----+      +-------+              .
      .              |  |          / Check   \<............+
      .              |  +-------->/  Signing  \
      .              |           /   Practices \<..........+
      .              |          +-------+-------+          .
      .              |                  |                  .
      .              |                  V                  .
+----+--------+     |            +-----------+     +------+-----+
|Reputation/  |     |            | Message   |     | Local Info |
|Accreditation|     +----------->| Filtering |     | on Sender  |
|Info         |                  | Engine    |     | Practices  |
+-------------+                  +-----------+     +------------+

                Figure 1: DKIM Service Architecture

Then you have the RFC5863 Development guide with a few dedicated 
sections, but not the only sections:

     7.3.  Author Domain Signing Practices
     7.3.2.  A Few Definitions
     7.3.3.  Some ADSP Examples

Then finally, you have the crux of the problem with this RFC5017 
section 5.3 item #10 statement:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

So on the one hand you have functional specifications across multiple 
RFC which  recommends receivers to honor author domain signing 
practices as a security measure to help product DKIM domains, but then 
we have miscellaneous peppered injections of statement that conflicts 
with these goals by telling receivers they MUST (not a MAY) to mind 
their own bee's wax if they see an unexpected, unsolicited, unknown, 
unauthorized non-first party DKIM signed mail when the author domain 
may have a policy that says "Thats a NO NO"

Dave, you got receivers all twisted up in knots!