Subject: [ietf-dkim] Practices protocol naming poll (Closing issue 1550)

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Mar 2008 09:02:55 +0000

Poll ends: April 3rd AoE (*)

Please mail the list with your preferences.
Tick the box for any of the name options you like.
You can pick more than one option.
If you change the subject line or mess with the
body of the mail, I may miss or miscount your
opinion, so don't do that.

[ ] ADSP - Administrative Domain Signing Practices (**)
[ ] ADSP - Author Domain Signing Practices
[ ] ASP - Author Signing Practices
[ ] FroDo - From Domain Signing Practices
[ ] SPAD - Signing Practices of Author Domains
[ ] SSP - Sender Signing Practices

(*) AoE = "Anywhere on Earth" (http://wirelessman.org/aoe.html) a
slightly silly, but I guess useful idea here.
(**) The word "Policy" was used when this was suggested, but I
think we do have consensus to prefer "Practice" instead, so I
made that change.

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 20 Mar 2008 12:10:01 +0100

[ ] ADSP - Administrative Domain Signing Practices (**)
[x] ADSP - Author Domain Signing Practices
[ ] ASP - Author Signing Practices
[x] FroDo - From Domain Signing Practices
[x] SPAD - Signing Practices of Author Domains
[ ] SSP - Sender Signing Practices

---

From: [email-masked] (Wietse Venema)
Date: Thu, 20 Mar 2008 07:22:54 -0400 (EDT)

Stephen Farrell:
> [X] ADSP - Author Domain Signing Practices

---

From: Tony Hansen <[email-masked]>
Date: Thu, 20 Mar 2008 08:30:28 -0400

> [X] ADSP - Administrative Domain Signing Practices (**)
> [X] FroDo - From Domain Signing Practices
> [X] SPAD - Signing Practices of Author Domains

in other words, any of the above that include the word "domain"

	Tony Hansen
	[email-masked]

---

From: John Levine <[email-masked]>
Date: 20 Mar 2008 13:05:12 -0000

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 20 Mar 2008 10:45:06 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Stephen Farrell
> 

Preference for A(uthor)DSP, FroDo or SPAD also acceptable.

---

From: Eric Allman <[email-masked]>
Date: Thu, 20 Mar 2008 07:33:42 -0700

eric

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Mar 2008 08:36:01 -0700

On Mar 20, 2008, at 2:02 AM, Stephen Farrell wrote:
> [x] ADSP - Administrative Domain Signing Practices (**)

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 20 Mar 2008 14:57:09 -0000

-- 
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: Hector Santos <[email-masked]>
Date: Thu, 20 Mar 2008 12:02:35 -0400

Stephen Farrell wrote:

> [X] SSP - Sender Signing Practices

What can you say? I have a thing for minorities.

-- 
Sincerely

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

---

From: "Nick Edwards" <[email-masked]>
Date: Thu, 20 Mar 2008 08:30:24 -0700

I vote for retaining SSP.  The challenges this group is tackling are
complex enough, I'd hate to confuse the industry further.  

Nick

IronPort Systems

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Allman
Sent: Thursday, March 20, 2008 7:34 AM
To: Stephen Farrell; ietf-dkim
Subject: Re: [ietf-dkim] Practices protocol naming poll (Closing issue
1550)

eric

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 20 Mar 2008 16:52:33 +0200

> [ ] SSP - Sender Signing Practices

in other words, those I found pronouncable :-)

Best regards,
Pasi

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Mar 2008 09:15:29 -0700

-- 

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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 20 Mar 2008 09:22:52 -0700

> [ ] SSP - Sender Signing Practices
-Jim

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 20 Mar 2008 08:42:39 -0700

[1] ADSP - Administrative Domain Signing Practices (**)
[2] ADSP - Author Domain Signing Practices
[3] ASP - Author Signing Practices
[ ] FroDo - From Domain Signing Practices
[ ] SPAD - Signing Practices of Author Domains
[ ] SSP - Sender Signing Practices

I object to FroDo as a potential and unnecessary trademark issue with parties that have a history of litigation and indeed are currently in litigation between themselves.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 20 Mar 2008 17:44:17 -0000

>I object to FroDo as a potential and unnecessary trademark issue with
>parties that have a history of litigation and indeed are currently in
>litigation between themselves.

You may be confusing trademark and copyright.

A quick search at the USPTO shows trademark registrations for FRODO
for alcoholic beverages, snacks (pizza in particular), key chains, and
action figures.  I see no trademarks related to computers.

There are trademarks on SSP for fire extinguishers, offshore floating
platforms, sports equipment, lubricating oils, air filters, insurance
claims software, web based online insurance claim processing, medical
needles, shaft pulleys, contract food services and food service
management, marine propulsion motors, computer chips with embedded
software for secure data transmission over a global computer network,
gold jewelry, steam engineering services, specialized motors,
packaging foam, battery chargers, and pipe fittings.

There is only one trademark on ADSP for radio transceivers.

I would consider staying away from SSP due to that trademark on data
transmission security chips, but it's hard to see how it would be an
issue for FRODO or ADSP.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Mar 2008 10:56:12 -0700

> You may be confusing trademark and copyright.

Besides that, why should we worry about colliding a name with a C64 emulator?

   <http://frodo.cebix.net/>.

Nevermind, that collision requires functional overlap.

d/

-- 

   Dave Crocker

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 20 Mar 2008 12:05:12 -0700

I am considerably more worried about the threat of a lawsuit than actual liability.

I have spent rather more defending cases I have 'won' than I have ever lost. 

-----Original Message-----
From: John Levine [mailto:[email-masked]]
Sent: Thu 20/03/2008 1:44 PM
To: [email-masked]
Cc: Hallam-Baker, Phillip
Subject: Re: [ietf-dkim] Practices protocol naming poll (Closing issue 1550)

R's,
John

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 20 Mar 2008 14:12:32 -0500

Arvel

---

From: SM <[email-masked]>
Date: Thu, 20 Mar 2008 13:36:23 -0700

>[ ] SSP - Sender Signing Practices

Regards,
-sm

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 20 Mar 2008 18:35:55 -0400

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, March 20, 2008 5:03 AM
To: ietf-dkim
Subject: [ietf-dkim] Practices protocol naming poll (Closing issue 1550)

[*] ADSP - Administrative Domain Signing Practices (**)

---

From: Sandy Wills <[email-masked]>
Date: Thu, 20 Mar 2008 20:40:47 -0400

> [X] SSP - Sender Signing Practices

   A particular internet message may have 17 people all claiming to be 
"author", and we may not be able to determine who actually wrote it (who 
or where the message is really "from"), but it was created as an SMTP 
message somewhere, and, after many steps it got released into the wild 
and sent to my incoming server by an unknown box or process.  I can 
reasonably call that box or process the "sender".  That box/process 
claims to provide outgoing mail services for a particular domain, 
sub-domain, or entity.  It may or may not be who or what it claims to be.
   All I want here is to know if my message really came from the claimed 
domain.   Yes, that's a complicated question, but this domain has a DNS 
record to help me make that decision.  Why not call that record by a 
name that includes some form of the word "Send"?
   I'd also like to see the words "Domain", "Message" and "Policy" but 
I'll settle for "Sender Signing Practices" if that makes everyone else 
happy.

   It may be that, even after following this mailing list for two years, 
I simply don't understand the question....

-- 
Unable to locate coffee.
Operator halted.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Mar 2008 19:27:43 -0700

Sandy Wills wrote:
> reasonably call that box or process the "sender".

A message has 7 sources of information that are variously referred to as 
describing where a message came "from".  One of those sources (rfc2822.Received) 
can be repeated and one (rfc2822.from) may have multiple values.

Exactly which value of exactly which field or command are you referring to?

And how does your desire related to the current *SP specification, which 
explicitly calls for using the value(s) in the rfc2822.From field?

> I'll settle for "Sender Signing Practices" if that makes everyone else 

Since the word "sender" is demonstrably ambiguous, why do you prefer it?

d/
-- 

   Dave Crocker

---

From: Sandy Wills <[email-masked]>
Date: Thu, 20 Mar 2008 23:22:24 -0400

> explicitly calls for using the value(s) in the rfc2822.From field?

I don't see how we can get a useful check from this header line:

From: [email-masked], [email-masked], [email-masked], [email-masked]

   There's been a lot of bandwidth invested in discussion of which 
address is "right".  First?  Last?  There's no clear best answer, which 
means there's no _right_ answer that can be put in a spec and used.  Any 
decision made by us will be capricious and without basis, and will be 
screwed up by the first email user to forget to put his boss's name first.

But we may get something useful from:

Sender: [email-masked]

which is required if From: has more than one item.

   An implementation of SSP can start with a check for Sender: simply 
because if it exists, that's the sender.  One test and it's done.  Only 
if that check fails would it look at From: and use the 
by-definition-only-one sender found there.  In the worst case, it makes 
two tests and it's done.
   Looking at From: first seems to be slightly more complicated, to me. 
  Look for a From: address, good, look for another.  If none, that's it. 
  If another found, then throw that away and look for a Sender: address. 
  Always at least two looks, and sometimes three.

> Since the word "sender" is demonstrably ambiguous, why do you prefer it?

I see no ambiguity in rfc2822 section 3.6.2. Originator fields, which I 
paraphrase here:

    If there is only one "From" address, that's the sender.  If there is 
more than one address in the "From" field, creating ambiguity on who 
it's from, then there will be a separate field "Sender" who is the sender.

   No room for confusion here.  I know that you know 2822 better than I 
do, so I'm not sure I understand your question.
   Can you explain to me where you find the term "Sender" ambiguous? 
Would you prefer the term "Originator", which means the same thing but 
takes longer to say and type?  When two ways of saying something appear 
equivalent, I prefer the more common/simpler/shorter way.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 20 Mar 2008 20:31:56 -0700

>  Always at least two looks, and sometimes three.

SSP has one, and only one, reason for existence. That is to
protect the domain displayed to the user in the From: field, as
Dave notes above.

Given that, any discussion of looking at the Sender: field is
pretty pointless.

Were you discussing any other sort of domain protection I'd
likely agree with you that the Sender field is relevant, especially
in the almost unheard of case of multiple entries in the From:
field, but SSP is solely intended to protect the string displayed to
the user. And that's the From field (with a partial exception for an
obscure MUA from Redmond). Looking at Sender: is out of scope.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Mar 2008 20:34:41 -0700

> From: [email-masked], [email-masked], [email-masked], [email-masked]

The efficacy of the current specification is a continuing question among many
folk.  Nonetheless, the From field is what it specifies.

And it seems that your concern relates to some other source of information. 
Hence, not this specification.

The question issues by the Chairs is about naming of the current specification, 
not some other possible spec.

> An implementation of SSP can start with a check for Sender: simply because if
>  it exists, that's the sender.  One test and it's done.  Only if that check 

And your preference for SSP remains a bit confusing, since that name has only 
ever been applied to a version of the current specification and, hence, only to 
using a value from the rfc2822.From field.

> If there is only one "From" address, that's the sender.  If there is more 
> than one address in the "From" field, creating ambiguity on who it's from, 
> then there will be a separate field "Sender" who is the sender.

The word "Originator" refers to the combination of RFC2822 fields:  From, 
Sender, and Reply-to.  That's 3 fields.

> No room for confusion here.  I know that you know 2822 better than I do, so 
> I'm not sure I understand your question. Can you explain to me where you find
>  the term "Sender" ambiguous? Would you prefer the term "Originator", which 
> means the same thing but takes longer to say and type?  When two ways of 
> saying something appear equivalent, I prefer the more common/simpler/shorter 
> way.

The word you are using is neither Originator nor From.

But that's not the word you are using. It's "sender".

hat term is commonly used for values ranging across  rfc2822.From, 
rfc2822.Sender, rfc2821.Received, rfc2821.MailFrom, rfc2821.Helo/Ehlo, and 
client SMTP IP Address.

That rates as ambiguous.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 21 Mar 2008 0:06:05 -0400

>  Always at least two looks, and sometimes three.

And Sender is quite often (usually AFAIK) not displayed to the end user.  
Once we're in the land of largely invisible header fields, there of no 
ability to reliably sort out mail that is spoofed from a particular domain. 
 Why not include resent-* too.

Unless the protocol is tied to From, it's essentially valueless from my 
perspective.  There is not a solution that is both pretty and useful.  Pick 
one.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Mar 2008 22:17:00 -0700

On Mar 20, 2008, at 9:06 PM, Scott Kitterman wrote:

> And Sender is quite often (usually AFAIK) not displayed to the end  
> user.  Once we're in the land of largely invisible header fields,  
> there of no ability to reliably sort out mail that is spoofed from a  
> particular domain. Why not include resent-* too.

For this statement to be correct, it might depend on being based upon  
the distribution of MUAs and not the number of recipients.  Many  
recipients will see the From header as a composite of Sender and From  
headers when the Sender header is present.

> Unless the protocol is tied to From, it's essentially valueless from  
> my perspective.  There is not a solution that is both pretty and  
> useful.  Pick one.

A signature must include the From header within its hash.  When the  
signature has been created by the domain seen in the From header email- 
address, but perhaps on behalf of a different identity, such as the  
identity within the Sender header (both sharing the same domain), the  
message should be considered complaint with the From (author's)  
signing _domain's_ policies.  An exception should be made when a key  
restricts the local-part of an email-address and this identity is not  
within the From header.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Mar 2008 13:05:57 +0000

Do me a favour and change the subject line,
Thanks,
Stephen.

---

From: John Levine <[email-masked]>
Date: 21 Mar 2008 13:59:25 -0000

Unless I'm missing something, this is a rehash of an argument which
we've already debated at length and settled.  Unless someone else
thinks it's worth reopening as an issue, perhaps we could just stop.

> ...

---

From: "J D Falk" <[email-masked]>
Date: Tue, 25 Mar 2008 13:59:00 -0400

> [X] ASP - Author Signing Practices\

But mostly, I want to see this issue closed so I can start telling
people what A(D)SP is /for/ rather than what it's likely to be called.

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 28 Mar 2008 16:57:00 +0000

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

---

From: Jon Callas <[email-masked]>
Date: Fri, 28 Mar 2008 13:18:47 -0700

[*] FroDo - From Domain Signing Practices