Steve, you bring up a good point. This is probably a much bigger conversation, but it does seem like "notifications" (currently just email via SMTP) should be a configurable backend -- e.g. email/SMTP, slack, file, or kafka like you said. I think we could throw notifications behind an interface and have whatever concrete implementations of the notification service that we want; each implementation would basically be a plugin with its own unique config file. I'm not sure how much granularity we want there, i.e. would we want emails for user registrations, slack for Let's Encrypt cert expirations, and kafka for whatever else? Or we could just provide a "service" configuration which would make an HTTP request to some external service's URL, then the external service is free to do whatever it wants with the notification data. I imagine authentication credentials would have to be factored in somehow.
It would be nice to provide that functionality within TO without having to fully overwrite endpoints via custom TO extensions/plugins. - Rawlin On Sat, Sep 14, 2019 at 11:25 AM Steve Malenfant <[email protected]> wrote: > > 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? > > > > > > > > > > > > > > >
