Thank you for your reply. I wasn't looking for an op sec answer but more of a technical concern around design of the product - i.e why didn't they think of it, or if they did what made them not solve the problem with other tech solutions (dummy prints, zero out, patterns, or even a thermal or physical recycle program). At least communicate this is possible like they addressed the digital safety side of it.
I don't believe it would take too much lift to automate this with a scanner+some software.
Thank you. I wonder if they considered a dummy cycle on a relevant media type after the print to zero out what's left over. Specially if some other patterns could be introduced to randomize what's left.
Ken is a good friend in the industry and always has the best interest of email security at heart. This may have been an architectural oversight but they are not wrong that SPF is surely a cause for concern, as is misconfigured DNS based trust and recertifications via arc (which was supposed to solve a problem for forwarding scenarios).
The centralization of email services to a handful of providers basically has led to multihoming of millions of domains that open SPF auth to the same handful. Any integrations by them or changes to existing stack can cause issues to pop up, because delegation of sending rights isn't strictly auth controlled. The same also happens with dkim delegation to saas providers who share backend keys across other customers of theirs and if their API is open to experiment (or an account gets popped) then the customer domains are possibly at risk.
Email is hard to do right. No auth no entry should be the default. But majority of domain owners aren't very good at figuring out how to secure things, or have business/product interests that are a priority, specially when delegated and authorized to third party senders on their behalf.
I had the privilege of working on some of this during the UUnet days. The pride I felt in "keeping the internet up" as a backbone while no-one in public recognized where I worked was admittedly amusing. Even in career interviews later, including today, I rarely meet anyone that knows or appreciates that exposure. Those formative years being exposed to networking and services in general from such amazing peers are extremely fond and foundational memories of mine.
FWIW although this article says many had oc48s by early 90s I can tell you that wasn't a thing till much later. The fact that I have a FTTH node at home that's faster than that today a severe fraction of the cost, and consumer 2.5g switches below $200 just blows my mind. The planning required during migrations alone for all failivers required calculations back then and I can unplug a cat6 today without sweating
Remembering back to the uucp days and when certain OOB nodes came back up after outages, this is precisely why email as a standard can handle delayed delivery and MX records have preferences for relays that can queue for future delivery.
You can always sign based on specific rules via your MTA to sign some and not sign others. You can also send from many sender's (say allocated by spf allow rules) that aren't signed at all but matches the IP ranges allowed.
Have been using this for a few years and the most amazing usecase is being able to switch between multiple chrome windows, just like windows used to let me do "same app, different window instances", with a preview!
The other thing that works well with this for a life upgrade on a mac is finicky (GitHub.com/johnste/finicky )
this was one of the main reasons I acquired the kindle keyboard :)
worked excellent as an emergency device when you _needed_ to rebook travel things with nothing else around.
There is a deep misunderstanding of the intricacies involved in actually delivering an email to the inbox, repeatedly, with the lowest risk. What you are paying for with ESP services is mostly that expertise.
This is what I would do as well. Coming from a hosted mail solution (one of the earliest in the Industry as part a of the initial Dotcom bubble) that cost 10000x5+thensome as much to run, albeit with higher send rates and clusters, It totally makes sense to use ec2 for these needs today.
I don't believe it would take too much lift to automate this with a scanner+some software.