> -----Original Message-----
> From: [email protected] [mailto:ietf-dkim-
> [email protected]] 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
