| Description |
This article describes how to resolve 'buffer is full’ in alertmail debug logs when a customer is trying to provision FortiToken Mobile. |
| Scope | FortiGate. |
| Solution |
Scenario: The user is using smtp.office365.com as an SMTP server. A sample of the initial configuration is shown below.
Email-Server:
config system email-server
UserLocal:
config user local edit "aljor" set type password set two-factor fortitoken set fortitoken "FTKMOB9A28E1BABB" set email-to "aljor@fortinet.com" set passwd ENC *** next end
With this configuration, the user is unable to receive any FortiToken Activation code on the email.
Troubleshooting:
Debug:
diag debug reset diag debug console timestamp enable diag debug app alertmail -1 diag debug enable
(root) # 2023-06-14 12:32:34 Arrived msg(type 8, 827 bytes):aljor@fortinet.com /data2/tmp/ftm_qr_FTKMOB32FE0765BF.png FTM Activation on FortiGate 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
"FTKMOB9A28E1BABB"
Alternatively, use the attached QR code image to activate the FortiToken with the 'Scan Barcode' feature of the app:
Sat Jun 17 00:30:35 2023 (GMT+8:00) Kuala Lumpur, Singapore, after which you will need to contact your system administrator to re-enable your activation.
FortiGate:
2023-06-14 12:32:34 mail_info: from:smtp.office365.com user:donotreply@notify.fortinet.com 2023-06-14 12:32:34 mail_info: reverse path:donotreply@notify.fortinet.com user name:donotreply 2023-06-14 12:32:34 to[0]:aljor@fortinet.com 2023-06-14 12:32:34 <==_init_mail_info 2023-06-14 12:32:34 create session 2023-06-14 12:32:34 resolve smtp.office365.com to 1 IP 2023-06-14 12:32:34 ==> send mail 2023-06-14 12:32:34 connecting to 52.98.33.130 port 587 2023-06-14 12:32:34 send mail 0xa151cc0 session 0xa16c070 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: greeting, code: 220 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: ehlo, code: 250 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: starttls, code: 220 2023-06-14 12:32:34 rsp_starttls: creating ssl structure for session 0xa16c070 2023-06-14 12:32:34 create_ssl: 0x7f772c0000 2023-06-14 12:32:34 sessionn 0xa16c070, SSL connected 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: ehlo, code: 250 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: auth, code: 334 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: auth2, code: 235 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: mail, code: 250 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: rcpt, code: 250 2023-06-14 12:32:34 session: 0xa16c070, rsp_state: data, code: 354 2023-06-14 12:32:34 buffer is full 2023-06-14 12:32:34 _session_on_destroy 2023-06-14 12:32:34 <== send mail failed, m = 0xa151cc0 s = 0xa16c070
Solution: It seems that the SMTP server is seeing a different user than the defined username on the config thus resulting in ‘buffer is full’. To resolve this, the ‘reply-to’ and ‘username’ addresses should be the same.
config system email-server
Debug results:
2023-06-14 12:54:59mail_info: from:smtp.office365.com user:alert@notify.fortinet.com 2023-06-14 12:54:59mail_info: reverse path:alert@notify.fortinet.com user name:alert 2023-06-14 12:54:59 to[0]:aljor@fortinet.com 2023-06-14 12:54:59 <==_init_mail_info 2023-06-14 12:54:59 create session 2023-06-14 12:54:59 resolve smtp.office365.com to 1 IP 2023-06-14 12:54:59 ==> send mail 2023-06-14 12:54:59 connecting to 52.98.33.130 port 587 2023-06-14 12:54:59 send mail 0xa1803b0 session 0xa1863f0 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: greeting, code: 220 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: ehlo, code: 250 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: starttls, code: 220 2023-06-14 12:54:59 rsp_starttls: creating ssl structure for session 0xa1863f0 2023-06-14 12:54:59 create_ssl: 0x7f772be000 2023-06-14 12:54:59 sessionn 0xa1863f0, SSL connected 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: ehlo, code: 250 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: auth, code: 334 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: auth2, code: 235 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: mail, code: 250 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: rcpt, code: 250 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: data, code: 354 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: data2, code: 250 2023-06-14 12:54:59 session: 0xa1863f0, rsp_state: quit, code: 221 2023-06-14 12:54:59 session finined 2023-06-14 12:54:59 _session_on_destroy 2023-06-14 12:54:59 <== send mail success, m = 0xa1803b0 s = 0xa1863f0
This same behavior is seen in v7.4.4, but for v7.4.4 even having the ‘reply-to’ and ‘username’ addresses for same username, it fails. 2024-07-30 09:41:43 mail_info: 2024-07-30 09:41:44 buffer is full
This server is only available for devices registered with an active FortiCare support contract. Also, the reply-to field in the source email is now automatically updated to DoNotReply@fortinet-notifications.com for all servers, including custom ones.
Related document: Default email server available to registered devices with FortiCare
|
