Eric Allman wrote: > 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.
Hi Eric, I understand this sentiment, and your point here is notable. However, it is very important that the terminology in use here is accurate and appropriate. The global messaging user-base wants and expects guidance on implementation that should be clear and direct. The truth of the matter is, the discarding of email should be expressly discouraged. No message should ever be discarded - RFC 2821 suggests this though does not explicitly disallow or discourage it: http://www.ietf.org/rfc/rfc2821.txt > Delivery SMTP systems MAY reject ("bounce") such messages rather than deliver > them. The discarding of email is one of the key causes of some significant loss of trust in email as a reliable means of communication. While it may be argued that spam may have caused email receiving domains to react in this way as a defense mechanism, it is actually the overreaction - perhaps due to a lack of guidance - that has allowed providers to think that discarding messages is a satisfactory response to the spam or malware threat. Perhaps, if our techniques were 100% accurate in ensuring that no valid message was ever lost, discarding could be appropriate. These techniques will not likely ever reach 100% accuracy. If we (where "we" is the email industry here that seeks to maintain and even expand the usefulness of email itself, rather than seeing our users resort to making a phone call or using IM when they need a "sure" method of communication) should be clear about this then, one appropriate value for the SSP record would be "reject" or something equally directive, perhaps "verify". And if we are to really seek to be clear on the Signing Practice in use, then perhaps we may even include a "none" value: none - The domain signs no email. unknown - The domain may sign none, some, or all email. all - All mail from the domain is signed with an Author Signature. reject (or verify) - All mail from the domain is signed with an Author Signature. Furthermore, 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 it if it does not verify. There are certainly valid reasons that a domain may request this higher level of requested interpretation - signature-based verification moves email towards an (optional) higher level of reliability and identity verification with legal and commercial implications. Douglas Otis wrote: >> 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. >> >> 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. This line of thinking is on target, though we really need to get better at using words our users will understand. "exclusive" is ambiguous, and I would argue, not an easily understood concept. "Signature did not verify" would seem to be an error message that could possibly be understood by a normal user in a DSN message. Sincerely, respectfully, -thom _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
