Set "from" and "reply to" addresses in emails

[czlee]

The "from" address in emails is arbitrary, so we should probably set it to something sensible. The obvious problem is that there's no obvious universal address that we could use, because Tabbycat doesn't have a domain name (and isn't going to get one just for this purpose). Here are some options, some terrible, some passable, not necessarily mutually exclusive:

1. Set it to settings.DEFAULT_FROM_EMAIL, i.e., the status quo.
   • We actually set what this is. At the moment, it's set to app123456@heroku.com, because in our code we set it to whatever SENDGRID_USERNAME is. But if the SENDGRID_USERNAME is an actual SendGrid username of the tab director's personal SendGrid username, this doesn't make much sense, because it'll always be apikey.
2. Set it to settings.TAB_DIRECTOR_EMAIL.
   • Given that we don't tell them this is what it's for, this is probably a bad idea.
3. Insist that users specify an email address on account creation, and use that email address.
   • This is a less bad idea, but I still feel like this should be decoupled from the email addresses of actual people.
4. Make it a setting, configured under "Configuration > Email Settings".
   • This would work, but would be difficult to discover.
5. Make it noreply@<domain-name>, e.g. noreply@gentle-citadel-45380.herokuapp.com.
6. Add a field to customisable email forms that specify this.
   • This could be used in combination with any of the above, and should be, in the sense that whatever of the above is used should just be the default for this field.

Question: Should we try to set a norm about what this should be? For example, would it be a good thing or a bad thing to suggest that this be a real email address, so that participants can reply if they have some problem with it?

[tienne-B]

As these messages really are noreply-type messages, point 5 would be the most appropriate in my mind. As an extension, the name we give (i.e. Étienne Beaulé <noreply@tabbycat>) could be customizable through a preference, or it could just be the (short) name of the tournament.

[philipbelesky]

I wonder if the choice of from address affects spam capture? I'd be fine with 1 or 5, but think its critical that the from name is something easily recognisable as debating related. So using the tournament short name seems like a sensible default.

If this is becoming fully preferenced-ised it would also be possible to specify a reply-to address different to the sender.

[czlee]

Ah, the reply-to address is a much better idea than trying to encourage it to be a real email address. (5), then?

In some use cases there'll be a tournament email address that could be (customisably) used, but this probably doesn't apply to most cases.

[philipbelesky]

Sure (5) sounds good!

[czlee]

Okay, so how about this:

• [ ] Change from address to noreply@<domain name>, with suitable fallbacks as necessary
• [ ] Somehow make the "from" address present (as text, not a field) in email forms, just so the user's aware
• [ ] Add reply-to setting, default to nothing, I'm fine with this being the same for all emails but lmk if you disagree
• [ ] Add a line to email forms saying what the reply-to address is (if it's set) or reminding the user that they can set one (if not)

I think it might be sensible to abstract @tienne-B's work on the email form to a suitable framework before working on this, since we've got emails for a few things now and I think this is more likely to go up than down.

[philipbelesky]

Yup, that sounds good. We could I guess set the reply-to address to be the email the first admin user signed up with perhaps. But if the form makes it clear that one needs to be set that's maybe not an issue (but potentially may be an issue if people can send emails without ever seeing the form).

[czlee]

The email that adjudicators get sent when their ballots are confirmed is sent without the user seeing the form, if that counts?

[philipbelesky]

Yea in that case I'd either be in favour of having the reply-to preference set alongside the initial admin user and/or a relatively obvious alert when the reply to is blank on a confirm-sending-email page (if there is one). I could definitely see scenarios where users reply to an email raising an issue not realising it's going nowhere.

[tienne-B]

Started on this with #679, which gives all the messages the set From address but with the tournament name, and a reply-to which is in the settings. As it is based on the tournament, the reply-to should not necessarily be of the first admin. Maybe in the Tournament Creation form though?

If we do use noreply, I guess we would only have to change DEFAULT_FROM_EMAIL, and that would make the 2nd point moot.

[tienne-B]

The reply-to field in the preferences is quite insistant, and won't allow email options to be changed without adding a name and address if that counts. As for private URL emails, there could be a warning that shows up, but I wouldn't be sure for the standings message as that function is secondary.

[philipbelesky]

Sorry, there could be a warning that shows up when what happens? When there is no default from email? Also what are the steps needed to close this issue as-is?

[tienne-B]

Yes. As it is now, we use (1) but with an option to set a reply-to address. That was the main focus. What this task also covers are warnings and notices for tab-people to know what is their "from address" and whether a "reply-to" is set. I think adding a sort of notice for both these items on the private URLs email page would be sufficient, but it could be a different task as its different to the main (fixed) focus here.

[philipbelesky]

Closed in cc00fde

[czlee]

Hmm, so we still use DEFAULT_FROM_EMAIL, which is still set to whatever SENDGRID_USERNAME is, which when using a SendGrid API key is apikey. Which looks a bit weird, because it's not an email address. Is that what we wanted? Any objections to changing it to noreply@<domain-name>?

[czlee]

I suppose this would require a bit of refactoring to pass the HttpRequest object into TournamentEmailMessage. For this weekend I'm just gonna have it check another environment variable as a workaround (see b4226dd6b), but we should probably get to a less hack-ish solution at some point.

[tienne-B]

Why would we have to pass HttpRequest? Anyways, we should test to see whether changing the email would cause problems (like with DKIM) or to specify a from.email rather than the default of the key.

[czlee]

Hmm, DKIM is a good point. I think it should be fine because it should be signed by SendGrid, but we should check. Gmail didn't complain in my initial tests, though.

We'd have to pass in HttpRequest in order to get the host name, since (as far as I'm aware) the only (or easiest?) way to get the host name is HttpRequest.get_host(). But definitely open to alternatives!

[tienne-B]

Would it be possible to set DEFAULT_FROM_EMAIL based on SENDGRID_USERNAME to prevent having to pass another object? I do think noreply is a misnomer in this case as we do encourage people to reply to the messages, just not to that specific email address (writeonly@<domain> is not common). Using noreply would not set off any alarms though as it is the same (authorized) domain.

[czlee]

Well, to be honest, from my perspective as a tab director I sort of don't want people to reply to the messages—I don't check my email for time-critical messages during the tournament 😝. But that aside, I'm not entirely sure what you meant. If you wanted to set something@<domain>, I think you can't do that at initialization, because I think the server doesn't actually know its own domain name until a request from a client comes in, which is why you have to derive the domain name from a request (I'm happy to be corrected on this).

[tienne-B]

I'm not going to work on this; the reply-to header is as a preference. The tournament's name is the From name. The discussion on setting a From address is moot on Calico where the site's name is the username of the @calicotab.com domain, and SendGrid would probably be more restricted in what can be done, especially in-software (and there are bigger problems with SendGrid).