-1.

In my view any DKIM entity on both sides of the coin, must be consistent in
all expectations.  Verifiers shouldn't be able to do what they please and
you ready dictating policy by the mere suggestion one is not required.

Since the signer already drives the verification process, there is already a
policy in place.  Suggesting the verifier can do what it please, is yet
another ambiguous policy.

IMV, there should be a minimum requirement that has nothing to with
"subjective policies" but part of the fundamental mechanism of the x821/x822
EMAIL process and that includes having such fields as a FROM: (for DKIM
signing).

I suggest that we become consistent with the 20+ year infrastructure where
there is a minimum requirement for headers, and expectations for all parts
of the framework, including display systems.

With RFC 822/821, we have a requirement of FROM: TO: and DATE:

With RFC 2822/2821, it was relaxed to just FROM: and DATE:

I don't see this as a "policy" but just part of the fitting the equation.

Just consider when you don't require atleast the FROM:.  This means we can
have systems creating non-originating (3rd party) DKIM messages with any
FROM address.

Of course, I already felt that signature authorization should be a natural
part of the DKIM protocol since it will help maintain the expectation of the
so called "responsible" signer.  Without signature authorization, dropping
the FROM: hashing is highly vulnerable to exploitation.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



----- Original Message -----
From: "Eric Allman" <[EMAIL PROTECTED]>
To: "IETF DKIM WG" <[email protected]>
Sent: Thursday, July 13, 2006 4:00 PM
Subject: [ietf-dkim] drop requirement to sign "From" or other "originator"
headers?


> I've heard some discussion the last couple of days that we should
> drop the MUST for signing originator headers and Resent-* blocks,
> since this isn't an interoperability issue (but is perhaps a
> usefulness issue).  This is, in some sense, dictating policy instead
> of being confined to mechanism, which we've been assiduously
> avoiding.  Viewed that way, it seems inappropriate to have this
> requirement.
>
> Of course, a verifier would be completely within reason to ignore
> signatures that didn't sign the From header, but that's up to them.
>
> If we can get a very quick consensus I can get this into base-04
> (which is going to be submitted today come hell or high water --- oh
> wait, that was Dallas).  It seems consistent with the other changes
> we've been making, which is why I have some small hope we can get
> this through in just a couple of hours.
>
> Thoughts?
>
> eric
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>


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

Reply via email to