Re: [fetchmail-users] Re: unsafe MDA procmail recommended by fetchmail

[Thomas W. <to...@to...>]

I had written:
> > > I had a "disk quota exceeded" condition here which procmail failed
> > > to handle properly. It accepted its input, threw it away and just
> > > returned success.

Stephen van den Berg wrote:
> > > Procmail handles quota-exceeded problems
> > > with flying colours since about 1993.
> >
> > > There is a 99.997% probability that the serious
> > > issue is a user error on your part.
> ...


> > bash> cat /tmp/procmail.log.
> > procmail: Quota exceeded while writing "testbox"
> > procmail: Truncated file to former size
> >  Subject: test mail
> >   Folder: /var/mail/....                                                 1266
> 
> > At this point, I noticed that procmail has a fallback behaviour
> > that when delivery to a local folder fails, it delivers into
> > /var/mail instead. So actually the mail was not lost.
> > This is, however, not documented anywhere.
> [...]
> > So, quoting you again
> > > There is a 99.997% probability that the serious
> > > issue is a user error on your part.
> > I would not say this issue was a user error on my part (because it's
> > not properly documented),

> $ man procmailrc
> [...]
Well, this is not very obvious, because I have to check the manual of 
procmailrc to find out about some basic workflow behaviour of procmail.
And I even have to study the descriptions of the environment variables 
(total of > 250 lines) before I get a clue on this handling mode.

>        ORGMAIL     Usually  the  system  mailbox  (ORiGinal MAILbox).  If, for
>                    some obscure reason (like `filesystem full') the mail could
>                    not  be  delivered,  then  this  mailbox  will  be the last
>                    resort.  If procmail fails to save the mail in here  (deep,
>                    deep  trouble  :-),  then  the mail will bounce back to the
>                    sender.
What would "bounce back" actually mean in an environment with no working 
or properly configured sendmail interface?


> > User feedback and documentation should be improved,
> 
> Please provide suggestions as to what wording in the logfile would have made
> it more clear?
Instead of just reporting the actual output file:
  Folder: /var/mail/....                                                 1266
the logfile should clearly indicate that this was a fallback situation, 
like:
procmail: Truncated file to former size
procmail: Redirecting to system folder as a replacement


> Even without asking on the mailinglist, the logfile
> should have made clear what happened.
Maybe, once you look at it. You don't normally do that, especially as 
the manual is very terse about the logfile and doesn't mention that 
it will be in /tmp by default. In any case, there should be a clear 
error message and indication what procmail did on stderr, too.


> Same question for the manpage; in what way should we rephrase it?
The mail delivery strategy, as well as (at least the names of all) the 
options and settings that can modify it, should be clearly described 
in a paragraph of the initial DESCRIPTION section already.
Currently, it's:
>       ... $HOME/.procmailrc.   According  to  the  processing
>       recipes in this file, 
The recipes do not include any fallback behaviour which is rather implicit.
>       the mail message that  just  arrived
>       gets  distributed into the right folder (and more).
So which are the right and, especially, which are the "more" folders?
>       If no
>       rcfile is found, or processing of the rcfile falls off the
>       end,  procmail  will  store the mail in the default system
>       mailbox.
OK, the system mailbox is mentioned, but not for the case in question.
Same in man procmailrc. All description of error handling is hidden 
deep in the description of settings that one could well assume to be 
optional.


> > ... and maybe this case of redirection should not be applied at all
> 
> Mail wants to arrive.  That means, if we can salvage the mail, instead of
> bouncing it, then that is the preferred solution.  Rescueing instead of
> giving up is the proper action.
I agree this is basically the right strategy.

> It basically guards the user from his
> own lack of knowledge on the situation (and since the user can't
> be asked at that point, procmail has to make an intelligent decision).
The problem here is that the user also has a lack of knowledge on 
procmail's handling of the situation. Once the manual is improved, 
and also the options to tweak the behaviour, it will be fine.


> > (or be configurable)
> 
> It is, just put the following lines anywhere in your .procmailrc file:
>   DEFAULT
>   ORGMAIL
> Which will unset the DEFAULT and ORGMAIL variables (and prevent
> evasive action in case of system or user error).
These variables only briefly occur in man procmail and are not described 
there. There is no hint either that man procmailrc will have to be 
studied to configure behaviour in error situations, and even there it's 
(as said above) hidden somewhere in the long list of settings.
The DESCRIPTION should clearly refer to the relevance of DEFAULT and 
ORGMAIL for proper adaptation to your specific environment, otherwise 
it's next to useless for the non-Guru, and I'm glad to be confirmed 
that I'm not the only one who couldn't easily assemble a proper 
configuration as Michelle Konzack wrote:
> So right, I am using fetchmail + procmail + courier-imap
> and sometimes They are errors and messages are going into
> /var/mail/<$USER> which are inaccessible.  Specialy if I
> have more then 17.000 $USER.
> 
> I think, procmail should have an config option to stop
> this behaviour and return an error instead.
> 
> It is not funny to walk through 17.000 Mailboxes to get
> the "lost" messages back into the $USER mailboxes.


Actually, I think there is also an option missing to prevent procmail 
from attempts to bounce a mail after failed delivery. As I indicated 
above, not all system configuration provide working outgoing mail 
(at least not through the standard interfaces). I, for instance, use 
ssmtp with a script wrapper; /usr/sbin/sendmail is not working here.
In this case (not bouncing failed mail), procmail should of course 
return an error code so e.g. fetchmail notices and doesn't delete 
the mail from the server.


Thanks for your consideration and your request for suggestions to 
improve documentation, which I hope to have done.

Best regards,
Thomas Wolff