0

I am trying to relay emails to Office 365 and have configured postfix as follows:

meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
myhostname = mail.disorderly-order.com
mydomain = disorderly-order.com
myorigin = $mydomain
mynetworks = 127.0.0.0/8, 10.10.0.0/16
smtp_generic_maps = hash:/etc/postfix/generic
relayhost = disorderlyorder-com02e.mail.protection.outlook.com

I have followed instructions on this website to setup the connector: http://kb.eclipseinc.com/kb/postfix-relay-office365/. I have set relayhost as disorderlyorder-com02e.mail.protection.outlook.com which is the value for the MX record.

When I send mail, nothing goes through. Below is my journalctl logs. I can see it sending email to [email protected] but I haven't sent any email to this address. I have only sent emails to [email protected].

Jul 10 22:04:40 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 27A0D10136330: from=<[email protected]>, size=488, nrcpt=1 (queue active)
Jul 10 22:04:40 vxmail.livedemo.vdevops.info postfix/smtp[740108]: 27A0D10136330: to=<[email protected]>, relay=disorderlyorder-com02e.mail.protection.outlook.com[104.47.71.202]:>
Jul 10 22:04:40 vxmail.livedemo.vdevops.info postfix/cleanup[740106]: F0E0510136331: message-id=<[email protected]>
Jul 10 22:04:40 vxmail.livedemo.vdevops.info postfix/bounce[740109]: 27A0D10136330: sender non-delivery notification: F0E0510136331
Jul 10 22:04:40 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: F0E0510136331: from=<>, size=3299, nrcpt=1 (queue active)
Jul 10 22:04:40 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 27A0D10136330: removed
Jul 10 22:04:41 vxmail.livedemo.vdevops.info postfix/smtp[740108]: F0E0510136331: to=<[email protected]>, relay=disorderlyorder-com02e.mail.protection.outlook.com[104.47.71.138]:>
Jul 10 22:04:41 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: F0E0510136331: removed
Jul 10 22:05:26 vxmail.livedemo.vdevops.info postfix/pickup[740098]: 62B9C10136330: uid=0 from=<root>
Jul 10 22:05:26 vxmail.livedemo.vdevops.info postfix/cleanup[740106]: 62B9C10136330: message-id=<[email protected]>
Jul 10 22:05:26 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 62B9C10136330: from=<[email protected]>, size=910, nrcpt=1 (queue active)
Jul 10 22:05:26 vxmail.livedemo.vdevops.info postfix/smtp[740108]: 62B9C10136330: to=<[email protected]>, orig_to=<root>, relay=disorderlyorder-com02e.mail.protection.outlook.com>
Jul 10 22:05:27 vxmail.livedemo.vdevops.info postfix/cleanup[740106]: 0DCAC10136331: message-id=<[email protected]>
Jul 10 22:05:27 vxmail.livedemo.vdevops.info postfix/bounce[740109]: 62B9C10136330: sender non-delivery notification: 0DCAC10136331
Jul 10 22:05:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 0DCAC10136331: from=<>, size=3626, nrcpt=1 (queue active)
Jul 10 22:05:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 62B9C10136330: removed
Jul 10 22:05:27 vxmail.livedemo.vdevops.info postfix/smtp[740108]: 0DCAC10136331: to=<[email protected]>, relay=disorderlyorder-com02e.mail.protection.outlook.com[104.47.71.202]:>
Jul 10 22:05:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 0DCAC10136331: removed
Jul 10 22:06:26 vxmail.livedemo.vdevops.info postfix/pickup[740098]: 77AA310136330: uid=0 from=<root>
Jul 10 22:06:26 vxmail.livedemo.vdevops.info postfix/cleanup[740106]: 77AA310136330: message-id=<[email protected]>
Jul 10 22:06:26 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 77AA310136330: from=<[email protected]>, size=910, nrcpt=1 (queue active)
Jul 10 22:06:27 vxmail.livedemo.vdevops.info postfix/smtp[740108]: 77AA310136330: to=<[email protected]>, orig_to=<root>, relay=disorderlyorder-com02e.mail.protection.outlook.com>
Jul 10 22:06:27 vxmail.livedemo.vdevops.info postfix/cleanup[740106]: 233FA10136331: message-id=<[email protected]>
Jul 10 22:06:27 vxmail.livedemo.vdevops.info postfix/bounce[740109]: 77AA310136330: sender non-delivery notification: 233FA10136331
Jul 10 22:06:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 233FA10136331: from=<>, size=3626, nrcpt=1 (queue active)
Jul 10 22:06:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 77AA310136330: removed
Jul 10 22:06:27 vxmail.livedemo.vdevops.info postfix/smtp[740108]: 233FA10136331: to=<[email protected]>, relay=disorderlyorder-com02e.mail.protection.outlook.com[104.47.71.202]:>
Jul 10 22:06:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 233FA10136331: removed
Jul 10 22:07:26 vxmail.livedemo.vdevops.info postfix/pickup[740098]: 853A310136330: uid=0 from=<root>
Jul 10 22:07:26 vxmail.livedemo.vdevops.info postfix/cleanup[740106]: 853A310136330: message-id=<[email protected]>
Jul 10 22:07:26 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 853A310136330: from=<[email protected]>, size=910, nrcpt=1 (queue active)
Jul 10 22:07:27 vxmail.livedemo.vdevops.info postfix/smtp[740108]: 853A310136330: to=<[email protected]>, orig_to=<root>, relay=disorderlyorder-com02e.mail.protection.outlook.com>
Jul 10 22:07:27 vxmail.livedemo.vdevops.info postfix/cleanup[740106]: 2F6B810136331: message-id=<[email protected]>
Jul 10 22:07:27 vxmail.livedemo.vdevops.info postfix/bounce[740109]: 853A310136330: sender non-delivery notification: 2F6B810136331
Jul 10 22:07:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 2F6B810136331: from=<>, size=3626, nrcpt=1 (queue active)
Jul 10 22:07:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 853A310136330: removed
Jul 10 22:07:27 vxmail.livedemo.vdevops.info postfix/smtp[740108]: 2F6B810136331: to=<[email protected]>, relay=disorderlyorder-com02e.mail.protection.outlook.com[104.47.71.202]:>
Jul 10 22:07:27 vxmail.livedemo.vdevops.info postfix/qmgr[740099]: 2F6B810136331: removed

I have also tried creating a mapping for the root user to a valid email address. It is not working as I can still see the sender as [email protected] in journalctl. Here is what I did.

Added the following line to /etc/postfix/main.cf:

smtp_generic_maps = hash:/etc/postfix/generic

Addeed the required email address alias to /etc/postfix/generic:

root [email protected]

Created the hash file and reload postfix:

postmap /etc/postfix/generic
service postfix reload
3
  • Is there anything in the /var/log/maillog or similar hiding place for mail logs? Because that's where the logs for why the remote server is rejecting the message should be.
    – thrig
    Jul 10, 2022 at 13:24
  • @thrig See those lone > characters at the end of the postfix/smtp log messages, all at exactly the right-most column used by the listing? Those are the tell-tale sign of journalctl using less -FRSXMK as its default pager. It's chopping off the ends of the lines at window edge, requiring the user to press the right-arrow key to scroll right to see the rest of the lines.
    – telcoM
    Jul 10, 2022 at 15:41
  • @thrig The status of the relay attempt should be right there at the end of each postfix/smtp log line, in the form of dsn=N.N.N status=something (NNN N.N.N some text). But unless you know about the default pager option choice of the systemd suite, you might not catch that you're not seeing everything there is to see.
    – telcoM
    Jul 10, 2022 at 15:49

1 Answer 1

3

When reading mail server logs, you'll need to pay attention to the queue IDs mentioned: without them, you won't be able to keep track which message each log line is about.

postfix/qmgr[740099]: 27A0D10136330: [email protected], size=488, nrcpt=1 (queue active)

The queue manager is processing a queued message with ID 27A0D10136330, apparently sent by the root user.

postfix/smtp[740108]: 27A0D10136330: [email protected], relay=disorderlyorder-com02e.mail.protection.outlook.com[104.47.71.202]:>

It's being relayed to 104.47.71.202 which is one of the two IP addresses associated with the name in your MX record.

The unpaired > at the end indicates there is more on this log line, but it's being cut off by the window edge. This is unfortunate, as the end of the line would have contained the status reported by the relay host, which would have been important to know.

(The version of journalctl/systemd in your system apparently uses less -FRSXMK as its pager. The S is the option responsible for this line-chopping behavior. You probably can use the right and left arrow keys while viewing the log to view the rest of the long lines.

If you - like me - don't like this behavior, add export SYSTEMD_LESS=FRXMK to your ~/.bashrc or other suitable shell start-up script to disable it and just let long lines be wrapped.)

postfix/cleanup[740106]: F0E0510136331: message-id=20220710120440.F0E0510136331@mail.disorderly-order.com

postfix/bounce[740109]: 27A0D10136330: sender non-delivery notification: F0E0510136331

Unfortunately, that did not work out: the relay host apparently rejected the message, and a non-delivery notification email is being generated for message ID 27A0D1013633. The new message ID of the non-delivery notification email is F0E0510136331.

postfix/qmgr[740099]: F0E0510136331: from=<>, size=3299, nrcpt=1 (queue active)

The queue manager begins processing the non-delivery notification...

postfix/qmgr[740099]: 27A0D10136330: removed

... and removes the original message 27A0D10136330 from the queue. Since the relay host apparently reported a permanent fatal error, waiting and retrying won't help. So that's The End for that message.

postfix/smtp[740108]: F0E0510136331: [email protected], relay=disorderlyorder-com02e.mail.protection.outlook.com[104.47.71.138]:>

Then the non-delivery notification message is being relayed to 104.47.71.138, which is the second IP address associated with the name in your MX record. Again, > indicates the status of the relay attempt is being cut off.

postfix/qmgr[740099]: F0E0510136331: removed

Since message F0E0510136331 was already an error report email, any failures in its delivery won't cause another error report to be generated (to avoid an endless storm of error messages of 2nd, 3rd, etc. degree generated by a configuration error).

This pattern then repeats for all your mail sending attempts.

To figure out what is going wrong, you would really need the status codes at the end of those long log lines, and ideally the contents of the bounce message too. So while you're troubleshooting, remove the root alias you placed into /etc/postfix/generic, and remake the hash map file. Then the bounces should start collecting into /var/mail/root, which you can read with any mail client that is capable of accessing local Unix-style mailbox files - or even with just less /var/mail/root if necessary.

You can add the alias back once you got the basic mail relaying working.

2
  • It seems I've now been blocked by Microsoft: Access denied, banned sending IP. I have requested for IP to be removed. Do you know if simple relay works for Office 365?
    – supmethods
    Jul 11, 2022 at 11:18
  • Simple relay does work for Office 365. Thank you for your guidance.
    – supmethods
    Jul 11, 2022 at 11:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .