Unable to send Admin Invite on new install

I have been trying to setup onCourse, and am having problem with admin email invite.

It keeps on giving message An invitation to user John Doe someaccount@somedomainname.com wasn't sent. Check you SMTP settings.

I’ve tried with v73 to 77, problem persists.

my smtp settings in onCourse.yml is as follows (I’ve also tried with tls and unsafe):

  email_batch: 10000
  host: somedomainname.com
  port: 587
  mode: starttls
  username: someaccount@somedomainname.com
  password: somesecurepassword

The mail server is working. Setup for other systems using same mail settings worked.

Thanks for your question. I’ll get our QA team to review this today.

When you tried with unsafe did you use port 25? We can’t make this problem happen on our systems. I wonder if your mail server has a certificate issue. It will not work with a self-signed certificate.

You might also like to set your logging to DEBUG and see if you can get more information about the problem.

How do I set logging to DEBUG?

Would it be better to have a default admin login for a fresh install? Or a way to create an admin account without invitation? Even better, able to create user accounts without email?

You can alter the logging settings by editing the file logSetup.xml which will be created when the server runs. Change both “WARN” to “DEBUG”. You might want to put it back before it fills up your disk.

As for the creation mechanism, this approach is needed to comply with modern best practices. Users (even the admin) should never know the password of other users.

Note that the latest java 11 (11.0.11) removes TLS 1.2 and 1.1 from the allowed protocols. That means your mail server needs to support 1.3 or else you need to set it to unsafe mode on port 25.

I have made some progress in troubleshooting it. The debug doesn’t help, though.
The following is the finding from log of mail server (I use iRedMail).

with mode: starttls and port: 587, I get error as follows:

May 12 02:55:53 mail postfix/submission/smtpd[410026]: connect from oncourse.test[]
May 12 02:55:53 mail postfix/submission/smtpd[410026]: SSL_accept error from oncourse.test[]: lost connection
May 12 02:55:53 mail postfix/submission/smtpd[410026]: lost connection after STARTTLS from oncourse.test[]
May 12 02:55:53 mail postfix/submission/smtpd[410026]: disconnect from oncourse.test[] ehlo=1 starttls=0/1 commands=1/2

with mode: unsafe and port:25, I had to disable a number of security checks to make it work. I later found that onCourse code sends email invite using noreply@hostname. This failed the HELO restriction, smtpd_sender_restrictions, and smtpd_end_of_data_restrictions. I had to disable reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_non_fqdn_sender to make it work.

The email invitation has https://testcopy.cloud.oncourse.cc/ (I assume testcopy is the college key or maybe hostname?) This of course is invalid for local setup.

Would be great if the SMTP sender name and email invite url can be specified in the onCourse.yml or somewhere for the initial admin invite.

Ps. How do we enable LDAP function? It says This feature is not enabled, please contact ish to enable it.

Are you seeing literally noreply@hostname or is the hostname the real hostname of the server? It should be the real hostname, which hopefully you can allow mail for.

The server URL should certainly be a configurable option since it cannot be autodetected behind a load balancer. We’ll add that. In the meantime, you could manually get around the problem by changing the hostname in the email invite. The rest of the URL will still be valid.

As for LDAP, that’s a part of our current hosted licensing model, but we are working to get rid of those restrictions now that it is open source. I’ll try and get that into the next release.

Not literally, it’s the real hostname of the server.

But this goes against best practice. Email being delivered needs to have the sender email address matching the account used to authenticate. Otherwise, this opens to a risk where someone sending an email that appears to come from someone else. Whitelisting a whole host/IP will open a much bigger risk that could result in uncontrolled email delivery. It could turn into a spam machine.

Could you allow more options, instead of hardcoding it? In the config file, you allow account to login, port, mail server, etc. Could you add sender address and (optionally) sender name?

Yes, did that. That’s how I managed to login. Worst case, I would just add CNAME in DNS for it.

I’m not following. The problem isn’t that your server is untrusted by your mail relay (since you have a trusted IP or you are using authenticated SMTP). The problem is that noreply@server.acme.com is not being relayed because it is an unknown address or hostname. In many MTAs you can rewrite those addresses like this.

Once you log in you’ll find that you can set a from address and name in the preferences. So the question is whether we want to move this setting to onCourse.yml. The advantage is that it will be applied for the initial server setup (which would help you), but then it is harder to change for a sysadmin with no access to the server configuration.

Its nice for from address to be a runtime configuration, but it also means people can change it to something invalid and break email.