# This is working: message gets "X-Spam-Language: ja.shift-jis" added to it. add_header all Language _LANGUAGES_ # This is being ignored maybe? ok_languages en ok_locale en # This is supposed to fire but does not: score UNWANTED_LANGUAGE_BODY 3 # This doesn't fire either: header UNWANTED_LANGUAGE_HEADER X-Spam-Language =~ /\bja\b/ score UNWANTED_LANGUAGE_HEADER 3
SpamAssassin
I agree with this message.
Instagram advertising is going great
I understand that they use "cookies" to enhance my personalized advertising experience!
Postfix
How do I prevent postfix forgeries in "From:" rather than envelope?
Putting "dnalounge.com REJECT Forgery" in "sender_access" prevents inbound unauthenticated SMTP connections from forging my domain in the envelope, but doesn't reject messages like:
Return-Path: spammer@example.comor
From: example@dnalounge.com
Return-Path: spammer@example.com
From: "example@dnalounge.com" <spammer@example.com>
Looking for a postfix solution, not a spamassassin solution.
Current settings:
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
permit
smtpd_sender_restrictions =
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_recipient_access hash:/etc/postfix/access,
check_sender_access hash:/etc/postfix/sender_access,
reject_rbl_client zen.spamhaus.org,
permit
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
Update: I have still not gotten an answer to this question that I understand or believe. Is the person below who said "you can only solve this by adding even more nonstandard complexity to master.cf" correct?
Postfix
When Postfix delivers to an unknown user via Dovecot it gets status=deferred but I want a reject in smtpd instead. How fix?
main.cf: mailbox_transport = dovecot:master.cf:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver
-e -f ${sender} -d ${recipient}
Running deliver by hand shows it exiting with status 75.
The oligopoly has won.

Many companies have been trying to disrupt email by making it proprietary. So far, they have failed. Email keeps being an open protocol. Hurray? No hurray. Email is not distributed anymore. You just cannot create another first-class node of this network.
Email is now an oligopoly, a service gatekept by a few big companies which does not follow the principles of net neutrality. [...]
I lost. We lost. One cannot reliably deploy independent email servers. This is unethical, discriminatory and uncompetitive.
*Stares in previously.*
Today in "Google broke email".
To recap, my domain hosts its own SMTP server running Postfix, and /etc/postfix/virtual contains a bunch of entries forwarding "employee_name@dnalounge.com" to whatever their actual email address is, usually gmail.
This has been mostly working fine for a decade or so, but lately there have been more bounces due to "strict SPF". For example, jksound.com's SPF record includes "-all" (dash instead of tilde) which means that when example@jksound.com tries to mail example@dnalounge.com, we forward that along to example@gmail.com, and then Google rejects it with 550 "SPF hard fail".
So, I don't know whether it has recently become more common for people to use dash-all instead of tilde-all, or whether Google recently started actually enforcing dash-all in a way that they didn't before, and while I am curious about that answer, it doesn't really matter.
Another thing that doesn't matter is that SPF is bullshit that solves no problems and should not exist. Let's just take that as a given and move on.
What does matter is, what the fuck do I do about it?
Telling all of these people, "Hey dummy, use tilde-all instead of dash-all" is obviously not practical.
"Provide an IMAP server for all of my employees" is a terrible answer, in terms of both maintenance headache and disk space.
"Turn over your MX record to some third party service" is an even more terrible answer, because so many of our custom internal systems touch email. Order confirmations. Shipment notifications. Calendar mailings. Sales reports. Bounce and unsubscribe handlers. Address verification and password resets.
Is there a third option?
Finally, here's a concrete question: let's say I desired to have a filter plugged into my Postfix that looked at a message, identified it as one that Google is definitely going to reject because of strict SPF and then... did something else with it. Like, say, forward it as an attachment instead. (This would obviously be insane and terrible, and yet still better than bouncing.) Is that a doable thing, or should I just stick forks in my eyes right now?
Update:
-
My current approach is to provide a POP3 server for all of my employees. It turns out that POP3 is a thing that still exists in the Twenty-First Goddamned Century. Gmail provides an option to download mail from external POP3 servers, if you trust them with your password. As far as I can tell so far, Google doesn't penalize my server for spam that is relayed that way, they just process it normally.
But, every now and then, instead of downloading a message, they deliver a message to the recipient that says "The message [...] contained a virus or a suspicious attachment. It was therefore not fetched from your account and has been left on the server." And in that case they leave it on my server forever, which is annoying.