Description
Solution
This article explains how to authenticate Microsoft Office365 users where Active Directory or LDAP services are not available
Solution
Authentication Server
To authenticate Office365 users with Fortimail the following settings should be used
Authentication type: POP3
Profile name: Office365_Auth
Server name/IP: outlook.office365.com
Server port: 995
Authentication mechanism: AUTO
SSL/TLS: CHECKED
STARTTLS: UNCHECKED
Secure authentication: UNCHECKED
Server requires domain: CHECKED
Mail hop count exceeded
Sending mails to other users on the Office365 domain may cause the email to be bounced with the error hop count exceeded.
This is caused by an Office365 mail rule used to forward mail to FortiMail (or any other MTA).
To resolve this, log into the Exchange admin center for Office365:
-Access the mail rules under mail flow.
-Edit the outbound mail rule you created to send mail to
the FortiMail.
-Under “Except if...” add in a new exception that will
match if the header contains your FortiMail domain name (found on the FortiMail under System -> Mail Settings)
Cause:
- Office365 servers sends the mail to the FortiMail
- FortiMail processes the mail
- The mail is then
forwarded it to another Office365 server using the recipient's Office365 MX record
Note: If the sender and recipient are using the same domain, the mail forwarding rule configured to send mails to the same domain MTA causes the loop.
- In this instance the rule causes the Office365 servers to look for messages already processed by FortiMail, preventing them from being continuously forwarded to FortiMail, instead the mails are sent to the actual recipient.
Recipient Verification
Configuring FortiMail to Office365 recipient verification:Recipient verification works by opening a session with the target SMTP server e.g Office365 and executing the following commands :
- EHLO
- MAIL FROM
- RCPT TO
The target Email address in the
RCPT TO is analysed in the response to see if the address exists.
The default value of MAIL FROM in FortiMail is left as a null value which can cause the Office365 service to fail
The solution is to define a source email address (e.g. noreply@domain.com)
Configure FortiMail MAIL FROM settings:
# config mailsetting smtp-rcpt-verification
# set mail-from-addr noreply@domain.com
# end
The MAIL FROM: default null value is replaced with noreply@domain.com
NOTE: This fix is for situations where you can telnet from the FortiMail to the Office365 server:
- Use a non-existent address in the RCPT TO field
- The rejection message is sent but recipient verification still fails
- If the Office365 sever
responds with an OK then the issue lies on the Microsoft configuration.
