Subject: [ietf-dkim] Body Length mechanism rejections

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Apr 2006 09:20:10 -0700

,---
|3.4.5  Body Length Limits
|...
| Note that verifiers MAY choose to reject or truncate messages that
| have body content beyond that specified by the body length count.
'___

change to:

: Note that verifiers MAY choose to truncate messages that have body
: content beyond that specified by the body length count.

While use of l= should be depreciated, it seems disruptive to have  
this mechanism possibly induce the rejection of messages.  The  
general goal should have all DKIM compliant MTA make the same basic  
choice of whether a mechanism is acceptable or not.

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Apr 2006 11:15:41 -0700

>choice of whether a mechanism is acceptable or not.

Agree. This is the only place where rejecting the message based on 
verification faults is mentioned.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Tue, 25 Apr 2006 14:06:05 -0700

> verification faults is mentioned.
Also agree with the part about not mentioning rejection of messages.

-Jim

---

From: Eric Allman <[email-masked]>
Date: Fri, 28 Apr 2006 13:15:10 -0700

>>> | 3.4.5  Body Length Limits
>>> | ...
>>> | Note that verifiers MAY choose to reject or truncate messages
>>> | that have body content beyond that specified by the body length
>>> | count.
>>>
>>> change to:
>>>
>>> : Note that verifiers MAY choose to truncate messages that have
>>> : body content beyond that specified by the body length count.

Paul and Jim seem to agree --- others?

eric

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Apr 2006 13:25:53 -0700

> Paul and Jim seem to agree --- others?

+1

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Apr 2006 13:44:52 -0700

I suggest we step back, for a moment, and think about this some more. 

I do not have a clever or clean alternative to suggest, but it strikes 
me that specifying modification to message content (by truncating it) is 
pretty extraordinary and likely to be problematic in terms of the 
originators and recipients.

I also keep coming back to the difference between a signing mechanism 
that passes or fails, versus a certification mechanism that uses the 
pass/fail for making a policy decision.  Whether to reject or truncate a 
message falls into the latter, not the former.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Mark Delany <[email-masked]>
Date: Fri, 28 Apr 2006 21:02:04 +0000

> >Paul and Jim seem to agree --- others?

Is this meaning to say that a verifier can't reject a mail if the
length mis-matches? That seems like something rather hard to
enforce. I also don't know the context this is in. Is it only relevant
if a verify is checking l= or in all cases?

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Apr 2006 15:32:29 -0700

On Apr 28, 2006, at 2:02 PM, Mark Delany wrote:

> length mis-matches?

A DKIM compliant verifier should not reject messages using this  
mechanism when information has been appended.  This situation will  
likely occur down stream from the initial transmitting MTA.   
According to the DKIM draft, verification of messages having the l=  
parameter still retains a valid signature.  An entity appending  
information to a DKIM signed message containing the l= parameter may  
risk having their information discarded or separately annotated, per  
the desires of the recipient.  When the appending entity is unhappy  
about the how their information may be handled as a result of this  
mechanism, their action should be to replace such signatures with  
that of their own.  A greater disruption will be caused by rejecting  
these messages, rather than discarding the offending portion of the  
message.  Another strategy could be to include annotation that  
indicates the origin of the unsigned portion of the message.

> That seems like something rather hard to enforce.

In some cases the message will be verified at the MUA where rejection  
is impractical.  When the message is rejected, will an error code  
clarify the reason?  Should the sender reattempt delivery after  
removing offending text?   It seems prudent to avoid disruptions  
caused by extraneous rejections caused by _valid_ uses of a mechanism  
in the DKIM spec.

> I also don't know the context this is in. Is it only relevant if a  
> verify is checking l= or in all cases?

This is only about removing a recommended remedy addressing the issue  
where the body length has been specified and subsequently altered by  
appended text.  If anything, at the extreme, this could be considered  
causing an invalid signature.  Whether an invalid signature serves as  
a reason for rejection would be a different issue.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Apr 2006 19:13:14 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Mark Delany" <[email-masked]>

> caused by extraneous rejections caused by _valid_ uses of a mechanism

I'm increasing getting concern that the DKIM-BASE specs is being watered
down to a PURE ACCEPTION technology at the SMTP level leaving all decision
for MUA's to make - the cat's meow for both good and bad spammers, including
the DMA.

We need to be very careful that this doesn't further contribute to what I
called "Mail Pollution."

There seems to be a "battle" of where DKIM is going to be implemented.

Doug, for what it is worth, DKIM is not going to succeed as a MUA verifier
solution only.  SMTP software will going to play a vital role here in
controlling mail pollution using the new level of information available to
them, one that is beyond legacy operations.

So I hope I'm not reading you wrong here and that you want ALL SMTP software
to pass all failures to MUAs.  I can't speak for others, but it "ain't"
going to happen in our software.  If we can detect DKIM failures, will be
rejected by default allowing the operators to decide for themselves.  Again,
think Mail Pollution.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Apr 2006 17:31:26 -0700

> There seems to be a "battle" of where DKIM is going to be implemented.

DKIM can be more rapidly deployed when verification is allowed to  
take place at both the MTA and MUA.  There should be no reason for  
these goals to be in conflict.  This "battle" seems resolved with a  
definition of received time rather than current time, as pertaining  
to timing constraints for the verification, and a recognition that  
SMTP is not the only transport protected by the DKIM signature.

> Doug, for what it is worth, DKIM is not going to succeed as a MUA  
> verifier solution only.

DKIM verification can take place at the MTA and the MUA.  At the MTA,  
obvious attempts at phishing is where DKIM will significantly improve  
upon the false positives, and at allowing more aggressive detection.   
Keep in mind such filtering is still reactive, whereas message  
annotation of well-known domains at the viewing application is  
proactive.  These two locations for DKIM verification offer  
different, valuable, and compatible benefits.

> SMTP software will going to play a vital role here in controlling  
> mail pollution using the new level of information available to  

Obstacles created to impede acceptance will be expensive,  
problematic, and affect legitimate senders far more than those intent  
on abusing email.  Allow DKIM to prove valuable at handling deceptive  
messages, while not disrupting the way email is currently used.

> So I hope I'm not reading you wrong here and that you want ALL SMTP  
> software to pass all failures to MUAs.

Over perhaps the span of many years it may become practical to  
generally reject messages failing DKIM verification.  Domains being  
phished are already known by filtering products at the MTA, where  
having these domains signing their messages should allow improvements  
upon what is and is not rejected for this specific problem.  A  
general distribution of well-known domain lists utilized at the  
viewing application will also afford a type of proactive protection  
as well.  DKIM will be of value at both locations, the MUA and MTA.   
Obviously, when at the MUA, message annotation replaces message  
rejection.

> I can't speak for others, but it "ain't" going to happen in our  
> software.  If we can detect DKIM failures, will be rejected by  
> default allowing the operators to decide for themselves.  Again,  
> think Mail Pollution.

Either the body length mechanism is added by the signer to improve  
upon the robustness of their message signatures, thereby improving  
their acceptance, or there is absolutely _no_ value having this l=  
mechanism.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 29 Apr 2006 11:57:57 -0700

>Is this meaning to say that a verifier can't reject a mail if the

Not at all. The verifier can reject mail for any reason at all. What 
the proposal does is take talk of rejecting the message out of the 
DKIM document.

>I also don't know the context this is in. Is it only relevant

Both, kind of. There appears to be little support in the WG for us 
talking about when a message should and should not be rejected, so 
removing the rejection talk from l= is a good thing. People will 
certainly write documents about how to decide when to reject 
DKIM-signed mail, just as they write documents about when to reject 
spam.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html