Talking about SMTP servers. It would be nice to be able to use a REST service instead of SMTP servers.
Eric mentionned a few reasons. HTTP based services can be used with proxies which is much easier. I understand everybody got their favorite alarming/transport system. Maybe something more generic could be used. I guess some options could be: - Write to a file (picked up by your favorite application) - Kafka - Slack I'm assuming those could all be plugins which we can provide hooks for different purpose. Steve On Fri, Sep 13, 2019 at 6:38 PM Eric Friedrich <[email protected]> wrote: > 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? > > > > > > > > > > >
