Subject: [ietf-dkim] draft-ietf-dkim-base-08 submitted

From: Eric Allman <[email-masked]>
Date: Thu, 18 Jan 2007 15:12:04 -0800

I have submitted draft-ietf-dkim-base-08 for publication.  This has 
some significant changes requested by the IESG.  Probably the most 
significant is the addition of section 5.4.1, "Recommended Signature 
Content".  The changes are summarized in Appendix F.1.

  http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-08.txt
  http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-08.html

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Jan 2007 11:57:08 +0000

Thanks Eric,

Eric Allman wrote:
 > I have submitted draft-ietf-dkim-base-08 for publication.  This has some
 > significant changes requested by the IESG.  Probably the most

FYI, the diffs are here [1].
The IESG comments these try to address are here [2].

Stephen.

[1] 
http://tools.ietf.org/rfcdiff?url1=http://www.neophilic.com/~eric/DKIM/draft-ietf-dkim-base-08.txt&url2=http://tools.ietf.org/id/draft-ietf-dkim-base-07.txt
[2] 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14210&rfc_flag=0
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Fri, 19 Jan 2007 09:36:42 -0500

Most of the changes that Eric made should be non-controversial, 
involving clarifications and tweaking that have helped us (the draft 
authors and the working group chairs) explain things to the IESG. 
Regardless, though, of the non-controversial nature of those changes, 
the chairs would like the working group to review the document fully.

The most changes are in two areas:

The security considerations, where some significant changes went in 
after discussion with the Security Directorate.  We hope these fall into 
the "non-controversial" category, and we urge the working group to 
object only with strong reason.

Section 5.4.1, "Recommended Signature Content".  Stephen has posted a 
pointer to the extensive IESG comments, but to summarize: there is 
concern in the IESG that, given no guidance at all, some signers will 
create perfectly compliant signatures that no verifier will accept even 
after verification succeeds, resulting in an interoperability problem. 
The new version of section 5.4.1 is thus attempting to give minimal 
advice, which might be modified by more specific signing policies 
defined later, to alleviate this concern.

Please review and discuss.  The chairs would like the group to complete 
this discussion quickly and efficiently, so that the IESG can send a 
final draft to the RFC editor very soon.  To that end, we're setting the 
discussion period to a week, and we're asking that we keep any 
discussion of the -08 draft tightly on track.  The point here is not to 
rehash anything that's already been discussed, to pick again at anyone's 
pet points, nor to go on about unimportant details.  The point is to 
decide whether with these changes, the document remains a solid protocol 
that has the rough consensus of this community.

As usual, when you start a discussion thread, don't use this subject 
line.  Use something specific to the topic you're discussing.

A week of discussion -- which ends on 26 January... and starts now.

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: <[email-masked]>
Date: Fri, 19 Jan 2007 11:03:05 -0500

On mailing lists,
If I was running one, a submission to the list after satisfying whatever
criteria I use for selection should then be propagated with a single
DKIM signature with the assumption that the list itself is the author of
this single distribution as opposed to re-signing every DKIM signature
that shows up on a submission. It will be reasonably trivial to
implement and make verification much simpler.

Bill Oxley
Messaging Engineer
Cox Communications

---

From: <[email-masked]>
Date: Fri, 19 Jan 2007 10:58:57 -0500

I can live with the proposed changes in this draft as written. 

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Friday, January 19, 2007 9:37 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] draft-ietf-dkim-base-08 submitted

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Jan 2007 16:15:45 +0000

Thanks Bill.

A sequence of +/-1 messages like that might be useful to help Barry
and I assess rough consensus at the roughest level.

(Given that other threads are mostly likely to embody disagreement
with some aspect of the -08 changes.)

S.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Jan 2007 09:59:09 -0800

> > Content".  The changes are summarized in Appendix F.1.

6. Verifier Actions	
				
  Since a signer MAY remove or revoke a public key at any time, it is	
  recommended that verification occur in a timely manner. In many		
  configurations, the most timely place is during acceptance by the	
  border MTA or shortly thereafter. [In particular, deferring			
  verification until the message is accessed by the end user is			
  discouraged.]			

This precaution should be removed!!  When the public key record is  
revoked due to abuse, then not immediately verifying a message offers  
what might be valuable time.  It is also likely the _only_ sure means  
to protect recipients from spoofing is through annotations applied by  
the MUA based upon recipient trusted email-addresses.  Do not forget  
about the EAI changes and the vast range of resulting look-alike  
attacks made possible.

While trust might be established between the MDA and MUA, DKIM does  
not provide a means for making that determination.  Without the  
ability of the MUA to also validate signatures, then any annotations  
applied based upon assumed trust in the MDA and some headers that may  
or may not be added imperils the recipient.  Don't make the mistake  
that sender policy offers a reasonable solution either.  Annotation  
based upon added headers or assumed application of sender policy  
reduces security.  Rather than discouraging deferred verification,  
discourage the rapid removal of keys!  There is an expiry that can be  
applied in lieu of key removal which can be compared against when the  
message was delivered.  There is no valid reason to rapidly remove  
valid keys.

One of the benefits of DKIM is that annotation does not need to rely  
upon headers that may or may not be added by the MDA, which of course  
may or may not be also signed (and for how long?).

-Doug

---

From: <[email-masked]>
Date: Fri, 19 Jan 2007 13:06:49 -0500

I thought this was resolved via an expiration date x= flag. With this
flag set a mua could certainly know whether a signature was still valid
before attempting to verify it.

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Friday, January 19, 2007 12:59 PM
To: Stephen Farrell
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] draft-ietf-dkim-base-08 submitted

6. Verifier Actions	

  discouraged.]			

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Jan 2007 10:23:07 -0800

On Jan 19, 2007, at 10:06 AM, <[email-masked]> wrote:

> I thought this was resolved via an expiration date x= flag. With  
> this flag set a mua could certainly know whether a signature was  
> still valid before attempting to verify it.

The critical element should be whether the message's signature had  
expired prior to delivery, which can be determined by checking when  
the message was received.  This check could be made days later and  
yet safely used to abate abusive replay of messages.  There is no  
need to rapidly remove valid keys and thereby make MUA verification  
precarious.  Retaining public keys for a reasonable period would be a  
reasonable strategy.  Implying that all checking must be done by the  
MTA fails miserably in efforts aimed at protecting recipients.  DKIM  
is not only about ensuring the acceptance of bulk email by the MTA.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 19 Jan 2007 21:37:43 +0100

> FYI, the diffs are here [1].

As soon as -08 is officially available there are also [Diff]
links on <http://tools.ietf.org/html/draft-ietf-dkim-base>

Henrik was at it again - it's not more necessary to create
the monstrous diff-URL "manually"... :-)

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Jan 2007 13:35:15 -0800

At 9:59 AM -0800 1/19/07, Douglas Otis wrote:
>This precaution should be removed!!

I disagree with Doug and agree with the wording in the current document.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Jan 2007 14:16:13 -0800

On Jan 19, 2007, at 1:35 PM, Paul Hoffman wrote:

>>> ...
>>> Since a signer MAY remove or revoke a public key at any time, it  
>>> is  recommended that verification occur in a timely manner. In  
>>> many  configurations, the most timely place is during acceptance  
>>> by the border MTA or shortly thereafter. [In particular,  
>>> deferring verification until the message is accessed by the end  
>>> user is discouraged.]
>>

Paul,

Would you explain the reasoning for discouraging verification at the  
MUA?

When annotations are applied by the MUA based upon email-addresses  
trusted by the recipient (which is how recipients might achieve look- 
alike spoofing protections at no cost), then verification should take  
place at the MUA and not at the MDA.  While DAC listed signing- 
domains might provide a category of annotation that can be applied at  
the MTA, there are many cases where third-party assurance is not  
required for protection to be realized.  Discouraging verification at  
the MUA seems aimed at only permitting third-party assurances as a  
means for annotating messages. : (

What prevents public keys from remaining available for a reasonable  
period to accommodate MUA use?  What annotation criteria can be  
safely applied at the MDA?  How can verification results be safely  
communicated to the MUA for email-address specific annotation?

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Jan 2007 15:29:41 -0800

At 2:16 PM -0800 1/19/07, Douglas Otis wrote:
>Would you explain the reasoning for discouraging verification at the MUA?

No, because that is not what I said, nor is it what I believe. Please 
do not twist my words, or the words of what are in the spec.

--Paul Hoffman, Director

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Jan 2007 16:14:15 -0800

On Jan 19, 2007, at 3:29 PM, Paul Hoffman wrote:

> No, because that is not what I said, nor is it what I believe.  
> Please do not twist my words, or the words of what are in the spec.

Not every signature will always be checked at the MTA.  While the MTA  
might be focused upon checking signatures that appear linked with the  
 From header, the MUA may ensure Sender headers containing "known"  
Mailing Lists are always checked, for example.  These goals are  
different, and there is not an expectation that _all_ (if any)  
signatures are checked at the MTA.

[In particular, deferring verification until the message is accessed  
by the end user is discouraged.]

One can't say don't check all, as does the added language in the base  
draft, and then say deferring verification by the end user is  
discouraged.  Clearly this statement seeks to define "deferred"  
verification efforts at the MUA as being discouraged.  This is  
wrong.  Allowing the MUA to only verify signatures linked to trusted  
email-addresses leaks less information.  There might even be valid  
reasons _not_ to verify signatures at the MTA.

-Doug

---

From: John Levine <[email-masked]>
Date: 20 Jan 2007 03:07:10 -0000

>I disagree with Doug and agree with the wording in the current document.

I'm with Paul, I do not want to reopen the arguments about how long a
verification key should or shouldn't be around.

R's,
John

---

From: John Levine <[email-masked]>
Date: 20 Jan 2007 03:18:02 -0000

I can also live with the proposed changes.

I concur with the comments other people have made about Section 7,
that it's overkill to require a standards track RFC to add new tags to
the list and an ordinary RFC would be plenty, but it's not a deal
breaker.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 20 Jan 2007 09:48:21 -0800

> verification key should or shouldn't be around.

Why strengthen a bad statement that attempts to declare DKIM is to be
done only at the MTA?  How can DKIM's protection be extended to the MUA?
The concept that policy will block look-alike attacks at the MTA is
highly flawed, and even more so once EAI becomes commonly used.  DKIM is
_designed_ to be invisible.  DKIM's protection requires annotation be
added.  The most secure place to add this annotation is at the _MUA_.

How can an MTA know which email-addresses a recipient trusts?  Checking
the validity of every signature will leak information in the same manner
pulling in separate graphic images.  A bad idea.  Why should the DKIM WG
insist upon making this mistake?

Marking messages at the MTA is afforded none of the protections provided
by the DKIM signature.  Why open such a security hole?  This added
statement goes to the heart of the questionable thinking that surrounds
sender policy protections.  This is a conversation that should be
carefully reviewed and well understood.

-Doug

---

From: John L <[email-masked]>
Date: Sat, 20 Jan 2007 13:17:18 -0500 (EST)

> done only at the MTA?

Nobody's made such a statement.  I don't understand the point of spending 
the group's time arguing about a straw man.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 20 Jan 2007 10:23:11 -0800

>Why strengthen a bad statement that attempts to declare DKIM is to be

Doug, please stop this. That is not what the addition to the text above says.

--Paul Hoffman, Director

---

From: Douglas Otis <[email-masked]>
Date: Sun, 21 Jan 2007 00:14:34 -0800

> the group's time arguing about a straw man.

I do not agree at all.

[In particular, deferring verification until the message is accessed by
the end user is discouraged.]

Removing unnecessary language in this statement leaves:

"In particular, verification by the end user is discouraged."

Any verification at the MUA would be deferred in comparison to being
done within the SMTP session.  The MUA is where end-user verification
would occur, and any verification not made within the SMTP session MUST
be considered deferred.

Most recipients will not fetch graphical images referenced by messages
from unknown originators to prevent leaking information and to prevent
DDoS exploits.  It is not safe to assume DKIM verification should be
done at the MTA for every message.  Such a strategy would clearly
indicate which clients succeed in getting past initial screening
defending DKIM verification and allows for DDoS exploits.

Something like a DAC list can serve as a prerequisite for DKIM
verification at the MTA. Being on a trusted list is perhaps the _only_
safe instance where DKIM verification should occur at the MTA.  When
done in this limited fashion, DKIM can be used to avoid identifying
messages as spam due to their volume, or avoid identifying messages as a
phishing attempt.  DKIM prevents false positive rejection of trusted
sources for more stringent filtering.

All messages, whether verified by the MTA or not, SHOULD be verified at
the MUA when applying annotations.  Verification at the MTA or MUA
SHOULD be limited to messages containing trusted originators.  Security
is improved when not verifying messages having an unknown or untrusted
originator.

It is unreasonable to expect that DKIM is useful for rejecting spam.
DKIM provides a safe basis for annotation that ensures a message is from
a trusted source, and DKIM minimizes false positive filtering.  The
erroneous concept that DKIM provides a basis for rejection is likely the
_only_ justification that could be used to support the very bad
statement added in the latest draft. 

-Doug

---

From: Hector Santos <[email-masked]>
Date: Sun, 21 Jan 2007 06:57:57 -0500

Douglas Otis wrote:
 > [snip]
> the MUA when applying annotations.  

You keep saying this but you continue to fail to understand the MUA will 
typically have no control over any of this.  You are assuming one type 
of MUA, the offline style standalone or applet MUA, such as POP3, IMAP 
which MAYBE would be interested in the possibility of offering delayed 
DKIM processing.

But you need to keep in mind (which you obviously won't) we need to deal 
with online mail clients and quite often, very thin mail clients which 
could be nothing more than just a simple web browser or telnet client 
100% completely controlled by the mail host or backend.

The statement in question, if anything, which applies to the general 
case offline or online mail clients, simply states:

    "Delayed VERIFICATION is discouraged after reception of a
     signed DKIM message."

This does not stop you or any other ambitious OFFLINE MUA from 
possibility doing delayed DKIM verification operations.

This problem is solved at the MTA. But there is the delay issue that an 
OFFLINE system will be confronted with if it has DKIM verification 
features.  The draft proposal:

http://tools.ietf.org/wg/dkim/draft-santos-dkim-rcvd-00.txt

attempts to summarize, highlight the delay verification issue and offers 
a way to assist the offline MUA.  But this is GRAVY because for us, the 
logic is all in the backend which covers all our MUA devices.

---
HLS

---

From: Dennis Dayman <[email-masked]>
Date: Sun, 21 Jan 2007 11:20:30 -0600

> I can live with the proposed changes in this draft as written. 

me as well..

-Dennis

---

From: "Charles Lindsey" <[email-masked]>
Date: Sun, 21 Jan 2007 17:38:01 -0000

>     "Delayed VERIFICATION is discouraged after reception of a

No, it doesn't say that either.

I think that, since this wording is being interpreted in different ways by  
different peopls, it is a clear case of needing rewriting so that  
_everyone_ agrees what it means.

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Sun, 21 Jan 2007 17:35:14 -0000

> "In particular, verification by the end user is discouraged."

No it doesn't. What the first statement discourages is omitting
verification at the MTA on the grounds that the MUA might be a better
place (observe the word "deferring"). There is no discouragement whatsover
against an MUA repeating, for its own benefit, a verification (and more
likely a different policy interpretation) that has already been performed
by the MTA.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 21 Jan 2007 17:52:25 +0000

Charles Lindsey wrote:
> On Sun, 21 Jan 2007 11:57:57 -0000, Hector Santos 
> <[email-masked]> wrote:
>>
> I think that, since this wording is being interpreted in different ways 
> by different peopls, it is a clear case of needing rewriting so that 

I've only seen one person with a contrary view of this so far. Everyone
else seems to agree about what it means.

And we don't have to get everyone to agree. We need only aim for rough
consensus and, so far, I believe we do seem to have that for this
particular change. (But that can change as more folks get to go over
the changes during the week.)

S.

---

From: Hector Santos <[email-masked]>
Date: Sun, 21 Jan 2007 13:14:43 -0500

> No, it doesn't say that either.

In so many words, thats is EXACTLY what it means.  The more you delay 
the verification, the higher the chances of finding revoked keys. Common 
sense? Absolutely. The very first sentence begins with that premise.

> _everyone_ agrees what it means.

Nah, its fine IMO. The only disagreement is ONE person (guess who? DOUG) 
who just wants DKIM processing moved to the MUA - PERIOD and we already 
had lengthy discussions on the issue of delayed verifications either at 
the MTA, MDA or MUA and their timing relationship to revoked and/or 
expired keys.

See

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Sun, 21 Jan 2007 14:21:32 -0800

> else seems to agree about what it means.

DKIM signatures can be verified by email web-based clients offering
basic capabilities, as well as by traditional MUAs running POP3 and
IMAP.  There are already products offering this extended capability.
Any DKIM verification done outside the SMTP session is "deferred".
There is NO reason to discourage "deferred" verifications _especially_
when the verification has _not_ been done by the MTA.  

Some MTA operators may establish a basis of verification as being done
_only_ when an invalid signature changes the handling of the message.
Signatures that might alter message handling at the MTA may frequently
differ from those signatures used to establish annotations by end user
applications. Mailing-Lists would an example of such a case.

This statement is _wrong_ regardless of intent, or what it is explained
to mean.

Perhaps this is what is attempting to be communicated:
,---
| Rejection of messages not having acceptable DKIM signatures SHOULD 
| occur prior to acknowledging acceptance at the end of the SMTP session
| DATA phase.  MTAs will not always verify signatures serving as a 
| basis for annotations applied by end-user applications.  Signatures
| that establish message annotations SHOULD be verified, whether
| deferred or not.
|
| Early removal of DKIM public keys may result in messages not obtaining
| desired annotations when applied the end-user applications.  
'---

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Jan 2007 10:50:47 -0000

> the chairs would like the working group to review the document fully.

Simple Canonicalization

The revised wording achieves what it was intended to achieve, namely that  
an empty/absent <body> result in a single <CRLF> to be hashed.

What is not clear is WHY this alternative was chosen (as opposed to  
letting it result in an empty <body>).

I hae repeatedly asked for a reason as to WHY this outcome is thought to  
be desirable, but no explanation has been forthcoming. So I ask the  
question again now.

WHY?

Note, this is not (yet) an objection to the draft - just a request for  
explanation.

---

From: Hector Santos <[email-masked]>
Date: Mon, 22 Jan 2007 07:32:10 -0500

Charles Lindsey wrote:
> The revised wording achieves what it was intended to achieve, namely 
> that an empty/absent <body> result in a single <CRLF> to be hashed.
> 

IMO, I think it was obvious, but I'll take a shot.

When the l= tag is specifically set to a zero value (e.g., l=0), per 
DKIM-BASE specification this means there is no hashing of the body, 
regardless of size.   As a consequence, technically, the body can be 
altered and passed on.

When the l= tag is not zero, this means the body was hashed, including 
the possibility of the l=2 condition where there was only two bytes 
hashed which MAY OR MAYBE be <CRLF> bytes.

So you have three conditions:

   l=0    No Body hashing (original body is not protected)
   l=2    May or may not be empty (could be 2 non CRLF bytes)
   l>2    Not an empty message, contains at least 1 byte.

So why would one hash a L=2 condition?

In order to distinguish between a hashing condition (l is not zero) and 
a non-hashing condition (l is zero) and the special case where the body 
is actually deemed SIMPLE c14n "empty", it might be desirable to hash 
the SIMPLE c14n "empty" body to simply indicate that the *original 
message body* was indeed EMPTY and not a case were the BODY was altered 
to a zero size.

Example:

Lets suppose I signed all my mail headers only, but not the body. I 
therefore have a L=0 tag in the DKIM-Signature. bh= is not defined.

Why I would I do this is out of scope, but of course, it makes our 
message insecure and vulnerable to replay exploitations where the body 
was altered and not the original.  Nonetheless, the specs does allow for 
a non-hashing body (l=0) provision.

We soon discover this is not a good idea and begin to hash the body.

Inevitably, we will come across an original message where the body is 
reduced to a SIMPLE c14n "empty" message.

We can't use a L=0 concept because that opens the door for the above 
body altering exploitation.

So we hash the SIMPLE c14n empty message with the <crlf> l=2 bytes to 
indicate that the message was indeed "empty" and not some malicious body 
altered message if l=0 was allowed to be used to indicate an "empty" 
message.

Hope that explains it.

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 22 Jan 2007 07:47:24 -0500

Hector Santos wrote:

>   l>2    Not an empty message, contains at least 1 byte.

We have a forth condition:

     n/a    l= is not defined, hence the entire body is hashed.

---
HLS

---

From: Eric Allman <[email-masked]>
Date: Mon, 22 Jan 2007 07:49:49 -0800

> The revised wording achieves what it was intended to achieve,
> namely that  an empty/absent <body> result in a single <CRLF> to be
> hashed.
>

I could easily envision a situation where a completely empty body got 
sent via BDAT to an intermediate MTA that had to convert it to DATA 
format for retransmission.  It wasn't hard to make a guess that some 
such MTAs might a CRLF before the final dot.  It's not likely, but 
possible, and canonicalizing in this way prevents that problem.

Other than that it's an arbitrary choice.  It was always my intent 
that it be included, and the ABNF was clear that it should be 
included, so that seemed to be the right way to go.

eric

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Jan 2007 11:34:44 -0800

>letting it result in an empty <body>).

Again: it doesn't matter why A or B was chosen. What is important is 
that we have a spec without interoperability issues.

--Paul Hoffman, Director

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 22 Jan 2007 20:35:59 -0000

>    l>2    Not an empty message, contains at least 1 byte.

The likely cases (including no l= tag at all, as you mentioned later)  
would be put there by the signer for the following reaons:

    l=0     I did not sign the body, and I accept that it may be altered in
            transit (undetectably), and I don't care.
    l=y where y>>0
            I signed y bytes of the message, and I don't care if anybody  
adds
            (or alters) anything beyond that (usually, y is the original  
length).
    n tag absent
            I signed the whole body, and I don't want anybody adding extra
            stuff beyond the end.

Now you seem to be saying that, supposing empty bodies hash as zero bytes,  
it is impossible to distinguish whether l=0 means
            I didn't sign the body, and I don't care if someone alters or
            extends it during transit.
or
            I did not provide any body, and I don't care if someone adda a
            body during transit.

These two cases are so similar that I see no necessity to distinguish  
between them.
> message body* was indeed EMPTY and not a case were the BODY was altered  

Your first sentence there seems to be distinguishing between three things  
with only one bit of information. But I think the distinction you are  
trying to make is the same as the one I mentioned above, and I see  
absolutely no reason why making that distinction will ever be helpful.

In the event that the sender intended to send an empty body, and wants to  
be sure that it arrived as an empty body (which seems to be the third item  
in your first sentence), then he would simply provide no l= tag at all.

[As an aside, if l=0 is provided in the present draft (meaning no body  
signature), what appears in the body-signature-hash space in the  
signature? Is it the result of applying sha-256 to <empty>, or is that  
hash space omitted from the signature entirely?]

> altered message if l=0 was allowed to be used to indicate an "empty"  

But l=2 does NOT indicate that the message was "empty". It merely  
indicates that the first line of the message was an empty line. It says  
nothing about the huge text that follows that empty line, whether that  
text was provided by the original sender or by soem intermediate scammer.

---

From: Hector Santos <[email-masked]>
Date: Mon, 22 Jan 2007 15:49:36 -0500

Eric Allman wrote:
> Other than that it's an arbitrary choice.  It was always my intent that 
> it be included, and the ABNF was clear that it should be included, so 
> that seemed to be the right way to go.

Regardless of how the message became "empty" either by BDAT or some 
other side-line "mail creator" that puts the new outbound mail into a 
DKIM signing queue, or whatever,  I think it is very significant to sign 
the DKIM based empty body simply to let the world known that it is empty 
indeed, regardless of how it got that way.

I personally can see many reasons why a message would be empty from an 
application standpoint, e.g.;  "Mail to Cell" messages where the subject 
line is used for text, no body required, Mail Events, Notifications or 
even LIST SERVER commands based on subject text, etc. Although the 
general rule of thumb is to throw in some tear line, there are many 
reasons why a message could be "empty."

---
HLS

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 22 Jan 2007 14:17:31 -0800

> verification key should or shouldn't be around.

Not sure if it's a +1 to Paul or a -1 to Doug, but either way I agree 
with Paul and John here.  We need -base yesterday; save the endless 
intractable arguments for SSP.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Product Platform Group
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 Jan 2007 15:32:08 -0800

On Jan 22, 2007, at 2:17 PM, J.D. Falk wrote:

> Not sure if it's a +1 to Paul or a -1 to Doug, but either way I  
> agree with Paul and John here.  We need -base yesterday; save the  
> endless intractable arguments for SSP.

While I might agree with the urgency, this poorly worded comment  
launches the SSP journey with a stated expectation that MTAs provide  
full coverage of DKIM signature verification prior to messages being  
obtained by end users.  This produces unrealistic expectations for  
how DKIM might be adopted, as well as overestimating the consistency  
of MTAs and their backups.  While this group might be dominated by  
MTA vendors (in general a good thing), DKIM will likely offer far  
greater protections in the hands of MUA vendors who can provide much  
needed annotations in a era where email will also likely see a rapid  
uptake of EAI extensions.

<repeated rant 1>
UTF-8 should create serious doubts about the efficacy of any  
annotation made by MTAs not based upon a level of trust.  The current  
thinking appears to be annotations indicating the number of policy  
hoops navigated.  With a churn rate of domain names in the millions  
per day, it is not reasonable to assume a protection scheme can stay  
ahead of the bad actors.  Finding a means to establish trusted  
identities is critically important.  Once such source might be the  
recipient's address book, in addition to DAC lists appropriate at the  
MTA.
</repeated rant 1>

<repeated rant 2>
The bifurcation of identities introduced by EAI also means a common  
domain scheme depended upon to link headers with DKIM signatures is  
not adequate either.  Expecting MTA servers to warehouse hundreds or  
thousands of private keys is another cause for concern, before  
launching the SS DKIM.  This problem can be resolved by a simple  
relaxation of the 'i=' identity and a provision allowing domain  
association using simple hash tags.
</repeated rant 2>

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Jan 2007 23:33:35 +0000

> intractable arguments for SSP.

So I hope that that's you volunteering for some Gordian knot work
on SSP in a short while:-)

Seriously though, once we get a sense of the WG wrt base-08, then
I want us to restart work on SSP, so we should all sharpen our
opinions for next week,

Thanks,
S.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 22 Jan 2007 15:54:54 -0800

On 1/22/07 3:32 PM, Douglas Otis wrote:

> obtained by end users.

No, Doug, my poorly worded comment simply reflects that the SSP journey 
thus far has been full of intractable arguments.  I'm not saying 
anything at all about MTAs.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 22 Jan 2007 16:23:43 -0800

On Jan 22, 2007, at 3:54 PM, J.D. Falk wrote:

> No, Doug, my poorly worded comment simply reflects that the SSP  
> journey thus far has been full of intractable arguments.  I'm not  
> saying anything at all about MTAs.

J.D.

I must apologies for my own poorly worded comment about the setting  
of expectations that MTAs provide full coverage of DKIM signature  
verification.  By poorly worded comment, I meant the one added in the  
recent base draft:

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 23 Jan 2007 01:31:53 -0500

Charles Lindsey wrote:
> On Mon, 22 Jan 2007 12:32:10 -0000, Hector Santos 
>> indicate that the message was indeed "empty" and not some malicious 
>> body altered message if l=0 was allowed to be used to indicate an 
>> "empty" message.
> 

That is correct as pointed out in my last issue post regarding leading 
blank lines:

http://mipassoc.org/pipermail/ietf-dkim/2007q1/006941.html

I think the overall issue here is that the DKIM-BASE specs lacks 
discussion on "Partial Hashing" considerations.

This is not a technical problem - but a SECURITY issue, and it should be 
  addressed with a KEY attribute that defines the EXPECTATION of the 
signer for WHOLE or PARTIAL hashing requirements.

In fact, looking at the spec, section 8.1 makes a profound statement 
statement about potential attacks, yet, offers no possible remedy:

   8.1  Misuse of Body Length Limits ("l=" Tag)

    Body length limits (in the form of the "l=" tag) are subject to
    several potential attacks.

Thats it!!  That is all it says.  This needs action.  I think this whole 
issue can be resolves once and for all with a KEY attribute that defines 
the whole vs partial hashing expectations.

I vote for a new corresponding key tag, "l=" in section 3.6  Key 
Management and Representation.

    l=  Defines whole or partial hashing of body

        w   The entire body is hashed (default). The
            DKIM-Signature: l= tag may be omitted or defined
            with the full body length.

        p   Partial hashing allowed.

        #   If a number is defined, this is the MINIMUM bytes
            allowed to hashed.

Again, I'm just winging it and I hope some doc person can do a better 
job.  I personally prefer the default to be entire body hashing.

---
HLS

---

From: <[email-masked]>
Date: Tue, 23 Jan 2007 10:07:33 -0500

Doug,
Authoritative statements made by a DKIM aware MUA is a good thing.
However from an ISP perspective I would not depend on an end user to
have a DKIM aware MUA but will verify and do Policy silently at my edge
MTA devices. Any mail that makes it past there can still be acted upon
by the MUA.

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Monday, January 22, 2007 6:32 PM
To: J.D. Falk
Cc: [email-masked]
Subject: Re: [ietf-dkim] Change to Section 6

<repeated rant 1>

<repeated rant 2>

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Jan 2007 16:40:18 +0100

I'll just add my +1 to the list of those who agree with the changes made 
by the authors in the last version.  I believe the arguments about MUAs 
v MTAs can really only be solved with operational experience.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 23 Jan 2007 08:38:37 -0800

> MTA devices. Any mail that makes it past there can still be acted upon

There are millions of new domains added and removed every day.  Checking
sender policy is like asking a fox to guard the chicken coop.  Should
the MTA verify DKIM signatures before applying filters?  Don't forget
about Display-Name only, clever use of UTF-8, cousin domains, and
obfuscations making it appear as though the email-address is displayed.
Of course, there is also EAI soon to be embraced by a major part of the
world.  Exploits will still slip through MTAs, simply because the MTA
does not know who the recipient is trusting. 

Reasonable anti-phishing efforts at the MTA requires content of the
message (including content of the links within the message) to be
checked, and not just a check of a sender policy.  Content checking will
not be comprehensive either, as IP address shuttering techniques easily
defeat even these difficult checks.  

Reasonable anti-phishing efforts at the MUA only needs to annotate those
email-addresses found in the recipient's address book that are confirmed
by a DKIM signature.  No sender policy is needed.  Content does not
matter, look-alikes of any type are thwarted, and this protection is not
easily defeated.  These MUA extensions can be added as plugins.  End
user extensions are even available for web clients. 

Expecting that all DKIM signatures are verified at the MTA is wrong!
Expecting that provider's customers should accumulate their private keys
at the MTA is wrong!  There should _never_ be more than just the
provider's private key at the MTA!  Association between the
email-address domain and the signing domain SHOULD be by REFERENCE!  It
is absurd to demand that associations are only possible when they are
within the same domain.  Association by REFERENCE can accommodate the
dual identities offered by EAI addresses.  Providers must stop trying to
obfuscate who is signing and transmitting messages!  

Annotations based upon DKIM signatures should be directly verified.
Early removal of public keys may cause such annotations to not be
applied.  Expectations that the MTA has verified all DKIM signatures and
sender policies should be strongly discouraged.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 23 Jan 2007 11:50:55 -0500

Douglas Otis wrote:
> There are millions of new domains added and removed every day. 

And if true, any given average node only sees 0.001% of them if that.

> Should the MTA verify DKIM signatures before applying filters?  

Thats out of your control.

 > Don't forget about Display-Name only, clever use of UTF-8,
 > cousin domains, and  obfuscations making it appear as though
> the email-address is displayed.

So if the MTA can't handle it, we'll pass you that junk so you can deal 
with it.  A six pack your MUA can't deal with it neither!

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 23 Jan 2007 11:30:32 -0600

> and I assess rough consensus at the roughest level.

+1 - happy with changes.

-- 
Arvel

---

From: Douglas Otis <[email-masked]>
Date: Tue, 23 Jan 2007 10:36:26 -0800

On Jan 23, 2007, at 8:50 AM, Hector Santos wrote:

>>> Authoritative statements made by a DKIM aware MUA is a good  
>>> thing. However from an ISP perspective I would not depend on an  
>>> end user to have a DKIM aware MUA but will verify and do Policy  
>>> silently at my edge MTA devices. Any mail that makes it past  
>>> there can still be acted upon by the MUA.
>>

How is this relevant?  New domains are often exploited before a  
registry can compile and transfer what has changed.  For ".com" there  
might be a 12 hour lag in noting the millions of new domains, which  
is a short interval compared to some TLDs.

> Thats out of your control.

Verifying DKIM signatures after applying filters informs bad actors  
what has slipped through.  Unless a valid signature permits the  
filter to be bypassed, there is little value validating a signature  
afterwards.  Verifying all signatures ahead of filters will increase  
require resources.  Verifying all DKIM signatures adds cost and opens  
the door to DDoS concerns without tangible benefit.  When the MTA  
will bypass spam or phishing filters based upon specific signatures,  
these are the only signatures logically that should be validated.   
The MUA can also be highly selective by only validating signatures  
trusted by the recipient.  Such a strategy reduces resources demanded  
by DKIM deployment, and will not leak critical processing information  
to bad actors.

>> Don't forget about Display-Name only, clever use of UTF-8, cousin  
>> domains, and  obfuscations making it appear as though the email- 
>> address is displayed.
>
> So if the MTA can't handle it, we'll pass you that junk so you can  
> deal with it.  A six pack your MUA can't deal with it neither!

There should not be any expectation that all signatures have been  
verified.  Logically only those signatures that might rescue a  
message from being rejected should be checked.  This checking should  
be selective and happen ahead of other filtering.  Essentially this  
means that not all signatures should be checked.

There are millions more MUAs than there are MTAs.  This may suggest  
which MTA versus MUA effort might be better at scaling.  How about a  
bottle of Cabernet versus your six-pack? : )

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 23 Jan 2007 19:51:32 -0000

> possible, and canonicalizing in this way prevents that problem.

Well that is a reason worth considering (more than can be said of Hector's  
confused arguments). But I would have though that a BDAT -> DATA converter  
would simply have rendered an emtpy bid as an absent body (which is  
perfectly possible under RFC 2821). So not a very strong argument.
>
> Other than that it's an arbitrary choice.

Indeed, but it is odd that the arbitrary choice turns out not to be the  
simplest choice.

---

From: Hector Santos <[email-masked]>
Date: Tue, 23 Jan 2007 16:12:22 -0500

Douglas Otis wrote:
>>>> have a DKIM aware MUA but will verify and do Policy silently at my 
>>>> edge MTA devices. Any mail that makes it past there can still be 
>>>> acted upon by the MUA.
>>>
> How is this relevant?  

Isn't the statement clear?  Hardly one single NODE will have handle a 
million churned domains per day, so its an irrelevant statistic.

> New domains are often exploited before a registry 
> can compile and transfer what has changed.  For ".com" there might be a 
> 12 hour lag in noting the millions of new domains, which is a short 
> interval compared to some TLDs.

Great, so the unregistered DOMAIN will fail.  So it all good!

> Verifying DKIM signatures after applying filters informs bad actors what 
> has slipped through.  

How so?  Whats the different if the VERIFICATION is applied at the MTA 
vs MUA. What makes the MUA exclusive and holds the copyright on this 
technology of yours?    What about thin clients?

By the way, what filter? I don't see anything about Filters in DKIM-BASE?

Anyway, it is still out of your control.

> Unless a valid signature permits the filter to be 
> bypassed, there is little value validating a signature afterwards. 

Regardless of whatever your filter is, your right. If the MTA validates 
the signature, there is little need or value for the MUA to do it. 
Thats the whole point.

> Verifying all signatures ahead of filters will increase require 
> resources.  

What filters?

> Verifying all DKIM signatures adds cost and opens the door 
> to DDoS concerns without tangible benefit.  

So why would you want the MUA to suffer if thats that case?

 > When the MTA will bypass spam or phishing filters based upon
 > specific signatures, these are the
> only signatures logically that should be validated.  

Who said anything about Mail Processing Order?  Content processing may 
not even be reached with 2821 checking is done.  Is that a problem for 
you too?

 > The MUA can also be highly selective by only validating
 > signatures trusted by the recipient.

Which MUA are you talking about?  Outlook, Thunderbird, Eudora?  What 
about telnet mail client, my web mail client?  Do you have a design 
there too?   Will DKIM work without the SMART FAT OFFLINE MUA?

> Such a strategy reduces resources demanded by DKIM 
> deployment, 

I see no proof of this and in fact, all indications are that you are 
100% completely wrong about your expect ions for MUA/DKIM operations.

 > and will not leak critical processing information to bad
> actors.

I see no leaks at the MTA that can't be also leaked at any other OFFLINE 
MUA.

>>> domains, and  obfuscations making it appear as though the 
>>> email-address is displayed.
>>
> verified.  Logically only those signatures that might rescue a message 
> from being rejected should be checked.  This checking should be 
> selective and happen ahead of other filtering.  Essentially this means 
> that not all signatures should be checked.

(Hand flying over head!) Phew! Geez Doug, honestly, I have no clue of 
what you are talking about!  You are making all kinds of assumptions!

> There are millions more MUAs than there are MTAs.  

Anyway, this is exactly the reason why you want the centralized the DKIM 
processing at the backend. Our figure is ~15,000 users per Wildcat! 
Hosting Server.  Average break down about 30% Offline Mail Access,  60% 
Online Mail Access (Web, Telnet, NNTP, GUI frontend).   Everyone 
benefits from centralized backend processing.

> This may suggest which MTA versus MUA effort might be better 
 > at scaling.

So you basically you are saying that all this is waste a time, no MTA 
should bother with DKIM processing, it should PASS all mail to the user 
regardless of how its is access?

 > How about a bottle of Cabernet versus your six-pack? : )

I've been drinking GlenFiddich (aged 15 years) these days. :-)

You are beating a dead horse with your DKIM MUA push.  Your best bet is 
to get the MTA/MUA DKIM communications worked out so that the MTA can 
pass verification information to the user (offline and online).  Until 
you do so, it is all out of your control.

---
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 23 Jan 2007 16:21:26 -0500

Charles Lindsey wrote:
> Well that is a reason worth considering (more than can be said of 
> Hector's confused arguments). 

Snob! What is so confusing about it?  You are the only one confused here 
with this on going not stop complaining of the SIMPLE c14n empty hashing.

> But I would have though that a BDAT -> 
> DATA converter would simply have rendered an emtpy bid as an absent body 
> (which is perfectly possible under RFC 2821). So not a very strong 
> argument.

Oh stop it already.   The specs in this regard is fine.  The only thing 
that is missing to resolve this security issue is a KEY attribute that 
defines the intentions of the signer for partial hashing.   If the 
signer is concern about it, it should never define a l= tag.  Otherwise, 
he would run into l=2 problems. If you don't understand that, thats your 
problem.

===
HLS

---

From: Jim Fenton <[email-masked]>
Date: Tue, 23 Jan 2007 16:32:51 -0800

> job.  I personally prefer the default to be entire body hashing.

I disagree with the need for this.  If the domain administration trusts 
someone to apply a signature for a domain, they should be trusted to 
abide by rules the domain sets for the signature:  proper use (or 
non-use) of l=, what header fields to sign, etc.  If they can't be 
trusted to do this right, they shouldn't be trusted to sign at all.

This is different from the specification of the hash and signature 
algorithms in the key record, since the use of too-weak algorithms might 
(at some point in the future, presumably) allow someone not authorized 
at all to apply a valid signature.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 23 Jan 2007 17:05:50 -0800

On Jan 23, 2007, at 1:12 PM, Hector Santos wrote:

> Isn't the statement clear?  Hardly one single NODE will have handle  
> a million churned domains per day, so its an irrelevant statistic.

Using your figures there are still 1000 unevaluated domains that  
might be seen at some NODE.  What makes this aggregate number  
significant is the amount that needs to be evaluated and then  
distributed.

>> New domains are often exploited before a registry can compile and  
>> transfer what has changed.  For ".com" there might be a 12 hour  
>> lag in noting the millions of new domains, which is a short  

No. These domains are registered.  They are not reported as being  
registered however until much later.

>> Verifying DKIM signatures after applying filters informs bad  
>> actors what has slipped through.
>
> How so?

When whether a signature is valid or not does not change how the  
message is handled, then not validating the signature will not change  
which messages are given a recipient.  When verification is  
selectively done ahead of filtering based upon signatures that permit  
filters to be bypassed, then this should reduce the required  
resources and false-positives.  When DKIM verification follows spam  
filtering, attempts to verify signatures only signals which messages  
passed.  Bad actors will be thanking you.

> What's the different if the VERIFICATION is applied at the MTA vs MUA.

The signatures that are trusted will be different from the end user's  
perspective.  An untrusted verified signature is of no value in  
either case.  Only trusted and verified signatures should be used to  
annotate messages.

> What makes the MUA exclusive and holds the copyright on this  
> technology of yours?

The end user application can more accurately determine which messages  
the recipient is trusting.  Only those messages need to have the DKIM  
signature verified.

> What about thin clients?

There are extensions that can extend nearly all the popular MUAs and  
web based clients.  Web based clients can be extended by taking  
advantage of normal display and unread options.

> By the way, what filter? I don't see anything about Filters in DKIM- 

Spam represents the vast majority of what MTAs receive.  These would  
be spam/anti-phishing filters of course.

> Anyway, it is still out of your control.

The base draft should not be so misleading and suggest that the MTA  
always verifies signatures first.

>> Unless a valid signature permits the filter to be bypassed, there  
>> is little value validating a signature afterwards.
>
> Regardless of whatever your filter is, your right. If the MTA  
> validates the signature, there is little need or value for the MUA  
> to do it. Thats the whole point.

You have missed what was being said.  An end user application does  
not have a standardized way to know what has been validated by the  
MTA. The MTA signing authentication headers increases the resources  
required.  The whole point is that what an MTA or MUA verify may be  
very different.  The recipient might not care about the From header,  
but does trust the mailing-list noted in the Sender header for example.

>> Verifying all signatures ahead of filters will increase require  

Spam/anti-phishing filters.

>> Verifying all DKIM signatures adds cost and opens the door to DDoS  
>> concerns without tangible benefit.
>

Why would the MUA suffer when limiting verification to just those  
messages that are being trusted?

>> specific signatures, these are the only signatures logically that  
>> should be validated.
>
> Who said anything about Mail Processing Order?  Content processing  
> may not even be reached with 2821 checking is done.  Is that a  
> problem for you too?

The MTA knows (well in advance) which signatures might rescue a  
message from their filters before even accepting the message.  Just  
those signatures need to be checked.

>> trusted by the recipient.
>
> Which MUA are you talking about?  Outlook, Thunderbird, Eudora?   
> What about telnet mail client, my web mail client?  Do you have a  
> design there too?   Will DKIM work without the SMART FAT OFFLINE MUA?

One could add DKIM verification scripts for any user interface or  
API.  When the application has a list of trusted domains, it should  
not be problematic to cache DKIM keys for offline analysis, perhaps  
for a slow and expensive connection.

There are plugins for Yahoo!Mail, Yahoo!Mail Beta, AT&T Yahoo!Mail,  
Hotmail, Windows Live, Gmail basic and standard, Earthlink web mail  
using Mozilla and IE browsers, and Outlook express to accept a  
trusted list.  This proves it is possible and works well.

Here is source for a DK and SPF plugin for Thunderbird by Joshua  
Tauberer.  Perhaps Mike might want to modify this for DKIM. : )
http://razor.occams.info/code/spf/

>> Such a strategy reduces resources demanded by DKIM deployment,
>
> I see no proof of this and in fact, all indications are that you  
> are 100% completely wrong about your expectations for MUA/DKIM  
> operations.

When the more than 70% of the email accepted is spam, then verifying  
only trusted sources eliminates a significant amount of DKIM related  
overhead.

>> and will not leak critical processing information to bad actors.
>
> I see no leaks at the MTA that can't be also leaked at any other  
> OFFLINE MUA.

Attempting to verify all DKIM signatures that have passed through the  
spam/anti-phishing filters leaks information.  When neither the MTA  
or MUA attempts to verify untrusted signatures, no information is  
leaked.

>>>> cousin domains, and  obfuscations making it appear as though the  
>>> So if the MTA can't handle it, we'll pass you that junk so you  
>>> can deal with it.  A six pack your MUA can't deal with it neither!
>>
>> message from being rejected should be checked.  This checking  
>> should be selective and happen ahead of other filtering.   
>> Essentially this means that not all signatures should be checked.
>
> (Hand flying over head!) Phew! Geez Doug, honestly, I have no clue  
> of what you are talking about!  You are making all kinds of  
> assumptions!

Saying that all DKIM signatures should be checked at the MTA is  
making assumptions as well.  Ironically, checking all DKIM signatures  
is not recommended by the DKIM base and lacks a logical reason for  
consuming resources, which also signals bad actors about how far  
their message has progressed.

> Anyway, this is exactly the reason why you want the centralized the  
> DKIM processing at the backend. Our figure is ~15,000 users per  
> Wildcat! Hosting Server.  Average break down about 30% Offline Mail  
> Access,  60% Online Mail Access (Web, Telnet, NNTP, GUI  
> frontend).   Everyone benefits from centralized backend processing.

What do you mean by offline mail access?

>> This may suggest which MTA versus MUA effort might be better at  
>> scaling.
>
> So you basically you are saying that all this is waste a time, no  
> MTA should bother with DKIM processing, it should PASS all mail to  
> the user regardless of how its is access?

DKIM signatures should be verified at the MTA when a valid signature  
might alter the handling of the message.  This allows filters to be  
more stringent while reducing false positives at the same time.   The  
end user application should not assume all signatures have been  
validated when applying annotations based upon what is trusted by the  
recipient.  Unless there is a secure method to reliably pass  
authentication information to end user applications, the signature  
should be verified by the application.

> You are beating a dead horse with your DKIM MUA push.  Your best  
> bet is to get the MTA/MUA DKIM communications worked out so that  
> the MTA can pass verification information to the user (offline and  
> online).  Until you do so, it is all out of your control.

Why should a user wait years for all the MDA/MUA interfaces to become  
standardized?  There is nothing to prevent an end user application  
from verifying DKIM signatures now.  It would be a mistake to think  
that verifying _all_ DKIM signatures will not have a substantial cost.

-Doug