I suggest using port 587 (SUBMISSION). That was you can heavily firewall filter the IP space to geographic locations where you are not likely to be sending mail. Besides geographic filtering, I also limit access to 587 using my "no eyes" list of datacenters. This firewall filter list comprises major cloud providers like AWS, and any minor league datacenter that I have detected doing hacking. I'm filtering Linode and also Digital Ocean, with my own IP obviously not on the list.
You will probably find Linode automatically blocked by ATT, just like DO. Linode's Japanese IP space is notorious for bad behavior. Once your IP is removed from private blocking such as ATT uses, you should be good forever. When I set up the new email server, I had to contact ATT again to get cleared. Ip2location.com provides free information on CIDRs used for individual countries. With enough firewall filtering, I don't need fail2ban. I just run SSHGuard. www.postfix.org/anvil.8.html Postfix anvil is highly suggested. I don't know if the intent was to stymie hackers, but it sure works well when one of those bots that tries to auth with guesses at usernames comes knocking. Original Message From: robac...@fastmail.us Sent: August 15, 2018 2:51 AM To: postfix-users@postfix.org Subject: Re: New to Postfix. 3 questions about security functions. Thanks alot for the comments so far! >> (1) >> >>What do folks here recommend to use? > On my current server, I skipped amavisd-new because sometimes it stalls the > mail queue. Nor do I run SpamAssassin. I'm happy just using RBLs. I'm running > opendkim, openspf, and opendmarc. > Regarding DKIM and DMARC I would stick with the standard opensource packages > which are opendkim and opendmarc, they play well together and you should be > able to install them from your distro packaging system. I don't have any experience yet with one or the other. Whatever I use I'll likely build instead of using distro packages. I'm not a huge fan of some of the spec files I see. I like simple and understandable! But I'll see yet. That 'trusteddomainproject' sounds a bit more official. Or at least broader. But I really don't know. Seems like there aren't a lot of people working on it. Or that bugs get the attention they need. The 'fastmail' project sounds like its attached to one specific vendor, Fastmail. But that's been my mail vendor, and they've been great. And it has the advantage of being an all-in-one-milter tool. Looks like a smaller project though. > Amavis, Spamassassin, Clamav Still thinking about those. > OVH I've seen way more spam attempts from OVH blocks than any other provider. By far. Could be because they're big. I'm not convinced. > DigitalOcean They've been the 2nd worst in my sample set. I'd rather setup my mail in a better 'neighborhood'. For me that will be Linode. Yeah I know. Different strokes! >>(2) >> >>What's the current advice for MTA-STS vs MTA-DANE? Which should we implement? > Outbound DANE is simple. Make sure you have a DNSSEC-validating resolver > running locally on the MTA (it can forward queries to an upstream cache if > you like), and set: Didn't realize it was THAT simple. Thanks. How do you TEST it once you turn it on? Is it just the obvious "if you can send, and there are no Postfix reported errors, then it works"? > If DNSSEC is not a major barrier for you In principle, no. > inbound DANE, but don't do it as a fashion statement, Roger that! > there are operational requirements that must not be ignored. In particular > your certificate rotation needs to be coördinated correctly with TLSA record > updates. I'm looking at Opendnssec and got it updating my DNS locally. What's got me antsy is the whole automation bit for the DS-Records updates at the registrar (right now I'm at Gandi). And rotation automation stuff. Still seems like there's a lot of Do-It-Yourself scripting needed. > ICANN61 talk slides Thanks alot. Those are some good reading. > One more thing I forgot to mention, should you be unlucky enough to run into > a domain whose TLSA records don't match reality, double-check this against: Back to the TESTing question. How does Postfix notify you if you do? Only in the error logs? Or some response that I should get as a response in my mailer? >>(3) >> >>I'm guessing it will be ABLE to use it. > It will be negotiated automatically if both ends support it, once you deploy Postfix linked with OpenSSL 1.1.1. But I'll have to SET Postfix to use TLS1.3 in the config? In the 'smtp_tls_mandatory_protocols' setting? Not sure yet about that one. Looks like you don't necessarily INCLUDE what to use, but EXCLUDE what NOT to use? > That said, best to not do that yet. Meaning? When Openssl 1.1.1 comes out, should you still only build Postfix with Openssl 1.1.0? Or are you talking about *config*? Thanks. Rob Arlenn
