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

[Stephen R. v. d. B. <sr...@cu...>]

On 11/2/05, Thomas Wolff <to...@to...> wrote:
> I wrote:
> > 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.

> Actually, it would also be prudent to add the mailing list address to
> the man page, in either the AUTHORS section or at least the -v description.

$ man procmail
[...]
MAILINGLIST
       There exists a mailinglist for questions relating to any program in the
       procmail package:
              <pro...@pr...>
                     for submitting questions/answers.
[...]
AUTHORS
[...]

> bash> cat /tmp/procmail.log.
> procmail: Quota exceeded while writing "testbox"
> procmail: Truncated file to former size
>  Subject: test mail
>   Folder: /var/mail/....                                                 1266

Even without asking on the mailinglist, the logfile
should have made clear what happened.

> 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
[...]
       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.
[...]

> User feedback and documentation should be improved,

Please provide suggestions as to what wording in the logfile would have made
it more clear?
Same question for the manpage; in what way should we rephrase it?

> though, 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.  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).

> (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).
--
Sincerely,
                Stephen R. van den Berg (AKA BuGless).