What is Reddit's opinion of
Postfix?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
Everything that has the smtp port open gets a lot of attempts to relay spam. If you don't intend to run a mail server, just disable postfix. If you do run postfix on purpose, please make sure to secure it.
What you are looking for is sender_dependent_default_transport_maps (http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps) Example: /etc/postfix/main.cf
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_dependant_default_transport.map
/etc/postfix/sender_dependant_default_transport.map
@example.com :smtp.example.com @example.org :smtp.example.org @example.edu :smtp.example.edu
Don't forget to run "postmap /etc/postfix/sender_dependant_default_transport.map" after editing a Postfix hash file, and then "postfix reload"
There are configuration options that could cause a mail server/client to reject mail from a client that HELOs with a non-DNS name. For instance in postfix, it's http://www.postfix.org/postconf.5.html#reject_unknown_helo_hostname .
Whether or not this is the actual problem, you have a bigger problem -- if you are paying for a company to do email for you and they can't get HELO configured correctly from the start, then my gut says a lot more could be wrong and trying to get them to fix it is going to be a huge pain. You might want to cut your losses and investigate alternatives.
It's for outbound mail. To get past almost all basic spam filters. That's why they care about pointing out the hostname matters. That said, serv1.server.com is fine. If you want it to be something different you can edit the config of your MTA.
Apache/nginx have nothing to do with sending or receiving mail.
Postfix lets you do this via the smtp_tls_policy_maps setting. An example is included there. You would want either the verify or secure level; encrypt doesn't perform any authentication whatsoever and will gladly accept an expired selfsigned certificate for example.com.
The documentation doesn't really make it clear that the only difference between those is the default match setting, which you can also override. verify is hostname, which means the server will need a cert matching gmail-smtp-in.l.google.com (or whatever the MX record points to). secure uses nexthop, dot-nexthop, which would effectively mean that it would need a matching certificate for gmail.com. You can also customize the match yourself.
Other MTAs, I don't have the slightest clue.
You'll just want to familarize yourself with postfix for the RHCE; don't ever waste your time on sendmail unless you hate yourself or inherit an environment that's already using it. Check out the docs in /usr/share/doc/postfix-*/ or at http://www.postfix.org/postfix-manuals.html. Read the architecture overview for what's going in master.cf (which you shouldn't need to touch unless you're doing advanced submission or filtering). And the basic configuration doc for main.cf, which has various things you might need to toggle (trying not to give away what's on the test). Presumably you already know about /etc/aliases and how that that works, but if not, it's a good thing to know for redircting things like cron mail.
- queue_run_delay (default: 1000 seconds) -How often the queue manager scans the queue for deferred mail.
- minimal_backoff_time (default: 1000 seconds) - The minimal amount of time a message won't be looked at, and the minimal amount of time to stay away from a "dead" destination.
- maximal_backoff_time (default: 4000 seconds) - The maximal amount of time a message won't be looked at after a delivery failure.
- maximal_queue_lifetime (default: 5 days) - How long a message stays in the queue before it is sent back as undeliverable. Specify 0 for mail that should be returned immediately after the first unsuccessful delivery attempt.
- bounce_queue_lifetime (default: 5 days, available with Postfix version 2.1 and later) - How long a MAILER-DAEMON message stays in the queue before it is considered undeliverable. Specify 0 for mail that should be tried only once.
- qmgr_message_recipient_limit (default: 20000) - The size of many in-memory queue manager data structures. Among others, this parameter limits the size of the short-term, in-memory list of "dead" destinations. Destinations that don't fit the list are not added.
edit: forgot to mention config page http://www.postfix.org/postconf.5.html
Non me ne capacito proprio. Purtroppo ce ne sono di siti così, quelli che mi stupiscono di più sono http://www.postfix.org/, che proprio non ce l'ha una versione sicura, e http://nginx.org/, che non reindirizza alla versione sicura, entrambi di programmi che implementano perfettamente gli ultimi standard TLS
Consider using an internal mail relay if your infrastructure supports such a setup. I use a small AWS Linux server running Postfix that all my internal servers send their mail to. The server forwards to O365 using the connector setup mentioned in https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-office-3 and from there the mail flows to its final destination.
Obviously you're not looking for a mail client. You want a MTA, a mail transfer agent. Sendmail is quite complicated, ancient and simply too much for such a simple task. Instead i would recommend Postfix. But even that might be too much, because if you own a account with a email provider (gmail, hotmail, live.com, gmx, or whatever) you can use their servers to submit your mail. Take a look at SSMTP, this is how I would do it.
Great! Depending on your postfix version, you may want to not actually use smtp_use_tls, as it was made obsolete in Postfix 2.3 and higher. The correct setting in later postfix for opportunistic TLS is:
smtp_tls_security_level = may
http://www.postfix.org/postconf.5.html#smtp_tls_security_level
http://shop.oreilly.com/product/9780596002121.do would be a good start.
But it all depends on what smtpd you go with. I tend to favor postfix, so that's my vote.
http://www.postfix.org/BASIC_CONFIGURATION_README.html is a great starter, and continual reference, as well.
http://www.postfix.org/postsuper.1.html
if you can identify these spam reliably, you can do some magic extracting the ID's with postqueue and the do a 'for i in' loop to delete each individual email.
be very careful though so you do not delete legit email from users!
Postfix is an amazingly customizable piece of software. I'd recommend setting it up as a "primary relay host" instead of doing address rewriting. You can use a transport map to handle the routing:
# Unmatched addresses are sent to Lotus Notes domain.tld relay:[lotusnotes.domain.tld]
# Users Migrated to BPOS relay:[bpos.domain.tld] relay:[bpos.domain.tld]
(Assuming I understood your problem correctly)
I'm pretty sure you can do that with Postfix address rewriting but you'd probably have to setup a subdomain to accomplish that. As such, it may not be a very good solution, depending on how long your migration window is.
Speaking of which, what do you think of BPOS so far?
I have no experience with MIAB but from a quick look it seems it uses postix, so the inet_protocols setting might be what you are looking for?
You can overwrite the routing of an email by setting up a policy service, which checks the size and returns a filter action like described here (ctrl+f other actions).
You may find this repository helpful, where I described how to set up such a setup. The script however checks the size against domain specific limits, so you have to adjust it.
yeah, a fully working mailserver from scratch is not a simple task for a beginner...
first, postfix only does smtp. imap/pop is something else, like dovecot or cyrus.
i would expect the config files in /etc/postfix (main.cf und master.cf)
there is an extensive official postfix manual. http://www.postfix.org/postfix-manuals.html
but honestly. maybe you should look either into renting a mail server, maybe a webhosting packet would even do. or look into deploying a package solution.
and fyi, I would expect a couple hundred dollars for someone to do it for you. if he is cheap. and can work without explaining every second key press. its a big time sink...
anyway. if you still NEED to do this, look for a community supported package solution
One of the things I have always loved about hosting my own email is getting to set custom REJECT message, and it's so easy with postfix. Here's a few real lines from my access map (domains hidden to protect the guilty):
> sales@d________x.net 550 "Mail From Incompetent Hosting Companies Not Accepted Here, Karl"
> orders@S_____._____P.nl 550 "Mail From Incompetent Hosting Companies Not Accepted Here, Karl"
> v________________s.org 550 "I didn't sign up, and your unsub links are broken. Go away"
Depending on your platform this could be more or less messy.
But on Linux postfix/Exim/sendmail should be doable to setup as a relay host sending all email to the corp SMTP.
Looks like postfix(my suggestion) have some web interfaces if you need it.
If my memory serves, and the docs seem to support it, the sender_dependent_default_transport_maps setting doesn't use the wildcard in the table. http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> The tables are searched by the envelope sender address and @domain.
Defining nexthop using relayhost or default_transport instead of the wildcard is probably the way to go.
All good info! Mail-in-a-Box is definitely one of the all-in-one packages I was thinking of.
Personally I am renting an OVH box with an embarrassment of HD space and I don't mind doing things "the hard way" so I really understand how it all works, and I get to make a lot of fussy choices that suit me best.
For example, Postfix (on which m-i-a-b is built) allows you to choose your recipient_delimiter. It defaults to "+" but you can set it to other reasonable values and get style address extensions.
Free aliases are nice though, and I use a lot of servicename@ aliases to copy more than one person. So, for instance, both my wife and I get the emails sent to our ovh@ alias.
It's a default setting in Postfix as well (possibly other OSS mailservers, I don't know for sure): http://www.postfix.org/postconf.5.html#recipient_delimiter . I think in Gmail it has the added benefit of being interpreted as a folder to file the email directly into.
I'm using sendmail (postfix interface) for mail delivery duties on a couple of ubuntu VPS instances, it's easy to configure. That might be worth looking at.
Edit- link
You will probably want to create a generic map for sender rewite. Instructions can be found here . The sending server should be in the relay path of the envelope however so this may not be necessary depending on where and why you are trying to determine which server it came from. If you do decide to rewrite the user portion, I'd suggest you use <user>+<host>@<domain> . The '+' is used by gmail and several MTAs as an ignore delimiter in the user string which means will be delivered to . This will prevent replies from braking. I don't recall if postfix has this rule automatically but you can add it pretty easily.
Edit: fixed link
you are barking up the wrong tree. if you just need postfix to connect to google/outlook etc. via tls then you don't need to setup a cert for your server. you just need to tell it to use tls where possible when making outgoing connections.
start here:
http://www.postfix.org/TLS_README.html#client_tls client not server.
Set:
smtp_tls_security_level = may
That's it.
This can all be done with just the Postfix side of things.
If you want to map specific emails to other specific but varying emails, you want alias_maps or virtual_alias_maps. That will allow you to say have go to and go to for example. You can even do things like to or whatever.
If you want all emails for domain1.com to be mapped to the same username at domain2.com, you likely could just do it with local_receipient_maps.
Something like
luser_relay = $
should take the username (part before the @) off the email for anyone not in the local recipient tables (don't have an email at that address) and tack it onto @domain2.com and try to send it there.
Here's more details:
I haven't specifically done this through Postfix, as the majority of my clients use EXIM. In Exim the rewrite rules are straightforward. With Postfix it's also (seemingly) the same. I think this is what you are looking to accomplish.
http://www.postfix.org/ADDRESS_REWRITING_README.html#standard
You can likely check the mail.log to see through which channel it's coming through. You can up the verbosity using http://www.postfix.org/DEBUG_README.html. The better thing to do is wipe and rebuild from a known-good backup.
You are talking about virtual domains. There is a bit of a learning curve ahead for you, but it gets easier the more you do it.
Start here (Postfix Virtual Domain Hosting)
Once you get the hang of that, I would recommend Modoboa as a Web Admin interface.
Also try and get into using Ansible. Once you solve a problem you can use it as many times as you want.
While I am no expert I would recommend using postfix. I know it seems a bit boring, but read through the basic config guide which will show you a basic configuration, and once you have done that you can probably figure out what to change for your needs from there.
http://www.postfix.org/BASIC_CONFIGURATION_README.html
I also recommend backing up then deleting the default config file, and starting with an empty file. The config for my mail server is probably about 20 lines, but the default config file is pretty big and is a bit clunky to navigate through. Postfix has sane defaults so if the config entry is not listed, it will pick something safe for you.
That's great! Thank you so much!
Do you know if there is any way I can throttle on the to address? like should only be able to receive 10 emails per anvil_rate_time_unit? smtpd_client_recipient_rate_limit (http://www.postfix.org/postconf.5.html#smtpd_client_recipient_rate_limit) seems promising but I'm not sure.
http://www.postfix.org/postconf.5.html#anvil_rate_time_unit
&
http://www.postfix.org/postconf.5.html#smtpd_client_connection_rate_limit
Anvil rate limit is the unit of time, the rate_limit is how many connections per the time unit/Anvil.
More information here:
How are you sending the email? If you're calling sendmail via the command line for example you can use the -F flag to set the From: field. You might also look at the other flags in the sendmail man page for Postfix.
Or if you use postfix: http://www.postfix.org/generic.5.html
> ADDRESS EXTENSION > When a mail address localpart contains the optional recipient delimiter (e.g., user+foo@domain), the lookup order becomes: user+foo@domain, user@domain, user+foo, user, and @domain.
I just did a new server with Postfix + Spamassassin similar to what you want to do. I followed this guide:
http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix
The key point for a relay is to integrate Spamassassin as filter into Postfix, which is very different to the integration into local delivery with procmail that's described a bazillion times all over the web.
In addition to the default Debian configuration, I have added zen.spamhaus.org as RBL directly into Postfix (see reject_rbl_client, drops a lot of spam right in the SMTP session) and added language-based filtering to SpamAssassin to get ridded of all the Portugese and Russian crap we seem to get. Works very well so far.
I do nothing about virus scanning as all our users are on Linux, but from hearsay ClamAV is quite good at this.
Oh, I didn't put in a link to a general tutorial because (like I mentioned) the default install will just work (if your ISP isn't blocking you). Any tutorial I link is for more specific stuff, like:
- allowing email users that don't have a login on your mail server
- rewriting email addresses (both to and from) and/or relaying thing depending on rules
- setting up pop3/imap so you can retrieve your email from a normal client.
What I didn't think about until right now is that I want postfix to be able to get to the outside world so my servers can email me (I have many scripts that do this for various reasons). It's quite likely your goal is something else and so thats why I don't know where to start you off. Oh, except for Postfix's documentation.
I hope this was worth the wait and makes sense. If I just did a really shitty job of explaining this, let me know and I'll try again.
The exact option is escaping me right now, but I'm quite certain that something in the postfix docs will be exactly what you're looking for.
Alternatively, you could always set up an iptables rule such that the only device that can communicate with your postfix server over port 25 is your nagios server.
IUseRhetoric bottom point is right. What you should do is set up a gmail account and use postfix (sorry for hating on sendmail...) with SMTP auth. This will allow you to relay emails (txts in this case) through the google account.
Edit: Look here first http://www.postfix.org/SASL_README.html
Basically it's:
Install postfix :-)
create a file with account username/pass
create a hashed file with 'postmap hash:filename'
add sasl stuff:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
set 'relayhost' in main.cf to google smtp server.
~$ mail -s test Hi There! (CTRL+D)
You mentioned Exchange, so I'm not sure if a Linux solution is useful.
Postfix can store aliases and transport maps in a MySQL database - you just need a table containing the old/new addresses, then when an email is received postfix can forward it to the correct address.
http://www.freshblurbs.com/how-enable-local-smtp-postfix-os-x-leopard
You'll also want to setup http://www.postfix.org/postconf.5.html#relayhost to have it relay the mail through your ISP's SMTP instead of trying to deliver directly. You could also probably set it up to funnel all email into a local account, but I'm not that familiar with postfix to give instructions there.
> My TLS is auto-signed so not from a CA, but my clients can still send mails so that doesn't really make sense to me ?
I do not understand what you mean by auto-signed. If you did not force the use of TLS clients still can deliver without TLS in standard config - see http://www.postfix.org/postconf.5.html#smtpd_enforce_tls as a reference.
> Also i don't see any mention of TLS in the logs ..
As I've mentioned in my last response, you will only see TLS related information in your logs if STARTTLS is used.
I would recommend your try to connect to your relay with telnet and port 25 and see if your relay offers STARTTLS after the ehlo and go from there. Good luck!
Yes you can enable ETRN so your home server can tell the relay server to deliver mail right away instead of waiting on the retry time. It's not necessary but can speed delivery once your server comes up.
You can tune how often the relay server will retry delivery: http://www.postfix.org/TUNING_README.html#hammer
Just run a mail server, postfix, exim, etc. on a VPS. They can be configured to queue ("store") and relay ("forward") mail to another server. It just needs to be configured to queue mail longer then you think your server will be offline/unreachable so messages don't bounce. For postfix the default is 5 days.
> ... in case it was quarantined ...
Not to be a bug, but you should read the documentation...
http://www.postfix.org/MILTER_README.html#non-smtp-milters - see error handling... and then...
http://www.postfix.org/QSHAPE_README.html#hold_queue
man postsuper, info postsuper, setup a cron/anacron job and try not to use the pickup queue to resend a lot of email.
Postfix has a native LDAP integration if that's what you're looking for.
http://www.postfix.org/ldap_table.5.html
​
There aren't as many tutorials on that compared to Postfix/mysql combos, but you might want to look up one of those postfix/sql combo config files, since the config syntax is pretty much the same. So you know how to build your config file ;)
I'm running Postfix on Debian, and the main postfix package does not depend on netcat. I've also been unable to find a path from any Postfix module to any version of Netcat. (Debian ships both netcat-traditional and netcat-openbsd.) Also, there is no mention of any dependency on Netcat, even an optional one, in the Postfix Installation From Source Code instructions.
I therefore strongly suspect that Postfix does not call Netcat under normal operation. Unless you've set up some weird service in /etc/postfix/master.cf that you forgot about which calls nc, then I think it might be worth looking more closely into the possibility that you've been compromised. Especially if Netcat is being used to listen for incoming connections on all interfaces on a non-assigned port (i.e. anything not listed in /etc/services).
What you are describing is a standard secondary MX setup. Make sure that:
- the secondary mail server hostname is listed as an MX (with a bigger precedence number than your primary)
- that the secondary is configured to be a relay for the domain (but doesn't accept email for the domain)
and it should "just work".
The secondary will queue email until your primary is back online and resend (the longer the primary is down the less frequently the secondary will check). With most email servers you can kick off a queue runner using the ETRN command.
One big caveat with secondary MX is that you need to have the same anti-spam controls on the secondary as you do on the primary. If you don't then spammers will simply send mail directly to your secondary and bypass all the spam controls on your primary.
From what you see that? And how do I change that? During the guide that I linked, I configured postfix to handle my domain actually... what do you mean?
This is my /etc/postfix/main.cf
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no
# appending .domain is the MUA's job. append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h
readme_directory = no
# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on # fresh installs. compatibility_level = 2
# TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_security_level=may
smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level=may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = myvpshostname alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = myvpsdns.net, mydomain.com, myvpsdns, localhost.vps.ovh.net, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all home_mailbox = Maildir/ virtual_alias_maps = hash:/etc/postfix/virtual
Use any of the popular mail hosting packages like mailcow or mailinabox or whatever. Edit your Postfix main.cf to set the relayhost to your third-party outgoing mail provider's SMTP server. If they require authentication (probably), that will be an extra step to configure:
http://www.postfix.org/SOHO_README.html#client_sasl_enable
Easy-peasy with postfix.
If you must do this in Postfix, you could set it up to automatically add a recipient to all processed mail. This recipient could have its own local mailbox.
you can have more than one relayhost
http://www.postfix.org/postconf.5.html#relayhost
as for the login details one per line will do. the domain name is the key:
You can, but it's not by DNS precisely. I do something like this with postfix:
I have a hosted VM running postfix configured as the MX for the domain. within postfix I configure it to send mail for the domain to another server
/etc/postfix/transport
transport:<domain.com> smtp:<second mailserver>
You also disable local delivery in this scenario. It's been running like this for 15 years with no issues.
http://www.postfix.org/STANDARD_CONFIGURATION_README.html
Edit: The internal host is configured to use the other one as a smarthost, meaning it relays all outgoing mail through it. This simplifies your mail security a bit. More advanced discussion of this likely belongs in another sub though.
yes.
Everything that happens in the terminal becomes text in a buffer so that you can navigate it, search it, yank it, past to the terminal (append only).
I often do something like edit a python file and then :terminal<CR>apython <ESC>"#pa so i write python and then paste the path to the file I just edited.
When editing for example postfix config, you can open a terminal, curl http://www.postfix.org/postconf.5.html or some tutorial or similar, go back to your postfix config and have every option in your <C-N> completion.
I used to do :r ! some command but got anoyed when i did it wrong. Now i do the same command in terminal, and yank the relevant lines
At that rate of domain growth this sounds like a major use case for the Postfix address rewriting facility. This means you could use your choice of ticket systems and let the MTA handle your addressing issues and very likely automate the domain addition process, unless you need specific support agents per-domain.
:thumbsup: Glad it helped and good luck with the project.
Would also recommend adding proxy: to your ldap connections from Postfix. Reuses connection to your db instead of a spawning a new one. A lot of how-to's leave it out for some reason. Nice to have for when some spammer takes a shot at the system so you don't exhaust connections.
Creating user accounts is the easiest by far, you can do virtual mailboxes with postfix, either with or without an external DB.
Mail-only accounts should use rbash or /bin/false for their shell.
You can do quite a lot with vanilla postfix: http://www.postfix.org/VIRTUAL_README.html
So it really depends on: how much time do you have, and how much do you want to learn?
Yes, From the documentation mynetworks = hash:/etc/postfix/mynetworks would contain all your IPs in one file, one address per line.
IPv6 addresses should be surrounded in square brackets [ ] since typical hash files use the colon character to separate record fields.
If you are running your own Postfix install, you can set the recipient_delimiter for address extensions to something other than plus (+), such as underscore, dash or dot, and get addresses like, delivered to your actual .
You'll have to let your management UI know that the recipient_delimiter you chose is a reserved character for usernames, of course.
If you use the local delivery agent (mail is stored into the users home directory) you can look at the mailbox_command section of postfix.conf. And have it run a script to pass the email through gpg.
You could also look at using a gpg proxy for the smtp server.
Any idea what PBX it is? I may be able to help you change it.
It's definitely possible to do with Postfix:
Plenty of examplea within postfix's documentation (http://www.postfix.org/).
Make sur to read and understand. Otherwise you'll shoot yourself in the foot and plenty of other sites will pay the price (open relay)
This what you are looking for? You may also want to bump the concurrency variable down. A lot of people create an additional transport for their slow transport that rate limits and concurrency limits email being sent to certain domains (yahoo being a big one).
You don't mention whether the connection is retrieving or sending mail so I'm assuming you are sending since this is the postfix subreddit and not a dovecot reddit.
Alternatively there are ways to limit the connections further, either using a policy server/service, or some iptables magick (probably not what you are looking for).
Il server di posta di ACME è probabilmente configurato per mettere in carbon copy Caio. Ci sono diversi modi per farlo, ma dipende dal server di posta. Con postfix: http://www.postfix.org/FILTER_README.html (custom content filters) http://www.postfix.org/postconf.5.html (always_bcc) http://www.postfix.org/cleanup.8.html
ive done something similarish in the past. you can basically use a postfix script to parse/modify an email and reinject it back into your mta. might be a little overkill and is not the easiest to get working.
http://www.postfix.org/FILTER_README.html
at the time my "v2" was gonna use qpsmtpd, but ymmv.
If I'm interpreting your question correctly, then no, it's not quite possible. In order to decide which certificate to present to the client, Postfix would need to support the SNI extension to TLS. Postfix only supports this when it's acting as a client: "There are no plans to implement SNI in the Postfix SMTP server."
If you pointed each domain to its own IP address, and defined a separate smtp instance in master.cf for each one, that would work - but it would be an inefficient use of IPs.
Tha is for your reply. I had another look at the Postfix site: - Postfix supports DANE since version 2.11 (http://www.postfix.org/features.html Postfix 2.11 RFC 7672 (SMTP security via opportunistic DANE TLS) PKI-less TLS server certificate verification based on DANE (DNS-Based Authentication of Named Entities). - MTA-STS is not supported by Postfix on its own but via the independently developed helper deamon (https://github.com/Snawoot/postfix-mta-sts-resolver ) which is under active development but still lacks a few features (according to its GitHub description)
Still, it is still unclear whether PM - uses the helper deamon from Snawoot, - has developed an in-house solution for MTA-STS, or - does not verify MTA-STS policies at all
The problem we are trying to solve is that we have customers migrating over to Office 365 and they are going to be behind our cloud email gateway system.
Our system is using a postfix SMTP server backend and I could not find a way to allow relaying apart from using IP address.
http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions
Any ideas?
I agree that opening relay for O365 IPs is bad but I can't find a way on postfix to permit relay based on FQDN. As I am aware, you can't do SASL auth for send connectors on O365 either. The only option available as per postfix documentation is using IP addresses.
http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions
You could do that, but I think the feature you are looking for, if your mail backend is postfix, is masquerade_domains. I am sure that whatever backend and front panel you use, there is a similar feature that will do what you need so that it translates to .
Postfix documentation is good.
For simple internal mailserver for log messages, basic configuration must be sufficient. See others links if you have special needs.
​
Yes, through ACL policies such as smtpd_recipient_restrictions, for example. With "permit mynetworks", you allow internal IP ranges first, and then further down the list you can have a map of internal domain names that you reject, unless they come from mynetworks. Essentially, you trust your own internal IP's, and if a message from an IP outside that range for one of your domains comes in, it gets rejected.
I'm pretty sure you just include /etc/aliases in your alias_maps as well. Then postfix knows about your virtual users and the local users on the machine. See: http://www.postfix.org/ADDRESS_REWRITING_README.html#aliases
But as you also want to effect the destination address you need to rewrite the header iirc and/or transport mail.
If you only have specific destination domains you can use smtp_generic_maps http://www.postfix.org/postconf.5.html#smtp_generic_maps . That will rewrite your *@yourdestination.domain to
Have a reread over the postfix docs. Running a mail server is hard. And spending a couple of hours just reading all of the docs and attempting to understand each of the config options regardless if they relate to you or not will help you understand the rediculous monstrosity that is mail systems.
> You can use the command "postconf -n" to find out what settings are overruled by your main.cf.
Check what myorigin is set to.
Edit: Also check out Postfix Virtual domains
As root, edit /etc/postfix/master.cf . On the line that starts with smtp (and/or relay, depending on which port your mail is getting delivered to), add "-v" (no quotes) to the very end of the line after "smptd". Then restart postfix ("service postfix restart" as root). Your mail logs should be in /var/log/mail.log. The resulting logs are very detailed (so you'll probably want to turn off -v as soon as you're done). I recommend getting ready to send a message, "tail -f /var/log/mail.log", clear the console while the tail is running, and then send your message, followed by ctrl+c. That'll make it easier to find the relevant log lines.
You can find some more detailed instructions here on reconfiguring postfix.
I would use aliases instead (default table is /etc/aliases unless you changed alias_maps in main.cf).
Add a new line:
: , ,
Then run newaliases and you're set. Forwards for new users need to be added to the alias manually but you can probably script that if needed. Note that if you want to forward to external addresses as well you need to use virtual aliases: http://www.postfix.org/virtual.5.html
The link you provide seems to be to the man page for the notoriously difficult to configure Sendmail MTA -- the Bat book weighs in at a svelte 1312 pages.
I am not sure if that is your intent, or if you mean the Postfix sendmail compatibility interface.
Instead of adding postgrey why not add local DNS resolvers so it's cached DNS requests.
Personally postgrey added more headaches for my clients over the years.
Also straight from the docs:
> always specify "check_policy_service" AFTER "reject_unauth_destination" or else your system could become an open relay.
> relayhost works fine but sends the email as which O365 rejects (obviously)
Use relayhost, but you'll need to set/map credentials so it authenticates correctly.
http://www.postfix.org/SASL_README.html#client_sasl_sender
Found via this link: https://stackoverflow.com/questions/27138337/postfix-sender-dependent-relayhost
In addition to the good suggestions made by others, I'd turn on postscreen. It works a charm and allows for much more flexible RBL checks (for example, you can combine and weight them, which is very useful).
Once you're a bit more comfortable I'd make use of a caching resolver rather than your ISPs DNS servers. Many RBLs have per-IP quotas for non-paying customers and having your queries lumped in with the queries of all of your ISP's other customers can cause you to run over the daily quota. Running your own resolver on your own IP will prevent this.
I use :
sender_bcc_maps = regexp:/etc/postfix/archive_domain recipient_bcc_maps = regexp:/etc/postfix/archive_domain
and
if !/www-data/ /@mydomain.co.uk$/ endif
to bcc mail that's not from www-data. Something similar ought to work for you.
See also :
This covers the basics : https://wiki.centos.org/HowTos/Amavisd
You need to harden your smtpd restrictions too probably : http://www.postfix.org/SMTPD_ACCESS_README.html
You should also consider postscreen (postfix's "blacklist client") : http://www.postfix.org/POSTSCREEN_README.html
tetroxid i know it works only on domain too but dont you see they lie. tetroxid if they comment you need subdomain.mydomain.com and someone don't know he will be forced to do it, this mean he need to pay more money, becouse for subdomain.mydomain.com you need to have ssl certificate. All linux need to persecute all lie. Linux need to make latest official manual, and every day when new release are release they need to write they version and explain what had chaged and what is new. This is good manual for postfix, i didn't know it exist. Here they explain all true for postfix: http://www.postfix.org/postconf.5.html#smtpd_sasl_path they explain what will happend and if it is plus that help humankind they comment it. Include postfix on medium use 384 bits encryption this mean tls 1.2. tetroxid open your eyes, tetroxid open your soul, tetroxid open your mind in this website they don't comment it is example: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-server-with-dovecot they comment you need to have subdomain " mail.mydomain.com " they don't comment you can use your domain.com for mail include they force you buy ssl certificate An SSL certificate that is valid for "mail.mydomain.com" if you use debian, ubuntu peoples need to use general explanation. You don't need subdomain for mx " mail server " if you use debian, ubuntu: then hostname is like domain name, if it the same then they need to speak only one of them, if someone new user want to install debian server and he see hostname and after he read domain he will not know what it mean.
Hey /u/hayjumper
> Based on http://www.postfix.org/postconf.5.html it seems you probably need both virtualmailbox* params listed above... am I reading it correct that with both uncommented you can receive mail but not send?
When I uncomment those you are right. I am able to receive mail either from my personal gmail, same domain hosted on google, as well as internally from mailcow. I am able to also send mail to my personal gmail. When I try to send to my email ID hosted on google I get this error in the log: NOQUEUE: reject: RCPT from mail-oi0-x261.google.com[2607:f8b0:4003:c06::261]: 454 4.7.1
Also good call on the MX record, I updated it to be a higher number to be hit last.
edit* should mention it seems that it is searching locally for the email ID and not finding it and either bounces or won't send. When I skip that it just sends it as expected but then won't accept mail. On github I got a bit of feedback but still no dice. https://github.com/mailcow/mailcow-dockerized/issues/380#issuecomment-310238722
Thank you
Apologies, I misread the part that you are already using Google for split domain (this part looks good).
Based on http://www.postfix.org/postconf.5.html it seems you probably need both virtual_mailbox_* params listed above... am I reading it correct that with both uncommented you can receive mail but not send?
The 550 5.1.1 error is 'recipient address rejected', I assume you've already checked the To: address is valid and should work?
Also, I think the Google MX records should have lower numbers than mail.domain.com, since mail will be delivered first to the record with the LOWEST numbered priority (this is somewhat backwards from what one would expect)... here is one explanation:
https://support.office.com/en-us/article/What-is-MX-priority-17d415c1-067e-4974-84d5-aaeaf3a0c0a9
Looks like just_insane linked a guide below which is a good start. I didn't really follow one guide but many, each for what I was trying to accomplish.
One for setting up the external MTA to forward all my mail and accept mail only for my domain and doing LDAPS checks to ensure the mailbox actually exists.
Another guide to setup amavisd to scan my and forward between my exchange and external MTA.
Another to setup exchange and forward all mail to my amavisd server
Is it possible for you to run your own mail server? At a high level this is how I would approach this problem.
Set up an SMTP server. My choice would probably be postfix, which is available in any major linux distribution.
Have my SMTP server deliver mail to a script that I would write. I've never done this, but there are many results when I search for how to do this with postfix. This example looks promising (though I wouldn't use PHP).
My script would arrange for the body of the email to be added to my database. Maybe it writes directly to the database, or adds to a pubsub queue, or calls some API on my web server. Any of the above could be situationally appropriate.
My web app reads the appropriate email bodies from the database when constructing the page.
Optionally, masquerade envelope sender addresses and message header addresses (i.e. strip host or domain information below all domains listed in the masquerade_domains parameter, except for user names listed in masquerade_exceptions). By default, address masquerading does not affect envelope recipients.
Also, this
So Postfix has different methods of "sending" the mail, none, may, encrypt, and others. The three I will list are the three that are most common.
none - At the "none" TLS security level, TLS encryption is disabled. This is the default security level, and can be configured explicitly by setting "smtp_tls_security_level = none".
may - At the "may" TLS security level, TLS encryption is opportunistic. The SMTP transaction is encrypted if the STARTTLS ESMTP feature is supported by the server. Otherwise, messages are sent in the clear. Opportunistic TLS can be configured by setting "smtp_tls_security_level = may".
encrypt - At the "encrypt" TLS security level, messages are sent only over TLS encrypted sessions. The SMTP transaction is aborted unless the STARTTLS ESMTP feature is supported by the remote SMTP server. If no suitable servers are found, the message will be deferred. Mandatory TLS encryption can be configured by setting "smtp_tls_security_level = encrypt". Even though TLS encryption is always used, mail delivery continues even if the server certificate is untrusted or bears the wrong name.
I would recommend setting your system up for "may" as that will attempt to use encryption when sending the message, but will fallback to unencrypted if the host does not support encryption.
You can google for 'smtp_tls_security_level postfix' to lookup more info, but I did a quick google search and found this guide, that might help you.
depends on how much work you want to do, or how effective you want it to be.
setup postfix as a relay and put some basic rules in it like checking RBLs and making sure headers are formatted correctly, maybe even greylisting.. and you have yourself a basic spam filter.
Need to do better than that? Well then you're in luck, because there's a whole list of goodies
http://www.postfix.org/addon.html
Note that pretty much every commercial spam filtering device is built on postfix and some combination of open source and custom software. usually what you're paying for is the pretty interface that ties it all together.
IMO, yes, it could. And I think it's not the smart way to "filter" emails. That's the mail filter's job.
If you insist in using reject_unknown_client_hostname or even reject_unknown_helo_hostname, at least try to use warn_if_reject before each option, so you can see in the logs, what will be rejected if the option is fully activated: http://www.postfix.org/postconf.5.html#warn_if_reject
Postfix doc does mention all, see it near the bottom of this page:
http://www.postfix.org/SASL_README.html#smtpd_sasl_security_options
> We close this section with an example that passes every mechanism except for GSSAPI and LOGIN:
/etc/postfix/main.cf: smtp_sasl_mechanism_filter = !gssapi, !login, static:all
You should really use postscreen and only reject messages based on a combined score derived from several blacklists.
http://www.postfix.org/POSTSCREEN_README.html
If you reject, based on one list's opinion about a sending IP, it is highly likely that you will be blocking legitimate messages.
Have you looked at the postfix documentation? The documentation is littered with flowcharts how postfix handles the individual email messages. For example: http://www.postfix.org/OVERVIEW.html IMHO it gives a rather good overview of how mail is handled.
Also take a look at http://www.postfix.org/CONTENT_INSPECTION_README.html
It feels a bit lazy tho to just point at the documentation, but it gives a lot better exmplanation at these things than I might manage.
It took me way too long to figure out how to configure postfix for this type of application the first time because I didn't know what I was really searching for. If you, like I was, are using an external mail server to send messages on behalf of the webserver (also known as an SMTP relay), you're looking to create a null client, and it's really easy to set up.
exim, qmail, and postfix are all capable of doing what you want, to various degrees.
Configuration of how usernames map across domains (i.e., if I have foo@domain1 do I have foo@domain2 as well?) is the main difference.
I hate to recommend this, but look into how the web hosting control panels (plesk, cpanel, directadmin) do it. This is a common problem they all address with various different implementations under the hood.
Not OP, but I've built SMTP relays for sending bulk marketing mail. Postfix supports VERP where the return-path address is an encoded version of the recipient address at the postfix server's domain. Postfix then sends messages to addresses matching this pattern to a script you write that removes the offending address from your database.
Here is a pretty recent guide on using CentOS 7 & Postfix to setup Store and Forward. http://www.jnvilo.com/cms/sysadmin/linux/mail-server-administration/postfix--store-and-foreward-howto-with-anti-spam-configuration
You will have to change the relay_host setting in Postfix to use a differnt tcp port for your home email server. http://www.postfix.org/SOHO_README.html
That should work. If you were wanting to use a different distro (Ubuntu for example), you can lookup a guide for installing Postfix on that distro... the configuration examples above will work for any modern *nix distro.
So instead of it coming from it's coming from ?
Sounds like the myorigin setting is set to $myhostname instead of $mydomain in /etc/postfix/main.cf:
myorigin = $mydomain
http://www.postfix.org/postconf.5.html#myorigin
Maybe post a diff of the main.cf between the two servers.