On Apr 28, 2006, at 2:02 PM, Mark Delany wrote:
,---
|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.
Is this meaning to say that a verifier can't reject a mail if the
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html