Postfix rejects emails relayed from O365
I have to do a migration of Office 365 from Postfix with Sogo. My goal is to configure small hybrid of Office 365 with Postfix, a bit the same way you do with Exchange On-premises.
Currently, postfix is a primary server with 1000 users and it sends and receives all emails for a domain.xyz. I've configured Office 365 and added same domain to it. I've created 2 mailboxes on it and configured Exchange Online that domain.xyz is set as InternalRelay domain.
Exchange online has so far 2 accounts
Exchange is configured that if someone on Exchange sends an email to domain.xyz and the mailbox is on Exchange the email should stay on Exchange, but if Exchange can't find the mailbox for domain.xyz it should use Outgoing Connector which I've configured to forward email to postfix. This means that any email sent from userA to userB works fine, but the moment userA sends an email to userC which resides on postfix - it blocks it.
Reported error: 554 5.7.1 [email protected]: Recipient address rejected: Policy rejection not logged in
My understanding is that Postfix thinks it's the only server that owns the domain domain.xyz and it treats any email from domain.xyz as some user/service trying to send an email without authorization and it denies it. This is proving when we create totally random email in Office 365 that doesn't have respective account in postfix and when trying to send an email from [email protected] to [email protected] we get
Remote Server returned '550 5.1.0 [email protected]: Sender address rejected: User unknown in virtual mailbox table'
What's a way to tell postfix (SoGo) to start trusting Office 365 (ip addresses range) and make it allow to receive email from domain it thinks it owns, and for accounts that it has. At the last step of migration of postfix to Office 365 each account in postfix will have identical account in O365 and we will be using redirection of emails 1 mailbox at time to onmicrosoft.com address to make sure users can use O365 without need to worry about their postfix account. But for that to happen traffic between O365 and postfix needs to work.
My guess it's not only problem for Office 365 co-existance, but any service such as SendGrid or similar that someone would use would have identical issue.
Last - I have no access to postfix/sogo. I only "own" o365 side. I'm trying to provide input to the Linux/Postfix team to fix this
Potentially relevant configuration bits that I got from the team, but I myself have no clue if that's correct
# HELO restriction
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
check_helo_access pcre:/etc/postfix/helo_access.pcre
# Sender restrictions
smtpd_sender_restrictions =
reject_unknown_sender_domain,
reject_non_fqdn_sender,
reject_unlisted_sender,
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access pcre:/etc/postfix/sender_access.pcre
#reject_sender_login_mismatch
# Recipient restrictions
smtpd_recipient_restrictions =
reject_unknown_recipient_domain,
reject_non_fqdn_recipient,
reject_unlisted_recipient,
check_policy_service inet:127.0.0.1:7777,
permit_mynetworks,
permit_sasl_authenticated,
#reject_unauth_destination
# Data restrictions
smtpd_data_restrictions = reject_unauth_pipelining
# O365 addresses
mynetworks = 127.0.0.0/8, 40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 104.47.0.0/17
#
# Lookup virtual mail accounts
#
transport_maps =
#regexp:/etc/postfix/transport_regexp
proxy:ldap:/etc/postfix/ldap/transport_maps_user.cf
proxy:ldap:/etc/postfix/ldap/transport_maps_domain.cf
sender_dependent_relayhost_maps =
proxy:ldap:/etc/postfix/ldap/sender_dependent_relayhost_maps_user.cf
proxy:ldap:/etc/postfix/ldap/sender_dependent_relayhost_maps_domain.cf
# Lookup table with the SASL login names that own the sender (MAIL FROM) addresses.
smtpd_sender_login_maps =
proxy:ldap:/etc/postfix/ldap/sender_login_maps.cf
virtual_mailbox_domains =
proxy:ldap:/etc/postfix/ldap/virtual_mailbox_domains.cf
relay_domains =
$mydestination
proxy:ldap:/etc/postfix/ldap/relay_domains.cf
virtual_mailbox_maps =
proxy:ldap:/etc/postfix/ldap/virtual_mailbox_maps.cf
virtual_alias_maps =
#regexp:/etc/postfix/transport_regexp
proxy:ldap:/etc/postfix/ldap/virtual_alias_maps.cf
proxy:ldap:/etc/postfix/ldap/virtual_group_maps.cf
proxy:ldap:/etc/postfix/ldap/virtual_group_members_maps.cf
proxy:ldap:/etc/postfix/ldap/catchall_maps.cf
proxy:ldap:/etc/postfix/ldap/sender_login_maps.cf
sender_bcc_maps =
proxy:ldap:/etc/postfix/ldap/sender_bcc_maps_user.cf
proxy:ldap:/etc/postfix/ldap/sender_bcc_maps_domain.cf
recipient_bcc_maps =
proxy:ldap:/etc/postfix/ldap/recipient_bcc_maps_user.cf
proxy:ldap:/etc/postfix/ldap/recipient_bcc_maps_domain.cf
In master.cf
smtps inet n - n - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
# -o smtpd_client_restrictions=permit_sasl_authenticated,permit_mynetworks
# -o smtpd_client_restrictions=$mua_client_restrictions
# -o smtpd_helo_restrictions=$mua_helo_restrictions
# -o smtpd_sender_restrictions=$mua_sender_restrictions
# -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATING
Any ideas would be welcome.
Solution 1:
It seems that order of rules matters!
- smtpd_helo_restrictions
- smtpd_sender_restrictions
- smtpd_recipient_restrictions
This means if you want to allow all o365 addresses to be always allowed the permit_mynetworks rule must be on top of each rule (or the one that is responsible for blocking). Once the rule is moved to the top everything started working and it resolved the first problem.
The 2nd error is most likely related to global settings
# Reject unlisted sender and recipient
smtpd_reject_unlisted_recipient = yes
smtpd_reject_unlisted_sender = yes
Which have priority over the rules defined under sender restrictions and recipient restrictions - so it would seem by disabling those - the rules would be allowed as well. I have not tested this - but this is my bet and as we won't have such need to test it I'll leave it for someone else to find out :-)