New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
MXRoute and postfix
Hey guys, maybe especially @jar,
I'm a happy customer of MXRoute for some years now. I just wanted to setup postfix to use my MXRoute to relay my messages from my Proxmox server, but I'm not able to set it up correctly. Is there anybody in here who can help with settings?
I was trying to use sasl_passwd to configure everything but I seem to fail all the time.
Thanks guys!
Comments
https://www.linode.com/docs/guides/postfix-smtp-debian7/
Just please suppress cron job emails. I get so tired of telling people that I've blocked the 500 cron job notifications they're sending to Gmail every hour. I know they don't read them. They know they don't read them. Everyone knows no one reads them. It's like converting my IPs into garbage delivery trucks.
@jar do you ever sleep? Thank you for your quick reply!
I'm not planning to spam anybody with this. Hopefully it will just be one mail every now and then when backups fail, not more. I was just struggeling to make it work but I think I just fixed it.
It seemed that this one did the trick:
main.cf
sender_canonical_maps
header_check
Can I assume it's okay to send them via an MXroute account to an MXroute account ( not 500 per hour naturally )? I assume that wouldn't affect IP reputation. There are some cron jobs that are actually useful and read. ;-)
I must admit, I'd get pretty annoyed if my cron job emails were filtered. When something fails, I want to know about it. And actually, I do read them all on gmail (although I have shifted from forward to gmail to POP3 a few months ago to avoid problems with forwarded spam that gmail bounced).
Gmail totally sucks for that sort of message. I email my firewall alerts there, but a lot of the time they get blocked because Gmail scans the body of the email and sees a "bad" IP. Not in a link, mind you, but just in plain text.
Maybe this explains why spam reports to Gmail abuse also seem to go into a black hole.
One may redirect stdout to /dev/null in order to supress regular messages and only get notified when something appears on stderr. Regardless of the output, cron will also shout if a job exits with code >0.
For filtering out expected cron messages, swatch can also be a great tool.
Basically you will log/mail all your jobs into a file and afterwards run swatch with a configured whitelist of expected messages/regex over it.
Well, my cron setup works pretty well for me at the moment. As you say, I do redirect stdout, so it's only a few times a year when something goes wrong that I get any mails from cron. And they are things I want to know about quickly as it usually indicates a serious problem, so having it forwarded to my main gmail where I'll see it on my phone in minutes is perfect.
I don't think @jar blocks ever cron mail, I think it probably like stuff like csf/ldf which can generate 100's of email alerts per day for failed SSH logins and port scans which 90% of user are not going to read them anyway.
Sure, have at it.
Don’t send high volumes of shit messages to Google that lack all reasonable header requirements and ask me to have my IPs rate limited just so you can watch Gmail reject them, rate limit IPs, and force me to add a /24 to outbound for zero gain other than to increase overhead and decrease inbox deliveries across the platform for the principle of it. If you want to know if something fails, actually do the work to curate a nice email from your system rather than connecting the bottom of your toilet to an SMTP server. I work hard, I expect the tiniest amount of work and consideration from people who want to benefit from it because my customers need me to do that to keep their delivery quality high. People come to me because they’re tired of delivery issues, looking out for you sometimes means telling you where you fucked up. Thankfully, my customers appreciate this work. If you just want to fling shit down a cheap pipe, LEB has cheap server offers. If that isn’t you at all, and not at all what you’re doing, then I expect you wouldn’t be on the receiving end of these messages from me so it’s a non issue. If you let me, I’ll do everything humanly possible to make sure your domain is associated with the highest quality reputation that recipient servers can give you.
Yup. It’s pretty easy to conclude that you’re not reading all 6,000 times a generic Chinese IP address failed root login on your box, and these poorly crafted emails serve only to increase rate limits and rejections. Inbox delivery is definitely connected in some way to the statistics of good vs junk email coming from a platform. These are the kind of things people shoot themselves in the foot with and then later bitch about their emails being in the spam folder. You can’t let people set themselves and everyone else up for failure on some worthless principle. Email should be for actual use, not dumping grounds.
To be a managed provider that aims for excellent results, you can’t sit on the sidelines and let everything happen as it will. Gotta take the bull by the horns and be willing to call the shots. And other corny sports metaphors.
Just so it's clear, this wasn't talking about your service. I'm not asking you to accept any of my mails, and if I did need that for my company down the road it'd be handled totally different to what I was describing.
This is an e-mail address I've had as my primary personal e-mail for 20 years and so now inevitably has some spam. It's been received by a box that I share with others for all that time, and around 2007, I got a gmail account and started forwarding almost all mail to my address that passed spamassassin to it directly. Originally, this was because I was travelling for a few months and gmail was way more convenient that any other method of reading my mail, but kept it mostly because gmail's spam detection was very good (much better than the local spamassassin) and for a long time, this worked without problem, but recently the number of bounces (ironically usually from non-spam) led me to change that to POP3.
To come to an end. Don't use @jar MXRoute services to spam. Simple as that. I'll just want to stay a silent customer and help keeping the service as gods as it is for years now.
The sad state of email setup and handling is a unix admin legacy problem. It's like they intentionally make/made things convoluted for job security.
When will Poettering fix mail setup for Linux distros? (Half joking)
What did the reject email actually say? I've yet to see a reject from gmail that wasn't pretty obvious and worthy.
When I report something "not spam" received from a shared hoster on a blacklist to my gmail, I'll get the next few in the inbox but eventually go back to delivered but in spam folder. But I always get mail sent to/from gmail delivered.
Tl;dr you're doing something really wrong or something.
I'd say that depends on your definition of 'fix'.
Start with a unified mailx.
Or, we need whatever email 2.0 is with encryption and verification and shit built in and just replace this legacy mess.
Nah, Gmail's spam filtering is just really dumb sometimes. Obviously, I have a whitelist for these in Gmail's filters (well, technically, Workspace or whatever they're calling Google Apps these days), but they get rejected at SMTP time, not filtered afterward, so that doesn't help. Don't remember the exact wording of the errors, but it was a 5XXX reject. They crop up just enough to be annoying, but not enough to make me really dig into it or configure a separate server to receive this stuff OOB.
Usually pretty solid but the undocumented update that they swear didn't happen on June 6th has definitely leaned into your statement there.