This is the mail archive of the
mailing list for the Cygwin project.
Re: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
Am 25.02.2010 00:04, schrieb Thomas Baker:
>>> Are you configured for case sensitive filenames? What does the
>>> following indicate?
>>> $ regtool get '\HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive'
>> I am on the road today with the netbook, and on the netbook the command
>> above yields a response of "1".
> On the desktop, I also get a response of "1".
>> I see that the command
>> $ cd /home
>> $ ls -n /home/tbaker TBaker
>> does _not_ work on the netbook, though I guess this will not be an issue
>> if the /etc/passwd on the netbook already uses "tbaker"?
> But on the desktop, I was able to make a link under /home:
> dr-xr-xr-x+ 1 tbaker None 0 2010-02-24 17:53 Administrator
> lrwxrwxrwx 1 tbaker None 12 2010-02-23 18:07 TBaker -> /home/tbaker
> dr-xr-xr-x+ 1 tbaker None 0 2010-02-24 17:53 tbaker
> That seems inconsistent, but I guess the changed /etc/passwd entry
> on the desktop has solved the problem, so I will not worry about this.
So to summarize, in spite of the obcaseinsensitive = 1 you have a case sensitive
?:/cygwin/home path. The passwd entry was pointing to an almost empty home
directory, and procmail consequently wasn't finding its procmailrc file.
For the fetchmail upstream (that's me), I take it that fetchmail behaved as
documented in that it launched procmail and injected the messages, procmail
delivered according to its built-in defaults or /etc/procmailrc, and fetchmail
removed the messages after successful delivery through procmail. (technically
successfully, i. e. messages are on disk somewhere -- that's all you get with
Now, to set the records straight, fetchmail 6.3 does not and cannot do any kind
of delivery. It will use SMTP (via TCP), LMTP (via TCP or Unix socket), or an
MDA (via anonymous pipe) to inject messages.
For procmail, it is notorious and infamous for its awkward error handling (or
non-handling, I should say, it ignores most errors and happily continues with
the next rule). It's basically unusable because you never know where your mail
ends up unless all of these are fulfilled:
* you keep a LOGFILE so you manually look up where you mail ended up
* you add a rule like this after each and every other procmail recipe:
* you use use proper options (such as w on filtering recipes) so that procmail
actually checks for errors
* you add an explicit rule to deliver to your default mailbox, for instance:
This would be the minimum error-handling .procmailrc.
The :0e stuff was discussed on the procmail list (AFAIR) ages ago and does the
- if the previous rule failed, change the exit code 75 (which is EX_TEMPFAIL in
- stop processing (that's what the HOST line does: it blanks the hostname, and
due to the mismatch, processing aborts).
Jason, would you include this EXITCODE/HOST stuff and other hints into your
Cygwin README file? I don't think the upstream version will ever change again,
procmail is apparently dead for nearly a decade. For debugging, I'd also suggest
to mention LOGABSTRACT=all and LOGFILE along with VERBOSE=yes.
LOGFILE=/dev/stderr may prove useful in command line testing.
I'd suggest to drop procmail in the long run and provide Sam Varshavchik's
maildrop instead. It is easier to configure and more robust, and it's actually
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple