X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Message-ID: <4B863157.2050202@gmx.de>
Date: Thu, 25 Feb 2010 09:14:15 +0100
From: Matthias Andree <matthias DOT andree AT gmx DOT de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com, Jason Tishler <jason AT tishler DOT net>
Subject: Re: Fetchmail call to procmail no longer works under Cygwin 1.7.1-1
References: <3a8528891002221452h48008b49t2a17aa42a97ee5e AT mail DOT gmail DOT com> 	 <20100223131352 DOT GA4172 AT tishler DOT net> 	 <3a8528891002230733x644a3bc1na91ddccacafb2e41 AT mail DOT gmail DOT com> 	 <20100223164927 DOT GA212 AT mimosa DOT garydjones DOT name> 	 <20100223182852 DOT GD4172 AT tishler DOT net> 	 <3a8528891002231114p3b23ef4cjced067a0b16fa9fd AT mail DOT gmail DOT com> 	 <20100223193543 DOT GE4172 AT tishler DOT net> 	 <3a8528891002231220w428ec33x74a19275e8a537bf AT mail DOT gmail DOT com> 	 <20100224132513 DOT GA3892 AT tishler DOT net> 	 <3a8528891002240702n5d17c520m88906fb24e9a1d49 AT mail DOT gmail DOT com> <3a8528891002241504x6ed224b4k4b70f049bab483df AT mail DOT gmail DOT com>
In-Reply-To: <3a8528891002241504x6ed224b4k4b70f049bab483df@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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
procmail).

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:

:0e
{
  EXITCODE=75
  HOST
}

* 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:

:0:
$DEFAULT

:0e
{
  EXITCODE=75
  HOST
}


This would be the minimum error-handling .procmailrc.

The :0e stuff was discussed on the procmail list (AFAIR) ages ago and does the
following:
- if the previous rule failed, change the exit code 75 (which is EX_TEMPFAIL in
/usr/include/sysexits.h)
- 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
maintained.

-- 
Matthias Andree

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple