Office 365 mail

the problem is we the mail headers since you require everything to be sent out under one account the mail headers cause problems with office365 even with a connector and with send as permission. can we get some help from ERPNext to resolve this?

Content-Type: multipart/mixed; boundary=“===============8521156360519372265==”
MIME-Version: 1.0
X-Original-From: Billing Office
From: Billing Office
Date: Tue, 04 Oct 2016 23:25:04 -0000
Subject: Issue: ISS-00027

i spent about an hour with Microsoft and they confirmed that the authentication error is not being generated by them is there some sort of local authentication going on in ERPNext for the default sending account that would generate this error?

(535, ‘5.7.3 Authentication unsuccessful’)

do the default email accounts need any user permissions or roles in ERPNext i can not seem to find it documented as a requirement it was suggested by the MSFT engineer that this error was localized to ERPNext?
(535, ‘5.7.3 Authentication unsuccessful’)

My Office365 works perfectly currently. Here’s what I did aside from the settings woakes070048 provided in his picture.

Created an email address ( gave it an exchange 1 license with Office. Waited 4 hours to be sure it was all good on Msft end. Created a user in ERPNext named inbox with that email, no roles or permissions.

Authenticated fine at that point.

Things that gave me issues: creating a “shared mailbox” in Office365 would not Authenticate. Having no license on the email in Office365 would not authenticate. Having no user in ERPNext with that email would not authenticate.

1 Like

This just doesn’t work no matter what i try…

i know now it is related to how the system only uses one account and how the python is written and formatted in particular the mail envelope but i have no idea how to fix as i do not code.

In exchange i enabled a connector based on ip so no authentication is should be needed and test from the erp machine using postix and telnet work just fine to office365.

i have given full mailbox access to default send account and all other accounts i use within erpnext
i have used
Server name:
Port: 993
Encryption method: SSL
Server name:
Port: 587
Encryption method: TLS
added users to correspond with sender account in ERPNext

I have engaged MSFT PSS and they are in agreement it lies with ERPNext via remote session…

i have been working with exchange for decades and office365 for years so i know the product very well and have numerous setups with office365 as a relay no problem what so ever…

yet with ERPNext i get (535, ‘5.7.3 Authentication unsuccessful’)
or invalid password

No matter how i configure ERPNext seems that mails either don’t send from all email accounts or are unreliable.

It totally beyond me how a product that at its base relies on email for communication such as invoicing and helpdesk has not focused more attention to this deficiency over the last 20 days since i raised the topic…

this product is useless if mail doesn’t work…

If i have missed something it would be great as i have a product integration that i would like my team to work on but can not justify moving forward if email does not function.

1 Like

Yep, everyone knows the product is useless for most people if email doesn’t work. The problem is that email IS working for most people it seems. There’s not much that the Frappe team or anyone else can do if no one can replicate your issue. All we can do is continually throw settings at you to try. Maybe you can send some screenshots of your setup?

I’m attaching screen shots of my setup for better or worse. It IS working and has been for a while. Woakes apparently has no problem setting up clients as well.

I noticed that Woakes has used for both his outgoing smtp and incoming (presumably imap) setting. I confirmed that this also works on my setup. I normally use for outgoing.

As I mentioned already, the email setup in Office365 is NOT a shared mailbox, it is a regular user. Also a long shot, but have you signed in to Office365 with the email address yet? If the system is waiting for the first sign in to ask the user to change their password then ERPNext can’t authenticate the temporary password. Also Multi-factor authentication won’t work obviously.

You should open an issue on Github for allowing multiple outgoing emails.

That would be a great addition to the software, but nothing will happen without a Github issue.

As i stated above its how ERPNext mail app works not the configuration of office 365 i have verified all of the various settings that were suggested and tested them with an MSFT Engineer.

In order for this app to logically work this must occur:

1 a user sends email to This Works
2 ERPNext polls mailbox and ticket is created This Works
3 whom ever is responsible to answer support ticket views ticket responds and save ticket This Works
4 response queued ticket sent This Does Not Work

Content-Type: multipart/mixed; boundary=“===============4205493180708883961==”
MIME-Version: 1.0
X-Original-From: Company Communications
From:Comapany Communications
Date: Thu, 06 Oct 2016 12:26:27 -0000
Subject: Re: 100616819
(535, ‘5.7.3 Authentication unsuccessful’)

it is because of some role or permission within ERPNext.

All mail accounts are actual mailboxes and are licensed office365 and logged into further i have gone one step further and created an ip based connector in office365 so all authentication is unnecessary and it still does not work…
It is somehow related to what ERPNext is doing with accounts at time of mail creation because as i said before i can telnet from this machine and send mail just fine and i do get the two default emails just fine from Backup Upload Successful and Daily Digest daily. it is only when i am trying to send mail from within the app as product of responding to tickets and communication so far that does not work

this is what doesn’t make sense i set the account up in email accounts i click save the account validates and turns blue. i go to email queue where the error mail exist and try a retry. no matter what account i logon as i get an ERPNext screen popup “message” invalid login or password which i know is not correct as the account validated and I’m not putting in any login information at this point so its happening on the backend… there has to be a permissions issue in ERPNext causing this yet this is a new default setup on site…

Ok I understand better where you’re having strange issues. Still can’t replicate though. I have no problem sending replies to messages that were pulled into the system from the default mail account.

I keep looking at your error messages and wondering how there’s a typo in the “reply to” domain name:[quote=“imllc, post:21, topic:15981”]
Content-Type: multipart/mixed; boundary=“===============8521156360519372265==”
MIME-Version: 1.0
X-Original-From: Billing Office
From: Billing Office
Date: Tue, 04 Oct 2016 23:25:04 -0000
Subject: Issue: ISS-00027

Maybe it’s nothing, but maybe that bad domain is cached in the system and it’s trying to authenticate against that for replies? You’ve only posted 2 error messages that show actual emails and both have that typo.

i just changed the domains in the copy and paste from the actual error for privacy reasons they are formatted correctly in the actual header…

are there somehow some roles and permissions that default account must have in ERPNext for it to be able to sendas?

could it be a document type permission for these response forms

alright I’m on to something here i went in and deleted the default sending email account from email accounts but not the same named user from the users accounts. i then created a new account called it remember i have an exchange connector based on ip so it doesn’t care about logon. now when i go into email queue and try to resend after logging in with the user of the same name as the old default email account a pop up says password not found and subsequently takes me back to the main page and logs out so obviously there’s a linkage between user and email account in ERPNext and how its logic handles email i am sure the developers are aware of this and can now provide the missing pieces as to why this is not working???

update it does this with any user i login in with

more interesting by the minute so i reset the site database and now every time i try to clear queue or send email it kicks me out and make me log back in obviously this is an ERPNext issue perhaps the approach should not be we cant duplicate but rather can you show me your environment and why our product fails so we can all work together to improve…

by the way i did a bench update today on this server…

ok so here seems to be the problem if for security you modify or change the default administrator account ie rename it messes everything up on the email side of things this should not be because of hippa and a variety of other laws in the us we need to do this with employee and customer data as a baseline… obviously from my experience this is a problem… this is erp software and it needs to be compliant my 20 + day journey trying to fix just email has uncovered a problem let me know where i can help…

reset data base with bench --site --force reinstall

fresh install what password is it looking for default sending account is blue



{‘retry’: 0, ‘log’: <function log at 0x3b14938>, ‘site’: u’’, ‘event’: u’all’, ‘method_name’: u’’, ‘method’: <function flush at 0x3bb3050>, ‘user’: u’Administrator’, ‘kwargs’: {}, ‘async’: True, ‘job_name’: u’’}
Traceback (most recent call last):
File “/home/frappe/frappe-bench/apps/frappe/frappe/utils/”, line 61, in execute_job
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/”, line 251, in flush
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/”, line 143, in check_email_limit
smtp_server = SMTPServer()
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/”, line 138, in init
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/”, line 141, in setup_email_account
self.email_account = get_outgoing_email_account(raise_exception_not_set=False, append_to=append_to)
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/”, line 62, in get_outgoing_email_account
email_account = get_default_outgoing_email_account(raise_exception_not_set=raise_exception_not_set)
File “/home/frappe/frappe-bench/apps/frappe/frappe/email/”, line 90, in get_default_outgoing_email_account
email_account.password = email_account.get_password()
File “/home/frappe/frappe-bench/apps/frappe/frappe/model/”, line 597, in get_password
return get_decrypted_password(self.doctype,, fieldname, raise_exception=raise_exception)
File “/home/frappe/frappe-bench/apps/frappe/frappe/utils/”, line 19, in get_decrypted_password
frappe.throw(_(‘Password not found’), frappe.AuthenticationError)
File “/home/frappe/frappe-bench/apps/frappe/frappe/”, line 299, in throw
msgprint(msg, raise_exception=exc, title=title, indicator=‘red’)
File “/home/frappe/frappe-bench/apps/frappe/frappe/”, line 292, in msgprint
File “/home/frappe/frappe-bench/apps/frappe/frappe/”, line 265, in _raise_exception
raise raise_exception, encode(msg)
AuthenticationError: Password not found

ok here’s the problem we need to remove the need for a password that is checked against the ERPNext database when email is sent so that an anonymous relay validated vial ip/connector works with office365 this is 100% ERPNext issue all of my other third-party apps work great with office365 either as login or ip/connector relay.

that way it would work without:
AuthenticationError: Password not found

or if login is setup
(535, ‘5.7.3 Authentication unsuccessful’)

i have invested over a month on this product and have submitted a substantial amount of information documenting the problem as have numerous others what do we have to do to get some resolution on this?

As has been mentioned, you need to start a Github issue. All the development around Erpnext happens on github.

Compile the information you have gathered (which is very helpful) and make a clear request. For example “remove internal password validation from email requirements” is fairly clear. “Fix broken email” is not.

Finally, you code a solution yourself, wait for Frappe to consider the issue and have time to do something, create a “job” on the Frappe board and pay someone to make the changes, or sponsor the development with Frappe.

If you can’t make the necessary changes yourself, it boils down to being patient and thankful for a free product to get developed to work the way you want it to, or paying someone to do the development either specifically for you, or for the benefit of the whole community.