I don't agree about that ZFS issue. Using whole disk isn't inheritantly wrong. When you have data pool separated from boot disks, using whole disks is better. No need to create partition table, when replacing disk. No worring over block alignment.
My take, as a postmaster for hosting company, who don't have any sympathy to gmail (that should be visible from my comments history):
Message-ID is absolutely MUST in production e-mails. You can send your test stuff without it, but real messages always have it. Not having Message-ID's causes lot of fun things. All somewhat competent software is capable to add Message-ID's, so lack of it is good indication of poorly made custom (usually spamming) solution.
Rspamd and spamassassin have missing MID check in their default rules, I am sure that most antispam software is same.
Your casual use of the word MUST is not the same as a standard document's use of the word MUST. Your real world experience is entirely irrelevant to the conversation about what the standard requires.
Why? If I'm writing a mail receiver, and I'm told there is some unique ID generated by the sender in a loosely specified way, the first thing I'm doing is ignoring that value forever. One lesson surely most everyone learns in CS is that unique identifiers are maybe unique to the system generating them, but to rely on foreign generated IDs being unique globally is a terrible idea that will break within the minute.
So at that point the ID has no value to me except being obliged to carry it around with the message, so maybe the originating system can at some point make sense of it. But then there is obviously no reason to ever reject mail without it, it's an ID valid for the sender and the sender didn't care to include one, great, we save on storage.
>Why? If I'm writing a mail receiver, and I'm told there is some unique ID generated by the sender in a loosely specified way, the first thing I'm doing is ignoring that value forever. [...] So at that point the ID has no value to me
Your framework of analysis is based on someone else's database key ids being irrelevant to you. That's true.
But another framework of analysis is tracking statistical correlations of what spam looks like. Lots of spam often don't have message ids. Therefore it's used as a heuristic in scoring it as potential spam. That's why other postmasters even without SpamAssassin independently arrive at the same answer of trying to block messages without a message id. Example: https://serverfault.com/questions/629923/blocking-messages-w...
MID-s are used by MUA-s for referring earlier messages, tracking answers and so on. So any software expecting dialog (messages coming back) needs to deal with MID-s correctly. Missing MID-s show that said communication is one direction, because broken dialog has not been problem.
Testing with different ISP-s involved ISP provided resolvers and directly using archive.today nameservers. I know that archive.today has previously blocked common public resolvers, like 1.1.1.1. That case they replied with 127.0.0.4 or other loopback IP addresses.
Expanding the address size did require a larger field but didn't require wiping out the existing addresses or anything else. We got the new packet header and near ubiquitous support for it, but that's not everything.
Thats true for several other speeds too. 100GE first generation was 10x10GbE, second generation was 4x25GbE. 200GE first version was 25GbE based and so on.
If you add additional piece to chain, chain becomes weaker, not stronger
> get AI-DoSed
Thats not that common. There are specific industries prone to DDoS, like gaming, but your average site don't get DDoS-ed. Then again CF free service really don't protect your site from DDoS. I have seen several times CF becoming source of DoS (not caching or denying malicious requests) and if back-end is on shared infra, CF goes to firewall.
That name NDP looks little bit confusing. For example, wikipedia article https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol shows NDP as Neighbor Discovery Protocol, even when RFC-s themselves don't use that abbreviation.
Yes, it was a poor choice of name. It was originally just a placeholder in the htsim code, from New Datacenter Protocol, but we avoided choosing a better name for too long and had already talked about it as NDP to enough people (especially research funding people) that we decided it would be confusing to change. With hindsight, we should have changed it earlier. Later on we did change the name of its derivative to EQDS.
That article had weird statement about PCI-X: "It did not see wide use with PCs, likely because Intel chose not to give the technology its blessing, but was briefly utilized by the Power Macintosh G5 line of computers."
I don't know, what they meant with blessing, but Intel server motherboards had PCI-X slots and this was common bus for servers/workstations. Mostly used by SCSI and RAID controllers, high-end network adapters.
The bit before it mentions it being designed for high-end workstations and servers, i.e. not PCs, but I do agree that it seems to imply Intel never used it at all, rather than rather the standard wasn't used in PCs (Intel or otherwise).
reply