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

> getmail should already be exiting nonzero when a delivery error happens.  Did
> you already test this and find differently?

To be honest, I do not know anymore where I got that idea from, I forgot. I must have been reading too many Postfix man pages lately. 8-) All I know 
now is that I have stated it in several e-mails to this mailing list, with detailed reasoning about it, and yet nobody has challenged that assumption.

Have you perhaps looked at the code since then, and are now convinced that the exit code will be non-zero?

I cannot actually test it now, but I will get back to it soon enough (hopefully). I am also a little impeded because I do not know Python.

In the meantime, as I already stated above, it is good practice to document the exit codes. I even gave you the following (really cool) starting text:

   EXIT STATUS

   0 on success
   something else on critical error

You could then explain what you meant by "nonfatal error", and what difference it makes, or should make, with respect to the exit status, if any.

Here is my suggestion: Why don't you finish the tiny documentation section above and add it to getmail's man page or web documentation? That would 
certainly help prevent doubts or misunderstandings like the one we are having now, not just for me, for other users too.


Furthermore, I stated in my very first e-mail: "I have seen a failing e-mail in a different scenario stopping the processing of all other e-mails 
altogether."

Here are the details I have collected: During testing, I set up a catch-all address, which then received a few e-mails. But I once sent an e-mail from 
the catch-all to the same catch-all again. Or something similar. This one e-mail did not have the X-Original-To header, but all other e-mails did.

It got interesting, because I deleted the mail with Thunderbird, but 2 invisible copies remained, one in the 'Sent' and one in the 'Inbox' folder. I 
could see them marked as deleted with Roundcube, but only with Roundcube, not with Thunderbird. I haven't had time to investigate this issue further. 
getmail saw them too, and tried to download them even though they were apparently marked as deleted.

In any case, I had configured getmail like this:

[retriever]

type = MultidropIMAPSSLRetriever
   <...>
envelope_recipient = X-Original-To:1


One or both copies of that single mail without X-Original-To made getmail stop abruptly. Is that what you would consider a fatal error?

I would have expected getmail to carry on to the next e-mail, but it is not clearly documented. The only mention in the documentation about carrying 
on in case of failure is in the ignore_stderr argument in sections MDA_external, "Creating the [filter-something] sections" and Filter_classifier 
sections, but I would have thought that the same rule should apply when collecting the mails over IMAP (before filtering or delivering).

By the way, I am using getmail version 5.13-1build1 that comes with Ubuntu MATE 20.04.

The moment I "really" deleted those "marked as deleted" mails with Roundcube, getmail was able to pick up and deliver the other mails. So that one bad 
e-mail stopped the whole mail collection.

Regards,
   rdiez