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
