On Tue, Jun 21, 2022 at 9:54 PM Dave Crocker wrote: > Within the NIST context, this might qualify as a kind of 'user', but > resolving that 'might' would indeed get into quibbling.
Agreed. > None of the relevant systems have C-R as a component, so I'm guessing > you mean this as an exemplar of the background stuff that happens > magically, to get an actor to be authorized to use the domain name. The domain name is a bit of a red herring with this proposal. The actor (sender) is authorized by the receiver, period. If the actor starts sending spam, they get docked. The definition of spam is by the receiver, which might use DKIM or simply say "new domain seen with this key", let's throttle these messages until we are sure. > None of these specs and services say anything at all about 'reputation'. They do. RFC6376 <https://datatracker.ietf.org/doc/rfc6376/> DKIM: 6.3. Interpret Results/Apply Local Policy It is beyond the scope of this specification to describe what actions an Identity Assessor can make, but mail carrying a validated SDID presents an opportunity to an Identity Assessor that unauthenticated email does not. Specifically, an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation. Conversely, unauthenticated email lacks a reliable identifier that can be used to assign trust and reputation. It is reasonable to treat unauthenticated email as lacking any trust and having no positive reputation. RFC7208 <https://datatracker.ietf.org/doc/html/rfc7208> SPF: 8.3. Pass A "pass" result means the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity. This is further discussed in Appendix G.1. > That entire concept is entirely outside these specs. The hope is that > these specs produce activities that facilitate developing better/easier > reputation assessment, but the specs themselves do not participate in > this process. I disagree. There are many other words, like trust, that are used to describe reputation, e.g. RFC8617 <https://datatracker.ietf.org/doc/html/rfc8617> ARC: ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. The words between the lines are you should (not SHOULD or SHALL) use ARC to manage reputation. > What I meant by foundation is that these techs aid in developing a base > of data that is noise free or at least has a lot less noise than when > the domain name is unauthenticated. So DKIM keys can be used in the proposed scheme. That's fine by me. What I would like is a protocol for bootstrapping trust (WoT), handling complaints, and querying reputation. DKIM doesn't solve that problem. If it did, we wouldn't be having this conversation. This list would be about interesting things like bugs in mail servers. Instead, most of the emails are about fixing reputation/delivery problems. Rob
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
