Menu
▾
▴
fetchmail-users
|
From: Thomas W. <to...@to...> - 2005-11-02 15:41:04
|
There has been some discussion about the MDA configuration of fetchmail
in the last few days, and I had proposed my configuration:
> mda "formail >> ${MAIL-$HOME/Post/Inbox}"
or alternatively:
> mda "formail -s procmail -p"
Jakob Hirsch as well as the fetchmail manual page even suggested to
use just procmail alone.
Now I've happened to encounter a really serious problem with procmail.
It turned out to be what the fetchmail man page calls an "unsafe MDA":
> RETRIEVAL FAILURE MODES
> The protocols fetchmail uses to talk to mailservers are
> next to bulletproof. In normal operation forwarding to
> port 25, no message is ever deleted (or even marked for
> deletion) on the host until the SMTP listener on the
> client side has acknowledged to fetchmail that the message
> has been either accepted for delivery or rejected due to a
> spam block.
>
> When forwarding to an MDA, however, there is more possi-
> bility of error. Some MDAs are 'safe' and reliably return
> a nonzero status on any delivery error, even one due to
> temporary resource limits. The well-known procmail(1)
> program is like this; so are most programs designed as
> mail transport agents, such as sendmail(1), and exim(1).
> These programs give back a reliable positive acknowledge-
> ment and can be used with the mda option with no risk of
> mail loss. Unsafe MDAs, though, may return 0 even on
> delivery failure. If this happens, you will lose mail.
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.
I heard before that exceeded quota is a known touchstone for proper
error handling of software. Obviously procmail has a serious issue
here which should be fixed as soon as possible. As long as it is not,
fetchmail should no longer recommend using procmail but rather warn
from it.
Kind regards,
Thomas Wolff
|
|
From: Stephen R. v. d. B. <sr...@cu...> - 2005-11-02 15:51:34
|
On 11/2/05, Thomas Wolff <to...@to...> 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.
Procmail handles quota-exceeded problems
with flying colours since about 1993.
> I heard before that exceeded quota is a known touchstone for proper
> error handling of software. Obviously procmail has a serious issue
> here which should be fixed as soon as possible.
There is a 99.997% probability that the serious
issue is a user error on your part.
>As long as it is not,
> fetchmail should no longer recommend using procmail but rather warn
> from it.
Acting prematurely on the 0.003% chance
that it is procmail's fault, would be unwise.
In order to clarify the issue, it would be helpful
if you can show the used procmailrc files, and
possibly even the generated logfile entries
(by procmail) which describe the event (or
shortly before and after).
Nonetheless, in order to assure timely assistance,
it would be prudent to forward this
information to the procmail mailinglist (instead
of me personally), so they
can help you fix the procmail recipe(s).
See procmail -v as to the address of the list.
--
Sincerely,
Stephen R. van den Berg (AKA BuGless).
|
|
From: Thomas W. <to...@to...> - 2005-11-02 17:58:50
|
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. > ... > In order to clarify the issue, it would be helpful > if you can show the used procmailrc files, ... When I did this, the issue did actually clarify (see below), ... > Nonetheless, in order to assure timely assistance, > it would be prudent to forward this > information to the procmail mailinglist (instead > of me personally), so they > can help you fix the procmail recipe(s). > See procmail -v as to the address of the list. Right; I'm not doing this now because the issue has been clarified. 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. So here is the essential info: bash> cd bash> cat .procmailrc MAILDIR=$HOME/Post :0: testbox bash> cat testmail From: to...@to... To: to...@to... Subject: test mail 1234567890123456789012345678901234567890123456789012345678901234567890 bash> if procmail -p < testmail ; then echo y ; fi procmail: Quota exceeded while writing "testbox" y bash> ls -l Post/testbox -rw------- 1 demsn702 mdd 0 Nov 2 17:08 Post/testbox bash> cat /tmp/procmail.log. procmail: Quota exceeded while writing "testbox" procmail: Truncated file to former size Subject: test mail Folder: /var/mail/.... 1266 bash> 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. It is very unexpected behaviour for a user who has a configuration file that refers only to local folders (for mail sorting, spam filtering, etc). After all, if I configure local folders, I'm doing it just because I do not intend (or cannot) use /var/mail. The event that procmail redirects into the system mailbox due to a failure should be noted clearly to the user in this case (on stdout/stderr, as well as in the logfile folder). 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), but it's not a serious issue as I said before. Procmail handles an inaccessible system mailbox well (this is documented); I was not able to check what would happen if /var/mail is completely inaccessible but I assume something reasonable should happen too, so I withdraw my statement that procmail is an unsafe MDA. User feedback and documentation should be improved, though, and maybe this case of redirection should not be applied at all (or be configurable) and rather a proper error indication returned instead. Thanks and kind regards, Thomas Wolff |
|
From: Stephen R. v. d. B. <sr...@cu...> - 2005-11-02 23:16:06
|
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).
|
|
From: Thomas W. <to...@to...> - 2005-11-10 13:37:40
|
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 |
|
From: Matthias A. <mat...@gm...> - 2005-11-17 10:43:01
|
Thomas Wolff schrieb am 2005-11-10: > > 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? Do not worry, fetchmail will not delete the message if you use a reliable retrieval protocol such as POP3 + UIDL and retry on the next run. > 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. In that particular case, ! redirections will not work either (unless you override SENDMAIL). -- Matthias Andree |
|
From: Matthias A. <mat...@gm...> - 2005-11-17 10:40:38
|
It is a well-known fact that procmail is too demanding to configure
properly for the average user, and the documentation is insufficient in
this respect.
What have the procmail maintainers done in the past four years to remedy
this? Nothing. No documentation, no code changes, no new release.
With my system administrator hat on, I have taken procmail away from
my users and given them maildrop instead, years ago, and I think
fetchmail 6.3.0 should go this route, as suggested by Thomas Wolff.
To use procmail safely, you have to add something after every delivering
recipe, that either you or Philip posted to the postfix-users list ages
ago when I complained:
:0e
{
EXITCODE=75
HOST
}
This is cumbersome, unintuitive, in none of the prominent tutorials, and
ugly as sin. The ugliness at that time caused embarrassed silence...
To the user: use maildrop, it does The Right Thing[TM] out of the box,
namely exiting with EX_TEMPFAIL as per /usr/include/sysexits.h
What's worse, procmail shows many incomplete examples that confuse the
user.
This procmail fallthrough behavior that makes the many popular and
shipped (see procmailex!) examples so unusable that users have to start
chasing their mail in bad weather is what makes me support Thomas's
original suggestion in spite of the problem being his own fault.
The problem gets worse when multiple rules may match a message. In that
case, the order of matches makes a difference, and mail may end up in
the wrong box, when, for instance by a POP3 or IMAP server shuffling its
mailbox around, /var/mail is TEMPORARILY out of space - the first rule
matches, attempt FOR DELIVERY fails, the mail server lets go of the
temporary file of the other user, meanwhile procmail falls through, the
second rule matches and delivery succeeds -> boom, the mail is in the
wrong destination.
Just unsetting DEFAULT/ORGMAIL as you suggest below is not sufficient to
fix this. It's also a long shot from being anywhere close to a solution.
> > User feedback and documentation should be improved,
>
> Please provide suggestions as to what wording in the logfile would have made
> it more clear?
The logfile should be enabled by default, and right in the face of the
user: $HOME/procmail.log
> Same question for the manpage; in what way should we rephrase it?
The code must change, not the manual page. In order not to break
existing setups, you should make new "EX_TEMPFAIL right away" behavior a
compile-time switch that defaults to off, or you should make it a
feature that is so prominently documented it warrants a version bump to
procmail 4.
> > 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).
procmail's undeterministic behavior is worse than a bounce.
A message that is delivered to the wrong place is a message lost for the
user, and at best one that causes additional work. Why use a filter at
all if it doesn't work? procmail's "intelligence" is a disservice to
users. We've been through this before, and you fail to see the point.
Imagine someone filtering his important messages (from VIP, with special
subject) to a particular "important" mailbox, to see the mail early, and
only checks his default mailbox once in a while. He'll "lose" that
important mail and only find it later. Is *that* smart? No, it isn't.
maildrop takes care to exit with EX_TEMPFAIL unless there is a really
clear permanent problem (such as user not found in virtual setups). That
makes the message stay in the queue, and fetchmail will thus leave it on
the server and retry later, and that is what users expect.
> > (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).
As shown above, this does not work for any setups except perhaps (full
example) this trivial one:
DEFAULT
ORGMAIL
:0:
everything
--
Matthias Andree
|
|
From: Michelle K. <lin...@fr...> - 2005-11-07 19:30:49
|
Hello Thomas,
Am 2005-11-02 17:58:28, schrieb Thomas Wolff:
> I would not say this issue was a user error on my part (because it's
> not properly documented), but it's not a serious issue as I said
> before. Procmail handles an inaccessible system mailbox well (this is
> documented); I was not able to check what would happen if /var/mail is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> completely inaccessible but I assume something reasonable should
^^^^^^^^^^^^^^^^^^^^^^^
> happen too, so I withdraw my statement that procmail is an unsafe MDA.
>
> User feedback and documentation should be improved, though, and maybe
> this case of redirection should not be applied at all (or be configurable)
> and rather a proper error indication returned instead.
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.
> Thanks and kind regards,
> Thomas Wolff
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Sunil S. <sh...@bo...> - 2005-11-14 13:51:36
|
Quoting from Michelle Konzack's mail on Mon, Nov 07, 2005 at 07:29:19PM +0100: > 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. procmail has a way of returning with an error. You may append the lines below to your procmailrc for error handling. ========================================================================== # if procmail has reached here, delivery has failed. return with a # temporary failure code from <sysexits.h>. # 75 = EX_TEMPFAIL EXITCODE=75 :0 /dev/null ========================================================================== WARNING: the above recipe works only when the program invoking procmail handles the exit code gracefully. Otherwise, all your mails will be trashed. fetchmail will not delete these mails. Even, most SMTP servers should queue up such mails for a few days before bouncing them back. But, if you have other programs invoking procmail, you will need to check if they handle such exit codes gracefully. -- Sunil Shetye. |
|
From: Michelle K. <lin...@fr...> - 2005-11-17 13:28:28
|
Hello Sunil, Am 2005-11-14 18:23:58, schrieb Sunil Shetye: > procmail has a way of returning with an error. You may append the > lines below to your procmailrc for error handling. > > ========================================================================== > > # if procmail has reached here, delivery has failed. return with a > # temporary failure code from <sysexits.h>. > # 75 = EX_TEMPFAIL > EXITCODE=75 > :0 > /dev/null > ========================================================================== This is, what I was searching for. > WARNING: the above recipe works only when the program invoking > procmail handles the exit code gracefully. Otherwise, all your mails > will be trashed. > > fetchmail will not delete these mails. Even, most SMTP servers should I use only fetchmail + courier-mta while the MTA receives regulary messages and fetchmail collect (at $USER request) messages from other ISP's > queue up such mails for a few days before bouncing them back. But, if > you have other programs invoking procmail, you will need to check if > they handle such exit codes gracefully. So I think, courier-mta will work to. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com) |
|
From: Rob F. <rf...@fu...> - 2005-11-07 19:46:22
|
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. As Stephen van den Berg posted: | 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). -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Michelle K. <lin...@fr...> - 2005-11-10 13:27:56
|
Hi Rob,
Am 2005-11-07 13:46:15, schrieb Rob Funk:
> As Stephen van den Berg posted:
>
> | 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).
Hmmm, I have tried this, but $DEFAULT is set in the $USER configs to
DEFAULT=$MAILDIR/.maybe_spam/
and ORGMAIL is unset.
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Rob F. <rf...@fu...> - 2005-11-10 14:07:13
|
Michelle Konzack wrote: > Am 2005-11-07 13:46:15, schrieb Rob Funk: > > As Stephen van den Berg posted: > > | 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). > > Hmmm, I have tried this, but $DEFAULT is set in the $USER configs to > > DEFAULT=$MAILDIR/.maybe_spam/ > > and ORGMAIL is unset. Do you have a line that's just: ORGMAIL in the file? If you don't, then ORGMAIL is not unset. -- ==============================| "A microscope locked in on one point Rob Funk <rf...@fu...> |Never sees what kind of room that it's in" http://www.funknet.net/rfunk | -- Chris Mars, "Stuck in Rewind" |
|
From: Thomas W. <to...@to...> - 2005-11-15 12:45:05
|
Sunil Shetye wrote: > Quoting from Michelle Konzack's mail on Mon, Nov 07, 2005 at 07:29:19PM +0100: > > ... > > I think, procmail should have an config option to stop > > this behaviour and return an error instead. > > ... > > procmail has a way of returning with an error. You may append the > lines below to your procmailrc for error handling. > ... > ========================================================================== > > # if procmail has reached here, delivery has failed. return with a > # temporary failure code from <sysexits.h>. > # 75 = EX_TEMPFAIL > EXITCODE=75 > :0 > /dev/null > ========================================================================== So that may work, but it is really an obscure trick. Fetchmail needs to have an easy-to-use, well-documented facility to configure its error behaviour in an obvious way. > WARNING: the above recipe works only when the program invoking > procmail handles the exit code gracefully. Otherwise, all your mails > will be trashed. > > fetchmail will not delete these mails. Even, most SMTP servers should > queue up such mails for a few days before bouncing them back. But, if > you have other programs invoking procmail, you will need to check if > they handle such exit codes gracefully. That other program may often be formail. While formail -s does propagate an error return code here, this is not reliable because it's not documented. Should be fixed. Kind regards, Thomas Wolff |
|
From: Jakob H. <jh...@pl...> - 2005-11-15 14:36:05
|
Thomas Wolff wrote: >> # if procmail has reached here, delivery has failed. return with a >> # temporary failure code from <sysexits.h>. >> # 75 = EX_TEMPFAIL >> EXITCODE=75 >> :0 >> /dev/null > So that may work, but it is really an obscure trick. > Fetchmail needs to have an easy-to-use, well-documented facility to > configure its error behaviour in an obvious way. This is not a fetchmail issue and this whole discussion is unrelated to fetchmail. If you are really interested in improving procmail's error behaviour, you should move this to the procmail-list. As a sidenote: I doubt procmail is so bad, but you never know. Anyway, I used maildrop for quite a while. Main reason was its non-obfuscating filter language, but it also has a proper error handling. And I never needed anything like formail to use it as MDA. > That other program may often be formail. While formail -s does > propagate an error return code here, this is not reliable because it's > not documented. Should be fixed. By whom? Certainly not by any fetchmail maintainer. |
|
From: Thomas W. <to...@to...> - 2005-11-15 15:20:55
|
I had confused: >> # if procmail has reached here, delivery has failed. return with a >> ... > Fetchmail needs ... Jakob Hirsch wrote: > This is not a fetchmail issue and this whole discussion is unrelated to > fetchmail. If you are really interested in improving procmail's error > behaviour, you should move this to the procmail-list. Sure, sorry for my confusion. > As a sidenote: I doubt procmail is so bad, but you never know. Anyway, I used > maildrop for quite a while. Main reason was its non-obfuscating filter > language, but it also has a proper error handling. And I never needed anything > like formail to use it as MDA. Thanks for the hint, it looks promising. Kind regards, Thomas Wolff |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X