I’ve recently taken over managing some systems from a former colleague. I’ve now gotten to the Nextcloud instance.
Got it mostly straightened out, but there seems to be a general problem with sending E-Mail through Nextcloud.
It’s SMTP port 25
sender is email@example.com
server is webmail.domain.com
All I get is “A problem occurred while sending the email. Please revise your settings.”
The Cloud is on the same local subnet as the Exchange-Server used to send mails. The Exchange is set up with an anonymous relay connector for the nextcloud, in order to reduce the failure points for troubleshooting, so sending mail through it should be as straightforward as it gets, it’s a simple SMTP 25 connection without any need for authentication.
If I telnet from the nextcloud-server, using the exact same settings, the mails go through without a hitch. Meaning DNS resolution is fine, and the Exchange accepts and relays mails from the host.
So something seems to be different with Nextcloud’s mailing system. I’m generally at home in the Windows Server world, so I don’t really know where to start.
I can provide any additional info that’s needed.
Yep i’m in the same boat as well. I have to pay to use an smtp provider when I have my very own!!!
What the hell nextcloud. My Exchange 2019 enterprise server works perfectly for all of my send-mailmessage script, all my blat scripts, all these cheap POE CCTV cameras but NOOOOOOOOOOOOO internal nextcloud ohhh sorry A problem occurred while sending the email. Please revise your settings. (Error: Email could not be sent. Check your mail server log).
What’s funny is I can send unauthenticated emails from my Ubuntu server that Nextcloud is hosted on, I can telnet to my exchange server using 25, 465, 2525 and 587 they all connect, I can ping my exchange server, I can ping the mx record.
Lots of digging through issues on the GitHub later…adding this to the config solved my issue:
‘mail_smtpstreamoptions’ => array(
‘ssl’ => array(
‘allow_self_signed’ => true,
‘verify_peer’ => false,
‘verify_peer_name’ => false
Apparently the new symfony mailer cannot handle it otherwise. Settings in the GUI seem to not have the desired effect (like selecting unencrypted…after which it should not matter what SSL weirdness symfony does)
Maybe that ought to be…y’know…in the documentation? Or maybe the functions should reflect the settings in the GUI. Or just get rid of the mailing GUI if it has to be handled in the config either way.