smb

but maybe only for emails from outside, not for emails from within protonmail? haven't read any specs of protonmail yet...

well for e2ee you obviously have to let one e encrypt the data for the other e. (good luck with newsletters then) for usual services kindly asking them to support either s/mime or gpg for outgoing emails, that would at least make them know the wish, but good luck there too.

i think the already mentioned solution with encrypting incoming messages on your side just before mda to your inbox should be the closest possible to what op wants. one would need to check if the message is already encrypted and skip encryption for those.

if you only want the admin of that email (imap) server to not be able to read all emails, maybe placing a separate encrypting server (smtp+encrypt+forward) inbetween outside world and your email imap server could be a solution.

one should have a look into the logfiles too as some mailers might log message subjects and of course sender/recipients along with ip adresses of incoming/outgoing servers which the op might not want to be readable as well (i dont know protonmail that much)

also gpg IMHO allows for sign-then-encrypt hiding the signature within the encrypted data which could be wanted. also one might want to look exactly what parts of the messages contents and its headers are encrypted or plaintext on the server before feeling safe from the threat one wants to be protected from.

but then the admin can still read the mail while it arrives ;-)

i'ld say this has nothing to do with linux (as linux is the kernel and what sucks there is your distributions choice of how things are handled), and i guess this is just one of tens of thousands of poisoned systemd crappy design "decisions". i went from systemd away for the same crap why i went away from windows. there are tons of very "interesting" similarities between systemd and windows and "it sucks" is just one of them. use a linux distro without systemd and stop complaining about linux when systemd is what actually fails for you. ;-)

nobody changed anything, so why should have anything changed? development does not appear by pure wish or magic, nor by letting time passing by, people have to do it, or it just doesn't get done.

sort of missing in the list:

• fruitarianism
• raw food eaters
• instinct diet

questions: why are reasons in the list only for 12. and 13. ? why is ethical reasons only for 13. but not for 12.? why is health or environmental reasons only for 12. but not for 13.?

i have met at least five peoples who's reasons did not match those named in 12 and 13, why so sure to know the reasons in the first place? at the very least someone could just 'try' veganism for "trying" but "trying" is not named as a reason in the list while its a very valid reason and could come alone without any other reason needed.

other reasons might be possible for 12 and 13:

• religion
• spirituality
• taste
• bad taste
• price
• dislike of industry production of all dead animal products
• dislike industry production in general
• dislike of food that tends to decay quicker and then beeing way worse than plants
• dislike of food that quickly attract flies
• dislike of meat eaters maybe for their stupid and wrong argumentation bases
• eating only what parents put on the table / say is good
• eating something to show kids what is (assumed to be) good for health
• eating the opposite of what parents say is good.

conclusion: debunking of this specific vegantheory seemed way too easy.

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 !

quite a few years since I bought it and I don’t remember anything about it.

but you still have it and 'could' make a foto, right? just to mention. i had this prob very long ago.

i guess leaking could be because the specific pens could have some different behaviour. while the ink flows down, air must flow into the catrige. if too much air can flow in, i'ld guess thats when leaking occurs, but letting that tiny amount of air that precisely into the catrige might be possible, for a refueled catridge, but could be more error prone due to moving parts or just might not be the same needed for every pen that fits and the vendor chooses somewhere in the middle to "fit" more pen types, but that was guessing from long time ago. however now that it seems that this prob still exists3.... maybe you can make a photo of the catrige and the pen.

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 ;-)

i'm sorry to have used the wrong word, i just happen to not know the english phrase and didnt look it up either before sending. i meant the "family" where he grew up.