Subject: [ietf-dkim] I-D ACTION:draft-ietf-dkim-base-08.txt

From: [email-masked]
Date: Fri, 19 Jan 2007 18:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

	Title		: DomainKeys Identified Mail (DKIM) Signatures
	Author(s)	: E. Allman, et al.
	Filename	: draft-ietf-dkim-base-08.txt
	Pages		: 80
	Date		: 2007-1-19
	
DomainKeys Identified Mail (DKIM) defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology to permit verification of the source and
   contents of messages by either Mail Transfer Agents (MTAs) or Mail
   User Agents (MUAs).  The ultimate goal of this framework is to permit
   a signing domain to assert responsibility for a message, thus
   protecting message signer identity and the integrity of the messages
   they convey while retaining the functionality of Internet email as it
   is known today.  Protection of email identity may assist in the
   global control of "spam" and "phishing".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dkim-base-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dkim-base-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 20 Jan 2007 03:59:33 +0100

>         Filename        : draft-ietf-dkim-base-08.txt

Observations in addition to "example.edu":

- [RFC-DK]  Is that ready for publication ?  I don't get
  what the I-D tracker page actually says, is it approved ?

- 8.1.1 s/displaying MTA/displaying MUA/

- 7.9 
  s/Permanent Header Messages/Permanent Header Fields [RFC 3864]/
  and add [RFC 3864] to the informative references, see also
  <http://permalink.gmane.org/gmane.ietf.message-headers/33>

- 7
  s/Standards Track RFCs/any published RFCs/  Otherwise the
  following sections make no sense.  The clause "approved by
  the IESG" should be removed.  The RFC-editor is obliged to
  ask the IESG for comments in the case of any "independent"
  submissions. 

- 6.3
  "SHOULD NOT reject" because that "could cause severe  
  interoperability problems" is plain nonsense.  Accepting
  mail tagged as "suspicious" will cause severe problems 
  because tagged mail will be most likely deleted without
  further checks later.  OTOH "reject" is a clean decision
  at the border MX.

Frank

---

From: Eric Allman <[email-masked]>
Date: Thu, 25 Jan 2007 14:19:43 -0800

>   what the I-D tracker page actually says, is it approved ?

My understanding is that it will be published at the same time as 
DKIM-base.

> - 8.1.1 s/displaying MTA/displaying MUA/

Thanks.

>   <http://permalink.gmane.org/gmane.ietf.message-headers/33>

Good idea.

>   ask the IESG for comments in the case of any "independent"

There is obviously substantial consensus on this, so the change is in.

>   further checks later.  OTOH "reject" is a clean decision

I think this one requires further discussion before I can change it. 
This has been in pretty much since the beginning, and it's come up in 
discussions several times, and so far as I can recall you're the 
first one to disagree with it.  That could be because no one has 
thought about it before, or could be because the WG feels it should 
remain as-is.

eric

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Jan 2007 17:43:41 -0500

> thought about it before, or could be because the WG feels it should
I'm glad Frank brought this up.  I think he is completely correct.  Reject 
gives clear feedback to the sender.  Filtering into never reviewed spam 
buckets or even dropping mail does cause severe interoperability problems on 
an ongoing basis.  Let's not have more of it.

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 26 Jan 2007 15:18:33 +0100

> Good idea.

Thanks.  I'm still trying to convince IANA that they need to update
their Web pages for the header registry, and apparently IANA still
tries to convince the IESG that they need to appoint an expert for
the message header field review list, so it's not yet hopeless. ;->

 [SHOULD NOT reject]
> This has been in pretty much since the beginning

Sorry, I saw it in an rfcdiff, but the diffs for chapters 4 up to 8
are a bit confusing.

> That could be because no one has thought about it before

In my case IIRC "hasn't noted it before".

BTW, in a similar direction, do you intentionally use [SHA] without
(or instead of) [RFC 4634] as normative reference for SHA-256 ?

RFC 4634 also covers SHA-1.  If you don't list RFC 4634 because the
license isn't exactly clear then RFC 3174 could do for SHA-1.  Both
RFCs are informational, but it's probably already accepted that they
don't need a special "downref" procedure anymore.

Frank

---

From: Eric Allman <[email-masked]>
Date: Fri, 26 Jan 2007 07:20:50 -0800

> In my case IIRC "hasn't noted it before".

So does this mean you're dropping that request, or should it still 
have more WG discussion?

> (or instead of) [RFC 4634] as normative reference for SHA-256 ?

Yes, because it really is normative.

> don't need a special "downref" procedure anymore.

It seems that DKIM is being held to a higher standard than usual. 
Making a normative reference to an informational document is just 
going to create friction, and there seems no obvious reason to do so.

eric

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Jan 2007 00:49:15 +0100

> So does this mean you're dropping that request, or should it
> still have more WG discussion?

When I tried to add an issue in a 2nd WGLC about USEFOR Harald
(one of the Chairs) said that it's my problem if I missed the
1st WGLC, so I think it's a judgement call for the WG Chairs.

Of course I think it's an "ISSUE", but I didn't look at parts
of the draft shown as "unmodified" by rfcdiff.

>> do you intentionally use [SHA] without (or instead of) 
>> [RFC 4634] as normative reference for SHA-256 ?
 
> Yes, because it really is normative.
[...]
> It seems that DKIM is being held to a higher standard than 

Of course, it's highly controversial.  Depending on my mood
I'm still not sure if it's "better" than PRA, or "worse", or
"unrelated".  At least the list of supporters is impressive,
and I hope they'll find _good_ ways to make use of DKIM.

Frank