Yes, but they are still effective at preventing spam from spammers who are pretending to be others.
5,702 karma · joined June 9, 2017
This is like spam filtering. I'm an anti-spam advocate, so the idea that most people can't discuss spam because even the discussion will set off filters is quite old to me.
People who apologize for email content filtering usually say that spam would be out of control if they didn't have that in place, in spite of no personal experience on their end testing different kinds of filtering.
My email servers filter based on the sending server's configuration: does the EHLO / HELO string resolve in DNS? Does it resolve back to the connecting IP? Does the reverse DNS name resolve to the same IP? Does the delivery have proper SPF / DKIM? Et cetera.
My delivery-based filtering works worlds better than content-based filtering, plus I don't have to constantly update it. Each kind has advantages, but I'd rather occasional spam with no false positives than the chance I'm blocking email because someone used the wrong words.
With web sites and WAF, I think the same applies, and I can understand when people have a small site and don't know or don't have the resources to fix things at the actual content level, but the people running a site like Substack really should know better.
I respect the fact that the Sentry people are honest about their teetering tower.
Also, it doesn't look like OpenBSD has binary packages for 32 bit PowerPC:
https://cdn.openbsd.org/pub/OpenBSD/7.7/packages/
Although I do see packages for OpenBSD 7.6 from last year:
https://cdn.openbsd.org/pub/OpenBSD/7.6/packages/powerpc/
There's always NetBSD, though, which has tons of binary packages and which isn't going to be dropping architectures like PowerPC any time soon :)
I keep a machine which has sshd listening on the IMAPS port (993) for when I'm traveling. It's amazing how many free networks don't allow ssh, but with -J and sshd on port 993, that really doesn't matter.
I wholeheartedly disagree. When given the choice between our ISP's DNS, DNS served by a for-profit company that wants to be a monopoly (such as Cloudflare or Google), or running your own DNSSEC enabled, fully recursive DNS server, you should absolutely run your own, if you're even slightly technical.
If your network is only IPv6, then you already have plenty of issues with general Internet use and should know your caveats. If you're using only IPv4, then you know to run BIND with "-4".
Either way, if you only have one or the other, then you have much more control over what happens when you run your own recursive resolver, regardless of whether it's BIND, Unbound or something else.
The author may've made some money being slightly passive aggressive about running BIND and pretending to not know about "-4", but that's more a self own than a slight on BIND, in my opinion.
1) How does AVID selling Blackmagic hardware make that a dependency? You can just as easily buy Aja hardware. "This depends on that" means it requires it. AVID systems do not require Blackmagic hardware at all. If you think they do, please explain.
2) Bin locking and media sharing (client specific paths in "OMFI MediaFiles" and "Avid MediaFiles") is a flag that is either off or on. That has nothing to do with all of the other things that have been sold to you as "special" about AVID storage.
For instance, link aggregation has been built in to macOS since the early days of Mac OS X. Also, it really doesn't matter. If you want something that literally does 4 gigabytes a second, you can do that all sorts of ways with current Macs - no need for multiple NICs.
Anyhow, speed is largely irrelevant for editing systems. The only time speed matters is if the storage can't keep up. You're not watching video at 2,400 frames per second as you're scrubbing through video at 100x speed, so people who are concerned with "800 MB" (you're not even saying per second, or anything like that) are no different than the people who want the wanna-be muscle car that puts out 500 horsepower but that are just going to and from the store. Who cares? If you care, you know. If you have the need, you know. If you're working on 4K uncompressed, you're not doing it on shared storage, anyway - that's just silly. But if you REALLY need to do 4K uncompressed on shared storage, guess what? You're not using AVID, because it can't support that :)
Otherwise, "800 MB" is just a sales number. I just build a NAS for less than $2500 that does 1.2 gigabytes per second, and I wasn't even trying to make it fast.
> i have used and still use the 3rd party "bin lock" solutions when I have special cases, and i can promise you, an ordinary file server does not compare when many clients are hitting the storage.
Those are two different things. If you choose to conflate them, that's up to you, but I can easily show shared storage that makes AVID's look outright pokey, particularly with twenty clients, just as I can show you software that turns the AVID bin locking off or on, so you're not fooling anyone by trying to suggest that all bin locking file servers are somehow inferior, or that they're inferior because they support bin locking, or whatever way you want others to think they're connected.
They're separate things. You do understand that, right?
I hope you take away from this that there are more products than just the half a dozen that are most common, and that products outside of the post world often make products in the post world look ridiculous, if in part because the ones in the post world are a generation older and multiple times the price. But because people in the post world don't know any better, they more often than not spend literally ten times the going price to get something with an AVID sticker on it, even when you can show them that the AVID product is just a rebadged Seagate storage array or whatever.
For instance, DNS handling and NTP keep coming up over and over, and it's almost becoming a meme. Why? Because it's the Microsoft mentality - we (the systemd people) know better than you (you're just the machine's owner and administrator), and we'll take care of this. You want to? Not without a fight.
So no, it's not FUD when reasonable people can't give reasonable answers for how to do something that's otherwise reasonably simple.
One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously. The ifconfig / ip example you use is good: Why? If we look at the reasoning given, it was that they didn't want to make big changes to ifconfig, so they made a whole new set of commands, even though the BSDs have extended ifconfig many times.
So that ends up meaning that how-tos just don't work any more. Imagine if you want to write a how-to these days where you're telling people how to do something using standard ifconfig and now also need to add ip. This is how you do DNS on standard Unix(like) systems, and now you have to explain multiple iterations of systemd. This is how you add software, but now you need to have separate instructions for apt, yum, dpkg.
Having administered Ubuntu for others, even going from version 18 to 20 or 22 means that how-tos no longer work, scripts need to be modified, systemd handling has to be updated, et cetera.
This is why I will always choose a BSD if given a chance. Pointing to a less messy Linux (like Void because it doesn't use systemd) isn't good enough when clean, well thought out systems already exist.
I can compile all sorts of things on my Mac LC III+ with 36 megabytes of memory. Sure, Perl takes nine days, but it works. What other language can actually be used on a machine with such little memory?
The number of wifi networks that're running around us has gotten so crazy that it's no wonder we all need wifi-6 to even get reasonable speeds. I'm the kind of person who goes around and disables wifi absolutely everywhere possible, so this is good to know, but what'd be even better is if devices stopped running wifi networks behind our backs. Sigh.
Second, please tell me how the fact that you can use no video interface card or Aja means you're dependent on Blackmagic.
Third, please tell me how bin locking on ISIS / Nexis is different than bin locking on third party shared storage with the AVID sharing flag turned on.
You've offered literally no searchable facts. If I search for anecdotes about how ISIS / Nexis are different, I'm only going to get marketing fluff.
So offer something of substance. Claiming someone is wrong without even saying what they're wrong about is not how any of this works.
I think you've been sold a bunch of ideas. For instance, Avid has no dependency on Blackmagic. They use Open IO, which means you can use any card that supports Open IO, whether Aja, Blackmagic, Bluefish, Matrox, whatever.
Nexus / ISIS isn't special. The flag is literally just a flag that tells Media Composer to enable bin and media sharing. It can be enabled on any kind of sharing - NFS, AFS, SMB, et cetera. For example, check out Mimiq software for enabling it wherever you want.
AVID hasn't been at the forefront of video editing since the Avid/1 / ABVB days. They sell a reasonably usable program with horrible hardware (since Meridien hardware - it's good they finally let us use other hardware such as BlackMagic), but never truly fix large problems. People therefore stay on a specific version of the software for ages, because everyone is scared of new and different bugs.
AVID's shared media offerings are tenfold the cost of other storage options simply because they have a flag on the mounted volumes that tells Media Composer to allow project and media sharing. "800MB pr box sustained" means nothing because anyone can do that easily with commodity hardware.
In other words, AVID is milking their cash cow and they really don't innovate or even try to offer a good product.
Apple, on the other hand, destroyed their professional editing products, then replaced them with decent tools, but ones that are worlds different. Many people have mixed feelings about this. On the other hand, if you want to edit 8K ProRes, Final Cut Pro makes it simple on any ARM-based Mac.
I sent this more than two weeks ago:
Date: Wed, 12 Mar 2025 22:56:55 +0000 (UTC)
From: John Klos <*******@klos.com>
To: apple.com-Admin@anonymised.email, apple.com-Tech@anonymised.email, Apple-NOC@apple.com, d*******@apple.com
Subject: Issue with Apple's SMTP delivery
Hello,
I've had several issues reported about email delivery from Apple. The error they have in common is this:
Mar 12 21:38:17 daisy sm-mta[28249]: 52CLcCoi028249: ruleset=check_mail, arg1=<*******@me.com>, relay=p-west1-cluster6-host7-snip6-8.eps.apple.com [IPv6:2a01:b747:3003:204:0:0:0:47], reject=550 4.1.8 <*******@me.com>... Access denied. HELO does not resolve. (HELO p00-icloudmta-asmtp-us-west-1a-1.p00-icloudmta-asmtp-vip.icloud-mail-carry.svc.kube.us-west-1a.k8s.cloud.apple.com)
Looking in to this, the resolution of "p00-icloudmta-asmtp-us-west-1a-1.p00-icloudmta-asmtp-vip.icloud-mail-carry.svc.kube.us-west-1a.k8s.cloud.apple.com" results in this list of MX:
mx-in.g.apple.com
mx-in-mdn.apple.com
mx-in-hfd.apple.com
mx-in-ma.apple.com
mx-in-rn.apple.com
mx-in-vib.apple.com
mx-in-rno.apple.com
mx-in-sg.apple.com
All but two of these resolve to A records.
Two of those, though, resolve to more MX:
host mx-in-rno.apple.com
mx-in-rno.apple.com mail is handled by 10 mx-in.g.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-vib.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-rno.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-rn.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-hfd.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-sg.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-mdn.apple.com.
mx-in-rno.apple.com mail is handled by 20 mx-in-ma.apple.com.
host mx-in-mdn.apple.com
mx-in-mdn.apple.com mail is handled by 20 mx-in-mdn.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-sg.apple.com.
mx-in-mdn.apple.com mail is handled by 10 mx-in.g.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-vib.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-rn.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-hfd.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-ma.apple.com.
mx-in-mdn.apple.com mail is handled by 20 mx-in-rno.apple.com.
This loop is a mistake and should be fixed.
Additionally, RFC 5321 section 2.3.5 says that the name given in an EHLO / HELO greeting should be an IP literal or a primary host name ("a domain name that resolves to an address RR"). The name given in the EHLO / HELO exchange does not resolve to an address RR; it only resolves to an MX. While this is technically incorrect, the looping MX is the real issue. However, if you're fixing the looping issue, you may want to consider fixing this issue at the same time.
Please look in to this, and please let me know if you have any questions or need any additional information.
Thank you,
John Klos* WHOIS is effectively destroyed.
* Companies like Cloudflare actively protect known spammers & scammers, and have made abuse reporting time consuming and error prone.
* Consolidation of most email to several large players means filtering them causes problems.
* Large delivery companies such as Sendgrid, Salesforce and Google basically do nothing about reported abuse.
Yes, most spammers these days that set up their own domains have tools to make sure DKIM, SPF and DMARC are all good, but consider that we can't know anything about these spammers: TLS certificates no longer contain contact information, large providers don't provide useful WHOIS, don't forward abuse complaints, have no clue what an SOA record is, and so on.
The way things should work is that we get a spam, we see the network from which the spam came through WHOIS, we forward the spam to their abuse address or the address they list in WHOIS, and we're done.
The way things work is that they don't have working information in WHOIS, they ignore the abuse complaints, they act like they don't know what to do with it, or they reply with a form email saying to go and use a web page where it takes time and work to paste in each part of a spam.
I blame the large companies who do this. Make reporting abuse difficult and you'll get much less reported abuse.
For instance, the [sendmail bat book](https://www.oreilly.com/library/view/sendmail-4th-edition/97...) originally talked about all sorts of ways to deal with resource limits, particularly memory, because this was often an issue with servers in the early '90s. Later, memory became cheap and huge, so discussions about this were removed from later editions.
Even when memory ceased being a limitation, though, learning about how to monitor and what to do about heavy resource usage remained important, so the removal was an overall loss. I wish that O'Reilly would make available for free the things they removed from later editions.
I wish I'd've had the money and space to buy the original editions of many of the animal books. I figured they'd live at the bookstore until I did, but then bad things happened, and now bookstores are rare. Perhaps one day I'll find some.
When you try to use bullshit to make excuses, people notice.
After that, they said the MMU isn't important, and that being fully m680x0 compatible isn't really as important as other things.
It's easy to handwave about how costly / difficult a thing is when you're ignorant, and you're preaching to others who are also ignorant about the subject matter, but people who actually understand programming can read the bug reports, the read about debugging methods and results, about the tests, et cetera, and can deduce when an action really can't be anything but monumental ignorance or, more likely, deliberately chosen. The ignorance of the apologists isn't equal to the actual experience of the people doing the work.
"triggering script hang/out-of-memory issues through what seems to be deliberate behaviour when the script does not pass a collection of Web API checks (since the same behaviour was observed on their "officially supported browsers" as well if the user-agent was spoofed to Pale Moon!)"
I'd love to see how those people try to spin this.
Also, this is a perfect example of how large companies can both try to create the illusion of being open - several high profile Cloudflare people post on this site regularly - yet there's no way to actually communicate with a human who can do more than copy and paste from a script, unless you're a paying customer. No company should get to operate as a gatekeeper for much of the world yet have zero methods of communication unless you pay them.
They did this with their Blu-Ray players about five years ago:
https://www.theregister.com/2020/07/18/samsung_bluray_mass_d...
Each device had to be shipped to a repair center because they needed to directly re-flash the flash storage. The issue with the Blu-Ray players was that an update caused it to get in to a state where it would boot loop before it even got to a point that anything could be done, manually or otherwise.
What we don't know yet with this issue is whether the devices are booting enough to apply another firmware update. It may be possible to do this, fixing this issue. If that's the case "bricked" would be technically incorrect, but for now, it's not a wholly inaccurate term.
It is definitely always possible.
> may not be affordable
You hired the wrong person / people, then.
> may degrade the overall user experience
Which is exactly what Cloudflare does, although most people would make a distinction between degrading an experience and outright causing something to not work at all.
For a company that has so many of their employees on this site, they sure do seem to be clueless when their supposedly amazing tech marginalizes people or otherwise creates issues. Even when they respond in these threads, it takes ages for them to address things, and often the problems are never permanently fixed and come up again after some time.
It reminds me of this fortune(6):
As far as we know, our computer has never had an undetected error.
-- Weisert