Subject: [ietf-dkim] Possible Signing Practices non-technical terminology

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 12:46:15 -0700

Folks,

As long as I am ranting about the need to non-technical -- that is, functional
-- descriptions of use for records that publish signing practices, I might as
well suggest some (relatively) non-technical terminology to use, so that we have
some consistency:

Author:
     Creates message content

  Mailing-List: Creates message content, based on existing messages

Recipient: End-user who may read the content

Operator:
     Transfers messages

  Author's
       Operator: Controls submission

  Recipient's Operator:
       Controls delivery

Filter:
     Makes contingent handling choices, based on mechanical assessments on a
message and

   Operator's Filter:
        A handling filter employed by an operator.

   Recipient's Filter:
        A handling filter operating in the Recipient's MUA.

Domain:
     Identity cited in a signing practices record

   Author's Domain:
        Identity of the domain in the rfc2822.From field

   Operator's Domain:
        Identity in the rfc2822.Sender field or a Received field.

So, for example, this is a large difference between a practices record that is
set by the author's domain and one that is set by an operator's domain.

Equally, there is a large difference between using practices records for
operator-based filtering than for human recipient decision-making.

d/
-- 

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 31 Jul 2006 13:02:53 -0700 (PDT)

>  Mailing-List: Creates message content, based on existing messages

I have a problem with above line. In my view mail list can not be
considered an author of the message.

> Recipient: End-user who may read the content

Not necessarily an end-user but this is less of an issue.

>     Transfers messages

Most people call it Mail Transfer Agent or just agent although I suppose
you're talking about who controls that agent.

>     Identity cited in a signing practices record

No. Domain is network-based group of users used as a common routing 
element on the network.

The identity is an email. Domain maybe used to identify common
practice for all its user but may just be a routing element used 
when identifying specific user identity policy.

>        Identity in the rfc2822.Sender field or a Received field.

This one is problematic too. While I don't disagree, I think we
need to specify separate Email Origin perator which is the
one that has to do with rfc2822.Sender field. An intermediate
email MTA operator it may add hostname into Received line but
that is not even a domain but a specific host and there is
no requirement for that to happen.

-- 
William Leibzon
Elan Networks
[email-masked]