You can already use an extension to override the behavior of any endpoint - so if you don't want to send email and would rather send a Kafka message (?) you can absolutely do that.
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? > > > > > > > > > > > > > > > >
