John Levine wrote:
The reason for saying DKIM, here, was to make sure the reader knows
it's ok for other DKIM-Sig values to be delivered. Without the DKIM
reference, the sentence would seem to be so broad as to have truly
nothing to do with DKIM.
My concern is this: what do identity assessors use today? An IP
address. They might want that tidbid of information as well. How,
then, not to exclude it?
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.
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.
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.
And as long as this mindset persist, you are going to get the funny
looks from many disciplines in this market - mainly SMTP vendors!
The funny thing here, we don't POLICY, yet we dictate policy. John,
you have no control over what people will use and how it will be
blended. The fact is, envelope comes first, not payload, so you will
always have this to deal with.
NOTE WELL: This list operates according to