On 6/22/2022 4:21 PM, Rob Nagler via mailop wrote:
On Tue, Jun 21, 2022 at 9:54 PM Dave Crocker wrote:
> 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.
OK. So you are suggesting something that is independent of
spf/dkim/dmarc/arc? That's fine, I guess, but I thought this thread was
discussing those.
> 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.
Sorry my writing was lax: By 'not saying anything', I meant not saying
anything normative/actionable about the details of assessing reputation,
per se, or that otherwise constitutes actionable specification.
The text you quoted pretty much reflects the statement I made here.
(What a surprise.)
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.
Again, this asserts authenticity to the use of the identifier, rather
than a statement that the actor using the identifier is to be treated as
having a good reputation.
> 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.
If someone is tasked with buying good quality eggs, milk, and the like,
they have a role in the creation of the pancakes (or waffles, or pasta,
or..., but not really.
With respect to the assessment of email reputation, these specifications
are similar to that distinction.
The words between the lines are you should (not SHOULD or SHALL) use ARC
to manage reputation.
'manage reputation' is normally taken to refer to an assessment of
reputation. None of these specification specify that assessment
process. They provide some data that is hoped to be used as input to
the assessment process, but say nothing about how. No technical details
or even guidance.
> 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.
So would many folk. And they have for roughly 30 years.
So far, efforts in that direction have not scaled well and none has
attained any type of standards status.
It's possible that this is a difficult problem...
DKIM doesn't solve that problem.
DKIM doesn't pretend to.
d/
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
