you’re welcome.

what i’ld suggest… a general rule that i like to always follow is to use a test system for everything new. but that does not need to be a full separate system every time.

lets say you have your mailbox and want to try getting new mails from it using fetchmail. first you can use uidl mechanisms to only fefch every mail once and besides that leave them all on the server, but i like it a bit more secure: create a second email adress/account at your mail providers service only for testing. thus you can do whatever you like to to test the mechanisms only without even touching your real inbox (maybe even fill it up with large emails and look how the system reacts, i once had an email account with a cheap provider that deadlocked the inboxes when full…). then when everything is as you want it, switch the account and password (or create another config file for fetchmail) and your’re done. every change (not only fetchmail things) could go tested this way before going live with the changes. filtering could be done with procmail for example, but when the mda that is called by procmail somehow exits with success when the email really isn’t delivered, then the email might get lost forever depending on the settings of course. so fiddling with new stuff always carries the risk of not fiddling correctly ;-)

have fun !

Its possible to tell your mta (like postfix) to use another mta for all mails, or only some domains etc, so using a third party to play the internet facing service then getting the mails by fetchmail, storing them in a dovecot server is easy. on the sending part you could use your standard email client (i.e. thunderbird on pc or k9-mail on smartphone) to send it to your postfix instance that also sits on the server hosting your dovecot service. the mta there takes the mail and delivers it by rules which could just be using the mta of your freemailer using username/password of your account for all outgoing emails. i am doing this but the “external” mail system are my servers as well, i just don’t want emails to stay too long on VMs in the datacenter where i have no access to the physical disks in case something goes wrong.

a raspberry pi is sufficient for such a aetup (i am using a pi4 currently but for emails only i’ld say a 3 or older would do too), adding a disk via usb makes storage huge and cheap then, i use two usb ssd’s in a raid1 for storage… that server could be only accessible through vpn if you whish, depending on your skills and needs (i mainly use ssl client certificates that are supported by k9mail and thunderbird so it fits seamless to be connected through a haproxy that authenticates these before proxying the plain connection to the pi) clients like thunderbird can offline-store all emails (configure download-or-not per imap folder) making searches easy and quick while my k9 client can search locally or on the server if needed.

maybe adjust maximum mail size of your own mta to exactly match (or slightly less) that of the freemailer you use to prevent surprises of big but later then unsent emails.

its possible to have a nextcloud instance on that same pi that acts as an email web mailer just in case of (i really dont need it, but i’ve set this up anyway). nextcloud is also great for syncing/backup files pictures, contacts notes todo lists and calendar of your phone (where i use davx5 opentasks and foldersync for). there are other webmailers available but installing /using nextcloud is not a too bad idea either ;-)

i suggest also setting up some automatic offsite backup with snapshots of that pi then to cover emails and the setup and its configs ;-)

yeah! you beat me to it 👍

guess this instance is lost, lets restart the matrix!

https://youtu.be/rNdpvNH1yi8?si=GPLbzrNxnwKNCfHm

with a microscope

if it was at least a scanning tunneling one, then yes, good job 👍 🤪

well there is plenty of what is possible to try. but unless one had looked at the real cause i’ld suspect one of apples hardware backdoors to cause the crashes like if the backdoor doesn’t work, crash the kernel, so we never loose control over the sheeapple thing. or more realistic if you want:

First maybe just crappy hardware:

There is a reason why i suspect apple’s hardware, cause my shitty macbook at work should(!) go to something like hibernate, sleep, or its spyveillance-only mode when closing the lid, and it should also lock the screen when doing so, the actual results seem pure randomly choosen, sometimes the sleep mode survives the weekend with lots of accu left, sometimes its completely depleted and i even have to charge it for a while before it has enough power to show the charging logo. for security reasons i have to manually lock my screen, verify it and then close the lid, which is pure annoy. this could just be buggy hardware, a sensor so broken that reading its inputs directly could crash any OS that assumes i.e. no division by zero, pointers to nonexisting ram or whatever, and maybe apple just knows what faulty measurements mean what (but cannot make that stable too, only no crash occurs)

secondly with a hardware backdoor:

https://www.kaspersky.com/about/press-releases/2023_kaspersky-discloses-iphone-hardware-feature-vital-in-operation-triangulation-case

“The discovered vulnerability is a hardware feature, possibly based on the principle of “security through obscurity,” and may have been intended for testing or debugging. Following the initial 0-click iMessage attack and subsequent privilege escalation, the attackers leveraged this hardware feature to bypass hardware-based security protections and manipulate the contents of protected memory regions.”

which is that (some/all?) iphones have at least one memory page where one only has to accidently or intentionally write something into it, that could trigger the backdoor feature to let you choose which memory address to overwrite with what bytes, bypassing every(!) security mechanism in hardware AND of course those made of software too. that is how i understood documentation and presentations about it. now apple said they “fixed” it in software, from what i remember that fix was just a “os preventing apps from writing to that memory backdoor page” thus not a fix but only a mitigation, while “fix” is more a lie than only misleading words to just pretend it wasn’t permanent and unfixable. let us assume that linux does not include hardware backdoor mitigations for apple devices AND that apple placed the very same backdoor memory page into macbooks as well but maybe at (an)other physical address(es). now the code that runs on closing the lid “might” just reside at or write to the very same memory page on every boot for a given exact same kernel, which might be a memory page that acts the same or similar like that iphone hardware backdoor, overwriting some other memory page depending on what is actually written to the backdoor page which immediately crashes the kernel. if that’s whats happening there, t2linux is not broken, but macbooks are just insecure costly (loss of money, time, security, trust, work performance, patents, stability, a.s.o. …) waste.

how to find out? (maybe)

• get the kernel code.
• deactivate every driver not needed to boot and run the lidclose stuff like i.e. the sensor, compile the kernel anew and try booting from it.

changin the kernel a lot by removing everything(!) not needed should in theory/hopefully also change the pages that would be affected when closing the lid. same effect: likely no backdoor. no effect: maybe something you deactivated, maybe yet another backdoor discovery.

it might also be solveable by sth like acpi settings or such, probably switchable from kernel boot cmdline , maybe change settings for hibernate / suspend to ram (does apple hardware even support such? i mean without the buggy behaviour i experience?)l

but you did notice that compilers can be manipulated to include backdoors into resulting binaries AND put the same manipulation into newly compiled compilers as well, right? then where did you get that compiler from? did you have a look at the binary output? then if so, did you look at it using the hexeditor of that same compiler? 😎 plz have a look … 💥 bzzzt … really you are lucky to be alive after a blast like that, especially you, have yourself checked out with ems before you leave!

you already have an internet connected back door in your CPU.

unless you’re running your own gsm station and let your cpu’s safely connect to it, and use that connection for additional snmp monitoring data?

i would not trust hardware from a vendor that puts hardwired backdoors into physical memory… you’ld undermine any security the OS could give you.

i experimented with this some time ago, see my post here: https://lemmy.ml/post/18706002/12772832

i had experimented with kexec and takeover.sh to install a distro that was not available by my provider.

it resulted in some scripts i now (triggered by this thread) have published (in a nonready state):

http://github.com/tobinq/goaround

the scripts may be in bad shape but i successfully changed one preinstalled ubuntu to a devuan with what is in these scripts. however i didn’t work on them for month now and am not sure about that last state… so its experimental only.

yes it protected - by accident - the servers from booting into malware 😁

well maybe letting them pay compensation to all(!) victims (not just their customers) for all losses including lost time already would solve that problem.

that would leave the decades-long unsolved problem of microsoft not beeing held liable for their buggy products (which is the reason for all security-products-as-a-workaround-to-compensate-that-crappy-os companies existance) open.

why not in general hold companies liable for the damage they cause so they CAN develop beeing more cautious with what they do? i mean not ONLY cs should be sued to hell, but ALL of them should be sued until they are reasonable cautious with all possible damages they can cause (and already did in the past)

so i misunderstood. sry then.

and yes, every company running an alltime-ever-in-news-due-to-critical-exploitable-bugs-in-the-mailclient already IS in freefall after that said jump.

i somehow feel this might be sort of a vim-vim situation 😁

most Linux “Users” would’nt be that stupid. it nearly always takes a noob in a CEO position (okay, just saying CEO is sufficient here) to blindly trust malware distributers and their ads.

This is very popular software.

if that’s a “good” argument for you, then i’ve already heared that, and it nearly never really fits. here is another one for you that is an argument as generic as yours: “maybe try eating poo, trillions of flies cannot be wrong, poo is VERY popular food, much more popular than any human food !!! (as in mass per day as well as in its number of consumers)”

maybe just lookup the name of the ceo and where he already did similar ;-)

or maybe even automatically like in any well done CD or CI environment. at least their customers now know that they ARE the only test environment CS actually has or uses. ¯_(ツ)_/¯

“if only” - poem (“3 seconds” edition):

if only.

if only there would exist CEOs in the world that could learn from their noob-dumb-brain-dead-faults instead of always ever speaking about their successes which were always-ever really done by others instead.

if only.

if only there were shareholders willing to really look at that wreck that tells all his false success storys and lies, so CEOs could then maybe develop at least a minimum of willingness to learn. maybe a minimum of 3 seconds of learning per decade and per ceo could already help lots of companies a really huge lot.

if only.

if only there was damage compensation in effect so that shareholders would be actually willing to take at least some seconds - maybe 3 seconds of really looking at new CEOs could already help, but its only shareholders, not sure if they would be able to concentrate that long or maybe are already too much degenerated over the generations of beeing parasitic only - to look at the CEOs and the damage they cause before giving them ability to cause that damage over and over again.

if only.

that a moderately clever human can talk them into doing pretty much anything.

besides that LLMs are good enough to let moderately clever humans believe that they actually got an answer that was more than guessing and probabilities based on millions of trolls messages, advertising lies, fantasy books, scammer webpages, fake news, astroturfing, propaganda of the past centuries including the current made up narratives and a quite long prompt invisible to that human.

cheerio!

it might take ages for her to choose the right boots for rebooting ;-)