Yeah optional is good for me! On Fri, Sep 13, 2019, 6:21 PM ocket 8888 <[email protected]> wrote:
> That's actually a good point - even the Perl implementation just shells out > to an external program; and that program isn't required by the TO specfile. > So it's already possible that the server isn't configured to handle such > things, you just get an uglier error. > > Are you good with this given what's been said, Eric? > > On Fri, Sep 13, 2019 at 12:50 PM Rawlin Peters <[email protected]> > wrote: > > > In general it seems that having an SMTP server available is optional > > already and should remain optional. If an endpoint depends on an > > optional configuration, the endpoint should return an appropriate > > error if it will not work without SMTP configured. This would be > > similar to how configuring Riak (Traffic Vault) is optional and how > > endpoints that require Riak should return a 503 if Riak is not > > enabled. > > > > - Rawlin > > > > 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? > > > > > > >
