Just to be clear, there are 2 ways to register/create a new user: 1. "register" a new user via the `POST /api/users/register` where you simply supply the email/role of the new user and an email is sent to the provided email address with a link. By following this link, the new user can define the remaining attributes (i.e. username/password)
2. create a new user via the `POST /api/users` endpoint where YOU define all the fields for the new user yourself. No email is sent. #1 will not work without an email server. jeremy On Fri, Sep 13, 2019 at 10:44 AM Eric Friedrich <[email protected]> wrote: > Yes, I think SMTP is an unreasonable requirement for user registration- it > should be optional. If I wanted to spin up a small CIAB, I would prefer not > to have to supply my ISPs email server. > > This also does not account for environments where TO may be deployed that > do not have Internet access or are segmented from email servers for > security reasons. > > Finally, it would be great if the implementation can include support for > both SMTP over TLS and username/password authentication out of the box. > > --Eric > > On Fri, Sep 13, 2019 at 12:10 PM ocket 8888 <[email protected]> wrote: > > > With the introduction of letsencrypt in PR #3534 (WIP atm) a > configuration > > option will be added to TO to specify the connection options for an SMTP > > server for sending emails. > > > > I'm currently in the process of re-writing /deliveryservices/request, > which > > sends an email as its primary functionality. AFAIK, there are two other > > endpoints that do this, /users/register and /user/reset_password. The > > current Perl implementation `exec`s `sendmail` to send emails without an > > SMTP server. There isn't really a Go library (that I could find) that can > > just directly send emails without an SMTP server to which to connect. > > General sentiment is that this is what should be done, it seems, but it > > means making the operation of endpoints that "just work" with a given > > configuration in Perl return an error without amending said > configuration. > > > > Personally, I think that's an improvement, and a few others I've spoken > > with agree. It would also line up nicely with the configuration in the > > upcoming letsencrypt functionality. > > > > tl;dr: Does anybody have a problem with requiring an external SMTP server > > for the /deliveryservices/request, /users/register and > /user/reset_password > > endpoints? > > >
