Add help text to "Username" field for Outbound email configuration

[neynah]

During testing I saw multiple users enter in invalid inputs for the "Username" field. Perhaps we can add some help text and/or provide an example.

[paulproteus]

Out of curiosity, what were the inputs people gave, and what made them invalid inputs?

For what it's worth, some email servers (like gandi.net's SMTP service) use e.g. asheesh@openhatch.org as a valid username input. So I imagine that we would have some difficulty defining the set of valid inputs.

[neynah]

So for testing I provided the email address, the SMTP host, the port and the password. The email was always admin@test#.nenanguyen.ca

Usernames I saw entered: "admin" "nenanguyen5"

Perhaps we should force users to test email delivery as @zarvox has mentioned and provide better error messages.

[paulproteus]

Out of curiosity, what was the valid username?

[neynah]

"admin@test#.nenanguyen.ca"

[zarvox]

It's up to the mail relay to decide if they want bare usernames ("admin") or full addresses ("admin@test4.nenanguyen.ca") for login, and we can't know a priori which is right or wrong, so I don't think there's any better text to provide here.

I believe we should fix this by:

1. providing clearer/more-aligned-with-our-labels instructions to user testers, if we think that's still representative of the task?
2. making sending a test email (and proving you received it) mandatory before changing email settings
3. providing good explanations for email-sending errors when we detect them in this test flow

[neynah]

1. providing clearer/more-aligned-with-our-labels instructions to user testers, if we think that's still representative of the task?

Yes, I think this will help our testers & is something I will do. Unfortunately, in the wild we can't control how others communicate this information.

I'm +1 on 3 and mostly +1 on 2 although I'm concerned that "proving you received" the email would add delay to the installation process. It can take up to a few minutes for the user to receive an email. If we block them from configuring other pieces while they are waiting for the test email then users may get bored/distracted/tired of waiting. Maybe we can still do something reasonable.

[ocdtrekkie]

A device that I was recently configuring email with had a Test button as the first listed/highlighted choice to entering your email data. It actually would show a popup that tested the SMTP connection and reported if it was successfully able to send an email with it. (So you didn't have to wait for one to appear in your inbox.)

Furthermore, rather than "requiring" you to test your email successfully, if your test failed, you could still just press save, but it would ask you if you were sure, because it had not successfully tested those credentials to work.

[kentonv]

In order to implement a test without making the user check their inbox, we could send the message to a Sandstorm.io-controlled server and then use some API to ask it if the message was received. This would only work if the user's Sandstorm instance can reach the internet, of course.

If this "phoning home" to a Sandstorm.io-controlled server is OK, then we could also check if the host has direct SMTP connectivity and is not on any spam block lists, in which case we can perhaps have the server act as its own MTA with no configuration needed.

[zarvox]

Just because the email relay said it delivered your email doesn't mean it will actually arrive - spam filters and other relays could fail to deliver it, or you could have mistyped the address. If your emails are getting sent, but spam-filtered out, your users are just as likely to be unhappy, but will have less information to debug than the admin setting things up. The end-to-end principle applies here.

Also keep in mind that configuring email as a whole remains an optional part of the setup flow (though I am also open to revisiting that decision, should we provide an easier way for people to get up and running with mailgun or sendgrid or something). I just want to make sure that when users think they've successfully configured email, they're right about it, because our user testing suggests otherwise. :)

Lastly, if the next thing the user is going to do is wait for a login email to arrive (which may or may not ever come), I'm hardly convinced that we're saving the user any trouble.