I’ve set up Email settings for our Office 365 account under System Admin > Email Setup, and also put our “From” address under the voicemail config for the server email field, as well as under Settings > Advanced Settings as the From: address everywhere it asks for one. However, I’m still getting an error in the logs showing that "[email protected]" isn’t authorized - but I’ve set up "[email protected]" everywhere (using an existing valid/licensed O365 box).
This isn’t just happening in the test screen, either - it’s when actual voicemail emails are trying to be sent (I saw a reference somewhere that this might only happen in the test screen).
Is there somewhere else I’m missing in the config that’s causing it to use asterisk@ instead of my config?
ETA: If I create/license the mailbox [email protected] and put it everywhere I had the other config, that works, so the connection itself seems fine. We just use the other mailbox for various alerts, and I’d rather not change it everywhere else (to something that would be confused), or license a separate mailbox just for this.
For reference so people don’t have to follow the chain, under the FreePBX bug report they verified that they’re writing the setting correctly where it needs to go, so suggested reporting it to Asterisk. I’ve done so here: https://issues.asterisk.org/jira/browse/ASTERISK-27199
Nope, closed as “not a bug” on both ends now, so I really have no clue what could be happening. I’ll just have to resign myself to using asterisk@ , since that’s the only thing that will work. Hope this at least saves anyone else the time of trying to look into it - if you’re having this issue, just go with asterisk@ and save yourself the headache.
To be clear Asterisk didn’t punt it back.
They said it is NOT an asterisk issue they simply use sendmail (or related system command)
We said this not a FreePBX issue because it has to do with your provider.
There is a misconfiguration (probably a security or spam setting) in o365 that is outside of our control.
Office 365 only accepts email from either the primary box or email addresses it’s authorized to “send as”… hence your problem.
I have several FreePBX clients using Office 365 (as 95% of my clients do) and I can confirm that it works. With Gmail/G Suite the system doesn’t care and will accept email from any address so long as it authenticates the mailbox.
For ISPs like 1and1 that will reject the message if the from user and the sending
user don’t match you can add these rules to /etc/postfix/generic replacing all
“[email protected]” with the real data used above for authentication.
I will add that this is not do-able in the commercial or free SysAdmin modules in the GUI, it must be done manually. But the above is your solution, I’m sure of it.
Yep, the above comment about needing postfix rewrite config in the smtp_generic_maps file fixed it - I updated the OP’s bug report as well. (Got good offline follow-up from Sean with Asterisk on the issue - thanks Sean!)
So it looks like the solution is out there, but it would probably help newer admins if it were easier to know that they have to do that, at a minimum. As someone who was setting this up for the first time, as far as I could tell, every setting I needed was there, but they just weren’t being listened to. I wonder if it would be possible in future to detect that this will arise - basically if they’re using O365 and/or other systems that require auth the same way - and either have the option for the system to generate the needed map, or at least maybe just flag it on the config screen as a manual step that will likely be needed? Could just be a link to that wiki page, with a short sentence like “you may need this config to make your serveremail address match your auth info”.
It seems like where the confusion of the issue’s root lies is this - it’s an issue that arises because O365 (and some other systems, it looks like, but a minority) have an additional requirement around how authentication works. In O365 that is not only the default config, but I don’t believe it’s actually changeable. But I don’t personally feel like it’s a “problem” with how O365 works - just an additional security requirement. I’m fine with having to do another step to set it up, but that’s where maybe a link on the SMTP page if O365 is selected might be helpful to people in future. Just helps link the pieces together.
Anyway, all good now, so thanks to those who have helped.
