Doug,
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.
eric
--On February 8, 2008 9:55:56 AM -0800 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)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."
Eric,
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"-
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html