We are unable to send more than a couple of emails to automate issue assignments. A default sending email has been configured to receive emails and then append the subjects to the issue list. We have also configured and enabled a few assignment rules.
It works only for a few emails and then completely stops working for a day. Recently, there are also no error logs in the list for the failures. No failed to send logs in the email queue as well.
When we create the issues manually and add them it works well with the assignment rules. But our emails are not being sent to the assigned users.
Our default sending email is configured using Zoho Mail and the earlier errors we have seen in the log were related to “Relaying disallowed as user@example.com” for the email address that was used to send the email.
We are currently using Frappe Framework version-14 (v14.28.2) and ERPNext version-14 (v14.18.3).
On Email Queue … mails appears as “Sent”, or as “Error”?
Are your scheduled jobs working while mails are not been sending?
Are other emails got sending from ERPNext?
All emails appear as sent. It didn’t log the emails that were failed to be sent. For instance, I had sent two emails and later two more but none of them made it to the Issues. There is none in the error log list as well.
The scheduled jobs are supposed to work fine. No other emails other than these are being sent from ERPNext.
Previously, when emails were sent from a Gmail user whose account has not been added to the email list, we were able to see the “Relaying disallowed” logs in the error list and also emails that were not sent with the “Error” status in the email queue.
Should I split the default sending email into two separate emails accounts?
One email account will receive the emails and append them to the issue list. It will be enabled for automatic linking in documents. While the other email account should be labelled as the default sending email that will send alerts or notifications to the users assigned in the assignment rules.
I realised we didn’t set any email for our first “Administrator” user. It’s the default admin@example.com and we didn’t change it. We have created a few more users to log in and use the ERPNext as system users. Should I set the email for Administrator to the default sending email which we use for issues and notifications?
I could try to test with two separate emails and see how it goes. We also have a 14-day trial Frappe Helpdesk account to test it out with the following version.
Email Delivery Service: v0.0.1 (HEAD)
Frappe Framework: v15.0.0-dev (HEAD)
Helpdesk: v0.10.0 (HEAD)
I will try to test with a single email account on this and if it doesn’t work then update the Frappe/ERPNext on our development server to the latest version-14 patch and/or test it out with separate email accounts since it’s a relaying disallowed issue.
None of the users except for the Administrator and Guest have user@example.com but we have created a few more users with fake email accounts to test out the different modules.
No, we are hosted on AWS Cloud. Is that the reason why there is some restriction on the number of emails we can send and receive?
We do have a 14-day free trial Helpdesk account hosted in FrappeCloud which has Email Delivery Service installed as stated above.
This means that the system are trying to send mails in behalf of user@example.com , and this address is not allowed to sending from your mailserver … So, change it on administrator to the mail address you are using to sending mails … xxx@zoho.xxx
I have done this step and tested but it didn’t work. There is some issue with relaying that cannot be solved from ERPNext settings or the user interface. Zoho Mail setup looks fine and the error occurs when the email is sent from the sender to the assigned user which is unwanted.
We have set the default sending email to receive issues from a sender and then append them to the issue list. After it’s done it should assign that issue to a user and send him a notification email. But there is also an additional email that is sent from the sender directly to the assigned user which should not happen. We have also set up an automated reply to the sender from the default sending email when it receives an issue.
For some reason, it works only for a couple of emails (about two to three) and then stops altogether. It works again after a few hours in the day but that’s not guaranteed each time.