John,
I want to not constrain the document to the point where it does not
reflect the complexities of the reality in which we find ourselves.
You've stated that reality below, by the way. A very simple decision
tree one could easily envision is something along the following:
[Sender]---->[Signer]-->[...]--->[verifier]-->[DBLs]--->...
...-> [pass]-->[dkim|spf|other]-->[assessor]-->[...]-->[mda]
Or, put in other terms:
[Outlook]---->[Exchange]-->[...]--->[sendmail]-->[RBLs]--->...
...-> [pass]-->[milters]-->[spamassassin]---->[mda]
These diagrams aren't perfect, but I think the illustrate one approach
we see in the wild.
Standards can't compel anyone to do anything. The most they can do is
to tell you how to make it most likely that you will interoperate with
everyone else. That's why rules like nobody else can sign my mail are
silly and unenforcable, and why I carefully worded the discardable bit
in ADSP to make it clear that it's advice, not a command.
We'll come to that point. You and I have a draft to write, still, by
the way, about DNS and ADSP experiences.
As Dave reminded us yesterday, the primary goal of DKIM is to provide
a better handle than IP address for managing mail. The best way to
make that work is to agree as clearly as possible what that handle is.
We tell senders that's the handle to put in signatures so receivers
recognize them, and we tell receivers that's the handle to check to
best know who's trying to talk to you. Assessors will certainly do
all sorts of other stuff as well, but this is the best advice on how
to interoperate with DKIM.
Right. And so I am comfortable with the changes Dave proposed.
With specific reference to DKIM, what I most want to discourage is
awful IP/domain hybrid hacks like only validating a signature if the
Sender-ID or SPF passes. So our interop advice is when you're thinking
about DKIM, don't think about IP addresses.
While I understand your desire, let there be room for people do try what
what works, and to adapt to circumstances. You might say that this does
not sufficiently constrain the situation from an interoperability
perspective, but I am concerned that doing otherwise will cause this
work to be ignored due to pragmatic real needs, the obvious case being
the converse of what you wrote above, where a DKIM signature check is
made only when an SPF check fails. Only actual data and analysis will
tell you whether that order is reasonable.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html