[Sending this from my home domain that publishes dkim=all ADSP. All
those domains that are dropping messages that fail dkim=all probably
aren't interested in this message anyway :-) ]
Dave CROCKER wrote:
People who contribute to mailing lists shouldn't say dkim=all. We
argued this ad nauseam when we were hammering out ADSP, it shouldn't
come as a surprise to anyone.
[Mike Thomas wrote]
That is not true at all. They shouldn't be using discardable. "All" only
says what the sender does, not what the receiver should expect.
+1
[John Levine wrote]
They certainly shouldn't be using discardable. I would advise not using
all either, due to the observed tendency of people to pay way too much
attention to DKIM and ADSP failures.
I'm (obviously) not as much of a fatalist when it comes using dkim=all.
I believe there are things that one can usefully do, such as to "raise
the bar" on content filtering, if a message fails a dkim=all ADSP. Yes,
a lot of people are looking for ADSP to be a magic litmus test, just as
there are domains that drop messages based on SPF softfail. These
domains need counseling.
Folks,
To claim that one signs all mail is to imply that anyone receiving mail from
them should see a valid signature.
Hardly. I thought that it was you that was making the point all this
time that all SSP/ADSP could do is describe the sender's practices, and
could not imply receipt of a valid signature.
Mail sent through list servers invites the problem of receivers getting mail
that does not have the promised valid signature, since intermediaries are
re-posting the message and are free to make whatever changes they see fit.
Hence, saying -all for mail that goes through intermediaries which might
affect
the signature is inviting receivers to treat the received mail with hostile
prejudice.
Depends on what "hostile prejudice" means. If it means using other
filtering measures more rigorously, I'm fine with that.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html