eric+dkim at sendmail.org
Fri Feb 8 11:18:15 PST 2008
I am in no way married to the word DISCARDABLE. We used it in SSP-02
because it matched ASP.
It has occurred to me that we've spent FAR too much time arguing
about exactly what word to use. I'm deeply tempted to switch to
numbers, special characters, or random gibberish strings so that
people have to read the actual description.
--On February 8, 2008 9:55:56 AM -0800 Douglas Otis
<dotis at mail-abuse.org> wrote:
> On Feb 7, 2008, at 4:54 PM, Eric Allman wrote:
>>> The EXCLUSIVE concept can still be covered using DKIM=DISCARDABLE.
>> Except that DISCARDABLE doesn't prohibit 3PS. It doesn't even say
>> that messages without any signatures MUST or even SHOULD be
>> discarded. All it says is how the purported author domain views
>> the messages that it sends out. The furthest it goes is to say
>> that the purported Author Domain "encourages the recipient(s) to
>> discard it."
> Agreed. This changes "strict" (the exclusivity) assertion into
> something that does not express a domain's intentions on
> exclusivity. This assertion simply increases the likelihood of
> having the domain's messages discarded.
> You have previously mentioned the motivation was to accommodate
> high profile domains finding themselves victims of phishing
> attacks. Using the term "discardable" appears to be sending the
> wrong message. It seems unlikely these high profile domains want
> their messages silently discarded, as this assertion implies.
> Discarding of messages does several things:
> - Destroys evidence of a serious crime
> - Reduces delivery integrity for important transactional messages
> - Makes resolving compatibility far more problematic
> Can you see changing this into terminology that does not attempt to
> suggest a verifier action? Going out on limb, I'll add a modified
> furthermore statement. (Frankly, this furthermore statement seems
> to belong in a BCP that happens later.)
> Using Hector's term "exclusive"-
> All mail from the domain is signed with an intent to avoid
> agents that may damage or remove signatures. Furthermore,
> in lieu of a trusted third-party signature, if a message
> arrives without a valid Author Signature due to
> modification in transit, submission via a path without
> access to a signing key, or other reason, the domain
> encourages the recipient(s) to reject the message or issue
> a DSN when the RFC 2821 MAILFROM domains match.
More information about the ietf-dkim