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. -- Sincerely Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
