Technical Tip: Unable to send FortiToken email using custom SMTP server starting v7.4.4

[rvillaroman]

Description

This article describes that the option to customize the reply-to field for notification email servers is no longer available from FortiOS v7.4.4 or v7.6.1. 

Scope

FortiOS v7.4.4, v7.6.1 and newer.

Solution

When upgrading to v7.4.4 and 7.6.1, the reply-to field will be automatically changed to DoNotReply@fortinet-notifications.com in the email server settings. This will affect all SMTP servers including custom servers. When upgrading to v7.4.7 or v7.6.2, this change is not enforced for custom servers, but the change still impacts email sending in certain cases.

On a custom SMTP server like Office 365, it is necessary to have the username and the 'reply-to' sender in the same domain, and with the same value. However, because the reply-to field is automatically changed to DoNotReply@fortinet-notifications.com once the devices are upgraded to v7.4.4/7.6.1, the emails will no longer be sent by the email server.

In the later versions, v7.4.7/v7.6.2+, the email used as 'reply-to' will be the same as the destination email (To: and From: will have the same value). This also seems to cause some problems in certain servers - to be verified on the custom email-server provider.

The output that shows the 'reply-to' option is no longer available in newer versions, and thus cannot be changed.

config system email-server

    set type custom                                          

    set server "smtp.office.365.com"

    set port 587

    set source-ip 0.0.0.0

    set source-ip6 ::

    set authenticate enable

    set validate-server disable

    set username "token@notify.fortinet.com"

    set password ENC ***

    set security starttls

    set ssl-min-proto-version default

    set interface-select-method auto

end

As a result, every attempt to send a FortiToken email will fail, and it will show the result of 'buffer full'.

2024-05-24 12:32:34 sessionn 0xa16c070, SSL connected

2024-05-24 12:32:34 session: 0xa16c070, rsp_state: ehlo, code: 250

2024-05-24 12:32:34 session: 0xa16c070, rsp_state: auth, code: 334

2024-05-24 12:32:34 session: 0xa16c070, rsp_state: auth2, code: 235

2024-05-24 12:32:34 session: 0xa16c070, rsp_state: mail, code: 250

2024-05-24 12:32:34 session: 0xa16c070, rsp_state: rcpt, code: 250

2024-05-24 12:32:34 session: 0xa16c070, rsp_state: data, code: 354

2024-05-24 12:32:34 buffer is full

2024-05-24 12:32:34 _session_on_destroy

2024-05-24 12:32:34 <== send mail failed, m = 0xa151cc0 s = 0xa16c070

Solution:
The issue is resolved in v7.6.1 and v7.4.5.

The Solution means that during the upgrade, the 'reply-to' field will not be forcefully changed to 'DoNotReply@fortinet-notifications.com'.

The reply-to field will no longer be available, or customizable, and as 'reply-to' it will use the email defined for the user.

Note:

Bug ID 0966140.

Reply-to is hard coded to DoNotReply@fortinet-notifications.com for both the customized server and 'fortinet-notifications.com'.
Bug ID 1036265.

Reply-to option under config system alertmail is removed even for custom mailservers with 2-FA (removed, not enforced).

Workaround:

Use the default FortiGate SMTP server (default values - set the server to 'fortinet-notifications.com'), or for a custom email server, it must use authentication.

Note:  

To use the default Fortinet email server, it is necessary to register the device on FortiCare support and have an active contract.