Correctly configuring #dovecot#LMTP so that you can use dovecot-sieve to filter spam is way harder than it needs to be and honestly I'm suspicious as to why this isn't a default package out of the box in the year 2024.
To be clear this was like 2-3 hours of my life reading the docs and learning about the differences between mailbox_transport, virtual_transport, and local_transport in #postfix.
Still, running my own mail server feels like navigating a labyrinth on the best days.
I wonder if it would be possible to configure my #postfix mail server to reject emails from #GMail and #Microsoft (replying they are not accepted because of spying users) 🤔
Is it a good idea? Is there anybody doing that?
I know it will cut me out of many contacts but I really don't want to be targeted by their algorithms.
Postfix 3.9 MTA embraces MongoDB, upgrades MySQL/pgSQL clients, and tightens security with essential improvements. https://linuxiac.com/postfix-3-9-mta/
Frage am die #postfix-Eperten: Ich kriege im log von Postfix nur genannt, das ein Server der Mail einliefern will keine der Ciphers kennt die ich nutze. Kann ich rausbekommen welche er anbietet? Der liefert nur aus, ich kann also nicht per telnet bei ihm testen....
OK folks, I'm in need of a tech assist: Please Boost!
Any Mastodon Postfix and/or ISPConfig wizards out there? I am trying to figure out a problem with the smtp not sending, possibly due to a bad milter/rspamd communication.
You ever get so sick of #spam that you decide to just create your own DNS blocklist? No? Well, maybe I'm the crazy one, then. Anyone with #selfhosted#email may appreciate this. (Directions included for #Postfix.) https://spammers.icu/
Gmail has advanced AI-based filtering. Now that LLMs are becoming democratized, I'm ready for a self-hosted AI spam filter.
It seems much more popular to publish research papers on the viability of LLM-based spam filtering than it is to build LLM-based spam filtering software. Here are dozens of papers: https://www.arxiv-sanity-lite.com/?rank=pid&pid=2206.02443 Nothing on GitHub, yet.
And now he proudly explains how he knew that 1.4 million email servers running #postfix and 150k email servers running sendmail would be affected. And STILL did not inform the postfix or sendmail community to discuss. No. Waited for 6 months.
The #SMTPSmuggling attack is being mitigated and tracked in the following CVEs:
CVE-2023-51764 postfix
CVE-2023-51765 sendmail
CVE-2023-51766 exim
All three CVEs have been filed today by the community and NOT by SEC consult who discovered the flaw in June 2023 but decided to not share their findings with postfix, sendmail or exim. Only after they published their post on 2023-12-18, the communities have become aware and are now working hard to fix what is now more a 0day :(
Instead of sending a fix to #postfix upstream, especially when postfix just celebrated its 25th anniversary, these folks at SEC consult decided to milk their 15 minutes of fame and #37C3 happily gives them the stage. https://chaos.social/@Foxboron/111621156200642472
in your main.cf so you can have relaxed holidays. Updates with a complete fix will land in your distro of choice soon enough. And thanks to SEC consult for this precious gift!
I don't know who needs to read this, since there are probably 12 #Slackware users out there, but a new version of postfix is out for Slackware 15, with a patch for "smtp-smuggling":
@ParadeGrotesque
I haven't seen any sign that #Debian has issued patches to address #SMTPsmuggling yet either.
For the benefit of others the #postfix link you cite above includes configuration workarounds which wisdom would see admins apply to postfix instances on whatever platform.
Admins of other MTAs should check their susceptibility too.
Ok about #postfix and #Smuggling:
"Days before a 10+ day holiday break and associated production change freeze, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>."
Presenter #TimoLongin found an exploit in SMTP, notified commercial vendors GMX, Microsoft & Cisco in July, then published a blog post in the week before Christmas that describes how the attack works. Free software maintainers and admins were not warned in advance and had to rush to build workarounds.
Would've loved to talk to him about his idea of "responsible disclosure".
As Timo clearly likes getting recognition for his work, I for one will be remembering his name, and the name of #SECConsult, his employer, for giving us this Christmas present. 💝
@scy I've read the article from Timo now at least 3 times and I'm convinced that he really forgot about RFC 2822 section 2.3 (“CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.”). The whole article is written from the perspective of the recipient server which should not allow LF as line ending for “CRLF . CRLF”.
My first impression therefore is that he just didn't realize that the sender (postfix) is also problematic. I made the same (false) assumption and can totally understand when this isn't the point of the research. #postfix is not in scope of the written article, it's just a vehicle to transport it to a vulnerable server.
OTOH it's good to know that postfix can work around the problem and a fix is in the work, but it's still not the problem here.
So, apparently, SEC did, via CERT/CC, contact Postfix months ago, but not with enough details about the attack to make Wietse or CERT think that Postfix was vulnerable. Then they fleshed out their blog post (that clearly mentions Postfix being vulnerable), but did not talk to Postfix again before releasing the article.