|
in reply to Re^2: MTA for Perl
in thread MTA for Perl
Adding a bit to that, the real question is how you want the mail to flow. An MTA like Postfix will manage its own queue, so your program writes out a mail message and gets "success" that it has been delivered to Postfix. If Postfix has a problem delivering it, you'll need separate monitoring to find out about that, and meanwhile the messages will pile up in the queue on the raspberry Pi. The other way is to deliver mail directly from your app to some external SMTP host, like a relay service from your internet provider, or SendGrid, or something like that. If you can't push the message to them, the error can be handled and reported in the application. This also saves you the hassle of setting up an MTA, which is nice, unless your whole goal was to learn about MTAs. |
Re^4: MTA for Perl
by Corion (Patriarch) on Mar 21, 2024 at 07:58 UTC
|
I think you need some secondary part monitoring the send status, bounces etc. anyway, at least if you are serious about sending mail and not having it marked as spam. Sisimai does the analysis (I have not used it). But you have to go beyond "mail was handed off to MTA" anyway.
| [reply] |
Re^4: MTA for Perl
by afoken (Chancellor) on Mar 21, 2024 at 10:12 UTC
|
An MTA like Postfix will manage its own queue, so your program writes out a mail message and gets "success" that it has been delivered to Postfix.
Nullmailer does exactly that, and ONLY that. The really great part about nullmailer is that it needs very little configuration compared to huge packages like postfix or exim, and it is harder to get the configuration wrong. The Debian wiki explains the configuration quite well, and so does the Arch-Linux wiki.
If Postfix has a problem delivering it, you'll need separate monitoring to find out about that, and meanwhile the messages will pile up in the queue on the raspberry Pi.
I usually have some cron jobs running on all machines, at least some kind of backup, a disk full check, or SMART and RAID integrity checks. So I get one cron-job mail per day per machine. If I don't get that mail, something is wrong. No extra monitoring needed.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
|
| [reply] |
|
|
Is there an advantage of Nullmailer vs. Email::Sender::Transport::SMTP::Persistent ?
One very obvious: nullmailer works for the entire system, not just for perl scripts that happen to use E::S::T::S::P. So you will also get mails from cron when cron jobs aren't silent, smartd will complain about failing disks, mdadm will complain about failing RAIDs, sudo will complain about people trying to get root privileges, and so on. And of course, any application or user can simply invoke sendmail to send a mail.
The other one is that you don't need to keep an SMTP connection open. E::S::T::S::P blocks server resources, which is not friendly. (You will probably don't mind if it is your local, bored server.)
The last few times I manually fiddled with a telnet client connected to SMTP servers, they simply closed the connection after a a few seconds of idle time. Keeping an open SMTP connection is very typical for humans, but very untypical for SMTP clients. So the servers just kick you out. And I would guess the same happens with E::S::T::S::P. Probably nobody notices, as it seems to silently reconnect if needed. I don't know, I don't use Email::Sender, but if I would want to know, I would add some print statements to E::S::T::S::P::_smtp_client().
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |
Re^4: MTA for Perl
by Bod (Parson) on Mar 21, 2024 at 12:45 UTC
|
unless your whole goal was to learn about MTAs
That is a big part of it...it's the reason I'm not just pushing them out to SendGrid or Brevo which we already use.
| [reply] |
|
|
