Am 09/11/2023 um 13:34 schrieb Lukas Wagner: > On 11/9/23 13:16, Dietmar Maurer wrote: >>> On 11/8/23 16:52, Dietmar Maurer wrote: >>>>> This patch series adds support for a new notification endpoint type, >>>>> smtp. As the name suggests, this new endpoint allows PVE to talk >>>>> to SMTP server directly, without using the system's MTA (postfix). >>>> >>>> Isn't this totally unreliable? What if the server responds with a >>>> temporary error code? (An MTA retries several times). >>> >>> The notification system has no mechanism yet for queuing/retries, >>> so yes, at the moment a SMTP endpoint would indeed be less reliable than >>> a 'sendmail' endpoint. I'm not sure though if I would call it >>> 'totally unreliable'. >> >> This kind of notification system is quite popular for (PHP) web-sites contact >> form. I have seen many over-simplified implementation overs the years, >> and yes, it is totally unreliable. >> >> That is why we always used an MTA to deliver mails... > > I see. What would be your suggestion? To not have such a plugin at all? > I implemented this because it was explicitly mentioned by Thomas in the > tracking bugzilla issue for an overhauled notification system [1]. > Not having to configure Postfix if one wants to use an external > SMTP relay seems to be add quite a lot of value to the user (e.g. > judging from [2] and [3])
While Dietmar is definitively has a point, and making this more robust in the long run would be good, I see the (re-)queuing and the availability of the endpoints as a bit different things. And as you say, like currently the request to gotify needs to get through, the one to the SMTP serve does too. Also, user-facing SMTP servers are most of the time not doing any grey listing or rate limiting or the like, as the authentication itself is enough proof that a legitimate user wants to send a mail anyway, so once the MTA of the users' mail provider accepted it, they'll handle retries with the target MTAs. In the end one might indeed want to move the actual sending out to a daemon (it's own, or if we really want to avoid an extra daemon then one of the existing, frequently running, ones like pvescheduler or pvestatd) and the library calls just generating a queue-entry file in, e.g., the /var/spool/pve-notification directory. But adding that would not require any breaking change w.r.t. configs or the like, so while definitively good to have in the long run, it would not need to be necessarily done now. > As a compromise, maybe we could just add a note to the docs > that discusses the reliability aspects of 'sendmail' vs 'smtp' > endpoints? > Sure, for now adding a general hint to the documentation that they are send one-shot only would be good. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
