677 karma · joined July 5, 2017
https://dmarcwise.io
For comparison, I'm now using UpCloud which uses network-attached storage for all volumes and easily hits 10k IOPS (up to 100k with some tuning).
I certainly may have missed something while testing this so I'm happy if someone else wants to contribute and correct me if I'm wrong.
https://digital-strategy.ec.europa.eu/en/factpages/data-act-...
> Reviving this account to say: Almost everyone at Vimeo was laid off yesterday, including the entire video team. If you're looking for talented engineers, there are a few on the market.
> Unrelated to this incident, we were and are currently migrating our customer traffic to a new version of our proxy service, internally known as FL2. Both versions were affected by the issue, although the impact observed was different.
> Customers deployed on the new FL2 proxy engine, observed HTTP 5xx errors. Customers on our old proxy engine, known as FL, did not see errors, but bot scores were not generated correctly, resulting in all traffic receiving a bot score of zero. Customers that had rules deployed to block bots would have seen large numbers of false positives. Customers who were not using our bot score in their rules did not see any impact.
https://developers.cloudflare.com/bots/get-started/bot-manag...
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.
[1] https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
[2] https://mailarchive.ietf.org/arch/msg/dmarc/Sk6JnDlXH_MkM4xm...
[3] https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarc...
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.
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.
Unfortunately managed Kubernetes isn't coming soon: https://twitter.com/bebehei/status/1838119096254173348
https://www.reddit.com/r/hetzner/comments/14e8asj/object_sto...
I wrote about it here last year: https://matteosonoio.it/cloudflare-support/