That does sound nice, but without a "default" implementation available I'm reluctant to adopt for rewrites right now. For now, I've opened a PR to add SMTP authentication and connection configuration to cdn.conf files: https://github.com/apache/trafficcontrol/pull/3925 . Hopefully this isn't digging ourselves into a hole if we want to go the "REST service route" later.
On Mon, Sep 16, 2019 at 11:35 AM Rawlin Peters <[email protected]> wrote: > 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? > > > > > > > > > > > > > > > > > > > >
