Dear ietf, spfbis, and repute, Until an identifier is linked with the source of an exchange by way of authentication, it must not be trusted as offering valid reputation input. For example, a valid DKIM signature lacks important context. A valid DKIM signature does not depend upon actual sources or intended recipients, both of which are essential elements in determining unsolicited messages or even whether the message is valid. SPF only offers authorization of Non-Delivery Notifications, and can not be considered to represent actual sources. Three different authors attempted to repair DKIM's header field issue within the WG process but repairs were rejected. As with the DKIM WG, being right about likely outcomes will not always prevail in offering safe and dependable protocols offering a well understood services. The initial intent for DKIM was to help prevent spoofing, but that effort ran astray with desires to extend DKIM beyond its capabilities. Flexibility allowing DKIM to be relayed removes typical rate limitations protecting a domain's reputation from occasional lapses or from messages easily taken out of context. Since a valid DKIM signature may not preclude prepended header fields, this raises important questions. When such spoofing does occur, which domain's reputation should be affected? A domain too big to block that does not add the non-existent header field hack? A domain being spoofed to improve statistical filtering? It is clear those actually responsible for abusive exchange may be ignored by these strategies. Better solutions at enforcing security and offering fair reputations are readily available. DKIM can not be used to establish reputation without a link with those responsible for its transmission. Neither DKIM nor SPF established those actually responsible for the exchange. Today, unfortunately, the only thing that can be "trusted" in email is the ip address of the host connecting to the mail server - and even that can be subverted with BGP injection. Regards, Douglas Otis |