-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jon Callas
Sent: Friday, June 25, 2010 12:21 PM
To: MH Michael Hammer
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-
00(fwd)
My interpretation is that gives you the license to do whatever makes
sense to you, as a receiver. If you *want* to silently drop a message
that doesn't meet policy, that's all the standards ammo you need to
justify your decision.
On the other hand, if you want to log, audit, quarantine, filter, or
even bend, fold, spindle, or mutilate the message, you have
justification as well. DiscardABLE doesn't mean they MUST be discarded.
Encouragement is even weaker than a SHOULD, and it's the sending domain
that encourages it.
+1. OpenDKIM actually implements a reject (55x error) with the intent of
giving the sender/victim an opportunity to detect a problem, an idea for which
there is some obvious demand, though I imagine we should make that configurable
and maybe even default it to an actual accept-but-throw-away form of "discard".
As the language in RFC5617 is soft ("encourages", "discardABLE"), the assertion
that doing anything other than accept-but-throw-away is indicative of lunacy
could easily be lost on the reader. If it's really a major problem, maybe the
WG should do an update draft that hardens the language and explains clearly
that "discard" in this context means "250 + bitbucket".
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html