Both the "require DKIM" and the mailing lists problem were discussed at length by the working group, with many having opposite strong opinions, so in the end the only consensus that was reached is a trade-off that left everyone unsatisfied.
There's hope that the mailing list problem will be solved by DKIM2 [1], since ARC has the problem of trusting the intermediaries.
On `pct`, you're right in theory, but it seems that implementers didn't get the message. From the mailing list [2]:
> That's how we intended it when we wrote that, and that's how early
implementations did it. But maybe this is the lesson: People have inferred lots of different things
from that rather straightforward definition, so maybe it's more ambiguous
than we realized all those years ago.
And the draft says [3]:
> Operational experience showed that the pct tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.
I agree that replacing it with another tag is such a confusing and unnecessary change, though.
> the only consensus that was reached is a trade-off that left everyone unsatisfied
Yeah, that is sort of what I assumed :(
> other values varied widely from one implementation to another.
IMHO the best solution to this is:
1. Clarify the specification so that future implementations are more likely to be correct.
2. Add a note that only pct=100 and pct=0 are recommended as the other values are inconsistently implemented. I would even rather go as far as calling all other values deprecated than add two new values that mean the exact same thing but will force implementations to support both and open this chicken and egg of you can't really switch to the new one because not everyone will support it. Just say that the pct flag has two possible values 100 and 0.
Yeah, that was one of the controversial parts. I updated that paragraph to be more precise.
The draft says:
>It is therefore critical that Mail Receivers *MUST NOT* reject incoming messages solely on the basis of a "p=reject" policy by the sending domain. Mail Receivers must use the DMARC policy as part of their disposition decision, along with other knowledge and analysis. "Other knowledge and analysis" here might refer to observed sending patterns for properly-authenticated mail using the sending domain, content filtering, etc. In the absence of other knowledge and analysis, Mail Receivers *MUST* treat such failing mail as if the policy were "p=quarantine" rather than "p=reject".
So basically `p=reject` doesn't actually mean reject anymore and receivers should instead treat it as quarantine by default.
The document then goes on by saying "nobody will listen to us anyway", which is an interesting thing to read in what will be a Proposed Standard:
>In practice, despite this advice, few Mail Receivers apply any mitigation techniques when receiving indirect mail flows, few organizations consider the effect of DMARC policies on their users' indirect mail, and it is unlikely that any advice in this document will change that.
And they are right because their recommendations about handling a reject policy are idiotic.
Orgs want a real reject policy, full stop. If we wanted our email to be quarantined... We would fucking set it a quarantine.
This is seriously one of the stupidest things I've read, in a spec, in a long time. It's right up there with whatever dumbass decided BIMI VMCs must not be used for reputation.
VMCs require a verification of personhood, trademark, and a non trivial momentary investment. But why use this reputation being served up on a silver platter to email providers when we can instead keep using our blackbox of IP reputation that already hasn't been working well for a decade.
I don't know what people use object storage for, but R2 is missing lots of features and it's not a replacement for S3 in many cases.
For example: no regions, no replication (and no AZs either), limited lifecycle management, no versioning, no MFA protection, no intelligent tiering, no customer encryption, no IAM, etc.
Where does it say they don't have the keys? It literally says they store the keys in their own datacenters. Which is obvious anyway, otherwise the API wouldn't be able to return the unencrypted data.
If/when we are able to provide object storage in the future, we will announce it on our social media channels, our customer forum, and our customer newsletter. We are also always very grateful to anyone who posts our good news here on HN. --Katie
The thing is that Cloudflare has no proper channels. Anyone that has tried Cloudfare's support (even as a paying customer) knows that it's almost impossible to get a sensible answer to anything.
Italy built the Leonardo HPC cluster, it's one of the largest in EU and was created by a consortium of universities. After just over a year it's already at full capacity and expansion plans have been anticipated because of this.
https://openai.com/enterprise-privacy/