ietf-dkim
[Top] [All Lists]

[ietf-dkim] ADSP breaks forwarding

2010-09-14 08:47:42
On 14/Sep/10 03:18, John R. Levine wrote:
Early drafts of what turned into ADSP used the word "strict" which I
changed to "discardable" to make it clear that if you set this flag,
you're saying the mail is unusually unimportant, to the extent that if
there's doubt about its legitimacy, just throw it away.

At the time, "strict" was meant to be the equivalent of DK's "-", 
wasn't it?  IMHO, "discardable" has been an addition rather than a 
substitution.  Given that, and assuming that "discardable means 
discardable", as you wrote[1], is it correct to _reject_ on _all_?

[1] http://mipassoc.org/pipermail/ietf-dkim/2008q1/009557.html

The final version said

  if a message arrives without a valid Author Domain Signature due to
  modification in transit, submission via a path without access to a
  signing key, or any other reason, the domain encourages the recipient(s)
  to discard it.

I think it's a reasonable interpretation to say that if you expect
your list software might break the signature, you're doing the sender
a favor by pre-discarding it since that's what the recipients should
do anyway.

Hear, hear. Does such criterion also apply to, say, courtesy 
forwarding?  Consider the following test I made:

   Authentication-Results: ns1.qubic.net; dkim=pass (1024-bit key)
        header(_dot_)i=(_at_)tana(_dot_)it header.b=CGKfNJdO; dkim-adsp=pass
   ...
   Subject: Test quoted printable
   X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.64
   Content-Transfer-Encoding: 8bit
   X-MIME-Autoconverted: from quoted-printable to 8bit by
     ns1.qubic.net id o7SAsR9R006644

The message was signed as quoted-printable, hence they 
(dk.elandsys.com) obviously had verified it /before/ converting back 
to 8bit.  Thereafter, they should not forward adsp-encumbered 
messages, unless wrapped inside entirely new messages, with their own 
"From" (as they actually do, for the autoresponder.)  Is that correct?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>