One thing we wanted to do on payments was ensure that emails we sent out to users were consistent with FxA emails. So we copied the theme to try and keep them consistent. This wasn’t great because we had to keep the forked code up to date.
But I’ve been thinking about email on AMO and realizing that we are going to have similar problems not just with the emails, but also the infrastructure of sending emails. For example on AMO we have a specific set of templates for sending emails at various events in the add-on lifecycle. They then go through socket labs, we’ve currently got two block lists, one on AMO, one at socket labs. I realized that one of the reasons I’m looking forward to using FxA for login is that I don’t have to worry about the account email infrastructure any more, FxA is going to do that for me. So I was thinking through an idea, where would it make sense for the FxA mailer to grow the ability to send an arbitrary email from an app using FxA for authentication. In our case it would be something like: * user has logged into AMO using FxA * user uploads an add-on * her add-on is reviewed successfully, triggering an email * AMO server does some sort of token exchange * AMO calls an end point for the user, containing an email (or maybe just some data that populates a template) * FxA responds, we log it and move on At this point AMO doesn’t even need to know a users real email and maintain that (for when email address changing lands), FxA maintains all that. Maintaining the spam list and ensuring delivery is moved to a team that has to look after that anyway… I’m not sure if this is a good idea or not, just thinking through ideas. _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
