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

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

> > [...]
> > 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.
>
> You did say "and" above, but that is not what getmail does. It writes errors to stderr and exits with a zero exit status, indicating no
> trouble, yet it did not process some e-mails because they failed.
>
> You did read what I said about backing up with tools like rsync and tar, if they did that, didn't you?

I have read what you have written.

> > 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,
>
> You do know that there are other ways, like systemd, do you?

Yes I am well aware of them.

> It is not common in the Unix world to infer errors just from the presence of
> text in stderr.

A good point, but I'm not sure it is relevant to the situation at hand.

> I have written here a couple of times that sometimes you get warnings (not errors) on stderr, and sometimes, while
> troubleshooting, you need to enable tracing to stderr. You did read all that detailed reasoning in my previous mail, did > you?

Yes I have read what you've written.

> > [...]> Your lack of experience is showing.
>
> Quit discrediting me already. If someone needs to pay attention, or learn at least good manners, it's you.

Okay, fair enough, but understand it is not my intent to discredit you. I (and others) are attempting to give you advice and guidance to solve your e-mail problem. You seem intent on arguing from your perspective rather than trying to absorb and apply the advice you've been given. If these tools were as fragile as you seem to think they are, would they be in such widespread use as they are? I don't think so. By way of example, when I start out with some new software I seek to follow the documentation and examples provided to get it set up and running as intended. Along the way I discover what works and what doesn't. Sometimes what appears not to work is really a bug, sometimes it's just me not understanding how the software was intended to be used. In order to be taken seriously when I report a bug or ask why something doesn't work, I need to demonstrate that I've followed best practices and am still running into problems. That does not appear to be your approach & thus, we the "adorable experts" as you called us may be a bit impatient with your questions and arguments. Maybe ask yourself: if so many people can get this stuff to work reliably, why can't I? The answer may well be your approach to the problem.

--Larry