I have configured an e-mail account but when I save it, I received a message that it could not be logged in.
By seeing the ERPNext logs, this is stored:
TypeError: ValidationError(SMTPAuthenticationError(535, ‘Incorrect authentication data’),) is not JSON serializable
Account and server are correctly configured. In fact, I can enter using Webmail and using Telnet test.
I have even used this service to e-mail test:
Free advanced online tool to Test and check your SMTP server. SMTPer provides you a full interface to test and check your Mail server on the fly. Specify the SMTP host and the port, you can eventually use a Secured Connection (ssl, tsl ..) and...
This was the test e-mail that was received:
This mail was directly sent by mail.example.com.
SMTP host: mail.example.com
Use SLL: True
Use Authentication: True
Authentication name: email@example.com
Authentication password: [not applicable] Email from: firstname.lastname@example.org Email to: email@example.com
Please don’t care about the domain dames. Are just examples to hide real domain names.
If you try the same configuration in a client like outlook, everything is working?
Authentication password: [not applicable] Email from: firstname.lastname@example.org Email to:
Your SMTP server doesn’t require any authentication?
Yes… SMTP and IMAP work in Outlook, in Webmail, in the page to test SMTP connections… everywhere but in ERPNext.
When I use this configuration in E-mail domain administration:
And then press Saved, server taks too long and then it responds with the message: outgoing e-mail is not correct.
when I use 587 port, and then press Save button, server immediately responds with a message telling that “Soporte” e-mail account has bad authentication information.
First strange thing, 465 port is perfectly valid. Well… I could save the domain before creating “Soporte account” using port 587, so I think the problem is with "Soporte"account.
This is how it is configured:
I have told you that password works, since I can connect to the account from everywhere.
It seems I have found a bug.
When password has some non alphabetical characters, that error is produced. I have changed account password to contain only letters and numbers and it was saved correctly.
However, I have loaded inbox for the account and no e-mails are displayed, even when there are some e-mails.
I have made a test by sending an e-mail and it works.
Any further help, please?
I using also special character and I have no problems.
Sometime, but should not happen, when you use ’ or " or ` or \ you can encounter problems.
I suggest to open an issue on ERPNext on GitHub about this issue and should be listed the steps to replicate this problem.
About inbox, you should thick allow incoming emails, and be sure that all the clients (including outside ERPNext) working in IMAP.
If you have just a single POP3 configured for “soporte”, it’s probable that you can’t sync “soporte” with other clients because POP downloads the messages removing them from the incoming email server
Glad you solved the problem.
I would be careful using online tools to test your SMTP, especially when your account requires authentication (actually even more so when it doesn’t).
Rather test using telnet from your local machine, or your server command line.
Just do an internet search for “telnet smtp test” or something similar. There are many, many references on the topic.
I have tested with IMAP and POP3 and none worked. Mails are not removed from server, and in fact, I can check e-mails from Outlook and Webmail and e-mails are always there.
The problem here is that I cannot debug this further. No logs are saved neither debug information that allow me to trace e-mail reception.
By using a POP3 tool, this was the result:
S:+OK Dovecot ready.
S:SASL PLAIN LOGIN
C: USER email@example.com
C: PASS xxxxx
S:+OK Logged in.
S:+OK Logging out.
POP3 test completed successfully.
By using other tool, it shows the 3 e-mails that actualy exist in the mailbox. So, the problem is not the server, but something wrong with ERPNext.
Those tools internally open a Telnet session to the server, so it is equivalent to do it manually.