,---
|5.3. Practice and Expectation Requirements
|...
| 2. The Protocol MUST be able to publish a Practice that the domain
| doesn't send mail.
'---
It seems some opinions expressed that 5.3 (2) could move from a MUST
category, with also some concerns raised that this requirement
conflicts with 5.4 (1) and even the title of the draft! Without
venturing into a discussion of various combinations of flags and
lists, it seems most strategies should have little trouble providing
this feature, whether it is a requirement or not. When protocol
purity is challenged, some may see a need to avoid policy that
indicates a general lack of email, rather than just a lack of using
DKIM, for a particular domain.
The handling of invalid signatures for various reasons will likely
have a fairly low probability of causing the message to be blocked.
While it is common for large corporations to use sub-domains within
their email's right-hand side address for their various divisions,
this has also lead to social engineering that replicates this
behavior and this occasionally thwarts filtering and deceives
recipients. These sub-domains can be domains that "NEVER SEND MAIL"
but still have domains at a higher level using DKIM.
When a possibly credible signature fails (keys are found for
example), a policy published for such a domain that asserts this
domain "NEVER SENDS MAIL" provides complete clarity that such
messages are in fact _not_ credible. If this policy were to say
"NEVER SIGNS MAIL" or "ALWAYS SIGNS MAIL" then of course this would
offer little clarity whatsoever, as signatures can fail for many
reasons. In this situation, the ability to assert "NEVER SIGNS MAIL"
policy is essential for curtailing a phishing attempt and DoS
exploits and should remain a MUST.
Strict handling of messages will be problematic even for domains
being heavily phished. Use of sub-domains to provide less strict
handling only reinforces the credibility and the likely success of a
sub-domain spoofing tactic.
The general goal of an assertion such as "non-compliant services are
not used" or "mail is never sent" for a particular domain allow for
more stringent handling of invalid signatures. These policies are
unlikely to be published by a domain that does not implement DKIM.
These policies however could be for a sub-domain of a domain that
does implement DKIM that is valiantly attempting to curtail phishing
traffic. This is more than "a nice to have". This is indeed required.
,---
|5.4. Extensibility and Forward Compatibilty Requirements
|
| 1. The Protocol MUST NOT extend to any other than DKIM for email at
| this time.
'---
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
