Re: How getmail deals with delivery errors and with bounce e-mails

On Thursday, November 5, 2020 6:42 AM, R. Diez <[email protected]> wrote:

> > Careful sysadmins have the logwatch package installed and either login
>
> > as root each day to read messages sent to root or, better, have set up
> > aliases so mail to root gets redirected to their own login.
>
> I suppose you are right. We have no other practical option left, given the state of the software tools we are using.

No, you're missing the point that is being explained to you. The common UNIX software practice is to have error messages sent to stderr and use a non-zero exit status to alert other programs of issues. When run from cron as is commonly done for getmail, each time getmail writes an error to stderr and/or exits with a non-zero status, crond will send the owner of the cron job an e-mail which contains the message getmail wrote to stderr. There is no need to rely upon grepping logs to be alerted to the errors, but once you do get a nasty-gram from cron, you would then likely go into the logs to investigate further. Read the man pages for crond, crontab and cron, its pretty well documented.

So your primary source of notification in the event of error is likely cron's normal behavior, logwatch et. al. can be used as a secondary means of alert, just depends on how many belts and suspenders you normally wear.

> Also, some tools pipe stdout to others, so if you are troubleshooting, you sometimes need to start outputting warnings or trace messages to
> stderr. If that is going to start triggering unexpected failures, because some tools consider the presence of text on stderr to be an
> indication of failure, it's not going to be fun, is it?

Oh good grief, the UNIX-way of building software has been proven over many decades & there are large numbers of extremely reliable systems built with it. Your lack of experience is showing. Read the documentation, understand the environment, and test the examples offered. You'll find that this stuff works well when you follow best practices.

--Larry