|
Make sure to have a working WAN link to send out the email. Do a test ping to the default mail server: notification.fortinet.net or fortinet-notifications.com
Since v7.4.4, the default email server has been changed from notification.fortinet.net to fortinet-notifications.com.
execute ping fortinet-notifications.com
PING fortinet-notifications.com (208.91.114.151): 56 data bytes
64 bytes from 208.91.114.151: icmp_seq=0 ttl=55 time=146.9 ms
64 bytes from 208.91.114.151: icmp_seq=1 ttl=55 time=147.2 ms
64 bytes from 208.91.114.151: icmp_seq=2 ttl=55 time=146.9 ms
64 bytes from 208.91.114.151: icmp_seq=3 ttl=55 time=146.7 ms
64 bytes from 208.91.114.151: icmp_seq=4 ttl=55 time=147.3 ms
Check the existing configuration in FortiGate.
Below is an example of default settings:
get system email-server
type : custom
reply-to :
server : notification.fortinet.net
port : 465
source-ip : 0.0.0.0
source-ip6 : ::
authenticate : disable
validate-server : disable
security : smtps
ssl-min-proto-version: default
interface-select-method: auto
In some cases, it is necessary to configure the interface manually:
set interface-select-method
auto Set outgoing interface automatically.
sdwan Set outgoing interface by SD-WAN or policy routing rules.
specify Set outgoing interface manually.
When the custom email server is used on FortiGate to send the emails out from the FortiGate for purposes like FortiToken Activation Email or Email Alerts, the emails may not be received on the user side.
Check the connection to the Email Server:
- Make sure FortiGate can reach the email server.
- Try to ping the email server to verify the connectivity.
exe ping <SMTP server IP>
- If the email server is beyond the IPsec tunnel, set the source IP in the email server settings of the FortiGate with the internal interface IP so that FortiGate can reach the server over the tunnel.
config system email-server
...
set source-ip {ipv4-address}
...
end
Run the alert mail debugs:
- Once the connection to the server is successful, run the following alert email debugs to see if there are any errors.
diagnose debug reset
diagnose debug enable
diagnose debug console timestamp enable
diagnose debug application alertmail -1
- After enabling the email, try to send the activation mail again or trigger a test mail.
diagnose log alertmail test
Note:
This test will send out the test mail to the email address that is configured in the alertmail setting ('conf alertmail setting').
If it is not configured, no emails will be sent out.
Refer to this article to configure it: Technical Tip: How to configure alert email settings.
Troubleshooting:
- If, as per the debug, the 'send mail success' message appears and the email is still not received, try to change the recipient email address to any public domain (Gmail or Yahoo).
- This is because sometimes spam filters are in place on the corporate email that block or archive emails.
- Still, after making the change, emails are not received; make sure to have set the default-reply-to email in the email server settings (only older versions. In newer versions, reply-to is no longer configurable: Technical Tip: Unable to configure 'Default Reply To' via GUI and CLI).
If that is not set, the debugs will show 'send mail success', but the mails will not be received.
config system email-server
set server "<Email server IP>"
set reply-to "admin@example.com"
If any failures or errors show in the debugs, check for the following things:
- If the credentials entered for the SMTP server and port number are correct.
- Verify the Protocol with the server as well (SMTP or SMTPS).
- Run a packet sniffer for the email server IP and see if there is bidirectional traffic.
diagnose sniffer packet any 'host <server IP> and port <port no>' 4 0 l
If the issue persists, collect all the debugs and the output of the above commands and submit them to the TAC ticket along with the configuration file of the FortiGate.
Then, disable debug:
diagnose debug disable
diagnose debug reset
Save the output either by downloading it via the CLI window or using the Putty tool to log it, to attach the debug logs to the case for TAC review.
Output of the Email Alert Debug:
The debug below shows the important messages to check during the troubleshooting:
diagnose debug reset
diagnose debug enable
diagnose debug console timestamp enable
diagnose debug application alertmail -1
Debug messages will be on for 30 minutes.
2024-11-25 00:04:42 Arrived msg(type 8, 818 bytes):XXXXXX@gmail.com <- User's email.
/data2/tmp/ftm_qr_FTKMOB4B64FDA57B.png <- QR code sent in the email.
FTM Activation on FortiGate <- Message body (Beginning of the message)
Welcome to FortiToken Mobile - One-Time-Password software token.
Please visit https://docs.fortinet.com/ftoken.html
for instructions on how to install your FortiToken Mobile application on your device and activate your token.
You must use FortiToken Mobile version 2 or above to activate this token.
Your Activation Code, which you will need to enter on your device later, is
"EEIJEOT7WMAVXDHV"
Alternatively, use the attached QR code image to activate your token with the "Scan Barcode" feature of the app.
You must activate your token by:
Thu Nov 28 00:04:42 2024 (GMT-5:00) Eastern Time (US & Canada),
after which you will need to contact your system administrator to
re-enable your activation.
FortiGate
2024-11-25 00:04:42 mail_info:
from:notification.fortinet.net user:DoNotReply@notification.fortinet.net
2024-11-25 00:04:42 mail_info:
reverse path:DoNotReply@notification.fortinet.net
user name:DoNotReply <- Message body (End of the the message).
2024-11-25 00:04:42 to[0]:XXXXXX@gmail.com
2024-11-25 00:04:42 <==_init_mail_info
2024-11-25 00:04:42 create session <- SMTP session.
2024-11-25 00:04:42 resolve notification.fortinet.net to 1 IP
2024-11-25 00:04:42 ==> send mail <- FortiGate Sending the email.
2024-11-25 00:04:42 connecting to 208.91.114.151 port 465
2024-11-25 00:04:42 send mail 0xca410a0 session 0xca42460
2024-11-25 00:04:42 session_io_event: creating ssl structure for session 0xca42460
2024-11-25 00:04:42 ssl_init
2024-11-25 00:04:42 create_ssl_ctx
2024-11-25 00:04:42 create_ssl: 0x7f8106334000
2024-11-25 00:04:42 sessionn 0xca42460, SSL connected
2024-11-25 00:04:43 session: 0xca42460, rsp_state: greeting, code: 220
2024-11-25 00:04:43 session: 0xca42460, rsp_state: ehlo, code: 250
2024-11-25 00:04:43 session: 0xca42460, rsp_state: mail, code: 250
2024-11-25 00:04:43 session: 0xca42460, rsp_state: rcpt, code: 250
2024-11-25 00:04:43 session: 0xca42460, rsp_state: data, code: 354
2024-11-25 00:04:43 session: 0xca42460, rsp_state: data2, code: 250
2024-11-25 00:04:43 session: 0xca42460, rsp_state: quit, code: 221
2024-11-25 00:04:43 session finined <- End of SMTP session.
2024-11-25 00:04:43 _session_on_destroy
2024-11-25 00:04:43 <== send mail success, m = 0xca410a0 s = 0xca42460 <- Email successfully sent to destination.
Note:
In some alert emails debugs the below logs can also be seen:
2024-12-31 10:19:58 connecting to 10.10.110.39 port 587
2024-12-31 10:19:58 session_io_event: creating ssl structure for session 0xaecf560
2024-12-31 10:19:58 create_ssl: 0x7f7de5174000
2024-12-31 10:19:58 error in SSL_connect (null)
The above error is seen when using an SSL-enabled security mode under the email-server settings as follows:
config system email-server
set server "10.10.110.39"
set port 587
set source-ip 10.10.90.1
set security smtps
To bypass this error, use 'set security none'.
Note:
In some cases, it is possible to see an error with 'code: 530', which will ideally state that the issue is with the server, specifically, that the client would not be successfully authenticated by the server. This can also be confirmed by taking a packet capture in the firewall for the port that is being listened to by the email server.
024-09-02 21:53:38 create_ssl: 0x7f9561385000
2024-09-02 21:53:38 session 0xef79390, SSL connected
2024-09-02 21:53:39 session: 0xef79390, rsp_state: greeting, code: 220
2024-09-02 21:53:39 session: 0xef79390, rsp_state: ehlo, code: 250
2024-09-02 21:53:39 session: 0xef79390, rsp_state: mail, code: 530
Note:
In the alertmail debugs, check whether the sender and receiver email addresses are different. Sometimes, if the sender and receiver email addresses are the same, the email server blocks the email send request. See the example logs below where the sender and receiver email addresses are the same:
WIG-FGT-01 (global) # Arrived msg(type 6, 83 bytes):sajeermkit@gmail.com
AuthCode: 240126
Your authentication token code is 240126.
mail_info:
from:192.168.77.31 user:sajeermkit@gmail.com <- Sender.
mail_info:
reverse path:sajeermkit@gmail.com
user name:sajeermkit
to[0]:sajeermkit@gmail.com <- Receiver.
Note:
Starting from v7.4.4, the default email server has been switched from notification.fortinet.net to fortinet-notifications.com. This default server is only available to registered devices with an active FortiCare support contract. The reply-to field in the source email is automatically updated to DoNotReply@fortinet-notifications.com for all servers, including custom ones.
Related articles:
Technical Tip: How to configure alert email settings
Technical Tip: Unable to send reports or activation email from FortiGate
Troubleshooting Tip: Alertmail queries
Technical Tip: Send mail failed due to ‘buffer is full’ when trying to authenticate FortiToken Mobil...
Technical Tip: Unable to configure 'Default Reply To' via GUI and CLI
|
