fetchmail 5.9.8 and maildrop 1.3.7

fetchmail 5.9.8 and maildrop 1.3.7

[Rui Carmo]

Hello again,

Just to report that fetchmail 5.9.8 compiles cleanly on cygwin, and that we seem to be heading towards a fully functioning e-mail solution (well, with ssmtp to forward mail to a smarter MTA, at least). Just grab the sources and do:

/configure --with-ssl 
make
make install

(I did not change config.h or any other options)

I've also been fiddling with maildrop-1.3.7 (actually maildrop-1.3.7.20020215...), an MDA (Mail Delivery Agent) that is part of the Courier kit. It required a trivial change to compile cleanly (something related to timezones, AFAIR a typecast gone astray), and I have managed to get both packages to work together (i.e., I actually fetched mail from my IMAP-SSL account and delivered to /var/spool/mail/user using both).

However, mutt then complains that /var/spool/mail/user is not a valid mbox file, since somewhere along the line, an extra blank line is inserted at the beginning of the mailbox upon creation. Editing it out by hand solves the problem, but is a rather lame fix.

I've tried to figure out why this happens, but will have to devote more attention to other stuff (I'm rather keen on looking at the rxvt sources at the moment, and reading mail directly via IMAP-SSL with mutt works fine for me).

Nevertheless, I think this bit of news will be of interest to those who actually need a full fetchmail-MDA combo.

You can get maildrop at http://www.flounder.net/~mrsam/maildrop, and fetchmail at http://www.tuxedo.org/~esr/fetchmail/

I'll probably have a go at the full Courier package one day (I rather fancy the notion of having a proper SMTP/IMAP server on my box), but from what I saw from a test compile, it'll be an uphill battle... :)

Best regards,

Rui Carmo




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: fetchmail 5.9.8 and maildrop 1.3.7

[Jason Tishler]

Rui,

On Sat, Mar 02, 2002 at 12:45:12AM +0000, Rui Carmo wrote:
> Just to report that fetchmail 5.9.8 compiles cleanly on cygwin,

If you run under Win2K (and possibly WinXP), you may want to see the
following to save yourself some grief:

    http://sources.redhat.com/ml/cygwin/2001-08/msg00628.html

However, so far no one else seems to have noticed this problem.

> I've also been fiddling with maildrop-1.3.7 ...
> 
> However, mutt then complains that /var/spool/mail/user is not a valid
> mbox file, since somewhere along the line, an extra blank line is inserted
> at the beginning of the mailbox upon creation. Editing it out by hand
> solves the problem, but is a rather lame fix.

If you are having problems with maildrop, then I suggest trying procmail.
I have been using the fetchmail/procmail/mutt combination very successfully
under Cygwin for some time now.

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: fetchmail 5.9.8 and maildrop 1.3.7

[Rui Carmo]

Jason,

On Sat, Mar 02, 2002 at 11:03:32AM -0500, Jason Tishler wrote:
> If you run under Win2K (and possibly WinXP), you may want to see the
> following to save yourself some grief:
> 
>     http://sources.redhat.com/ml/cygwin/2001-08/msg00628.html
> 
> However, so far no one else seems to have noticed this problem.

I was under the impression that recv() bugs had been twiddled in 1.3.10... Or did the changes in recv() not address MSG_PEEK?

I did not notice any corruption issues with my fetchmail build - but then, I did not transfer much more than a few megs of mail (around 25MB, I think).

> If you are having problems with maildrop, then I suggest trying procmail.
> I have been using the fetchmail/procmail/mutt combination very successfully
> under Cygwin for some time now.

Well, the reason I tried maildrop was that, after searching the mailing list (and I do recall finding the message you refer to, for instance), I found that you had to install BIND to build procmail. I also like the Courier suite, and intend to have a go at it later. :)

I'm also not entirely sure that fetchmail is not the one inserting (or handing over, or whatever) the extra blank line upon mailbox creation (appends work fine...). I'll have to check later.

Anyway, if you've been using fetchmail + procmail since September, what's keeping it from being added to the packages list? :) Is it the BIND issue?

(I'd be glad to lend a hand, mind you...)

Rui Carmo



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: fetchmail 5.9.8 and maildrop 1.3.7

[Jason Tishler]

Rui,

On Sat, Mar 02, 2002 at 10:12:20PM +0000, Rui Carmo wrote:
> On Sat, Mar 02, 2002 at 11:03:32AM -0500, Jason Tishler wrote:
> > However, so far no one else seems to have noticed this problem.
> 
> I was under the impression that recv() bugs had been twiddled in
> 1.3.10... Or did the changes in recv() not address MSG_PEEK?

Hmm, I will look into this.  It would be great if my patch just became
obsolete.

> I did not notice any corruption issues with my fetchmail build - but
> then, I did not transfer much more than a few megs of mail (around 25MB,
> I think).

Like I said, no one else seems to have this corruption problem.  Note
that I spent quite a few hours one day last summer inside of gdb trying
to get to the bottom of this problem.  I saw the read() return less
characters than requested even though the number requested is less than
or equal to what was returned from the recv(..., MSG_PEEK).  Trust me,
this causes bad things to happen to your mail.

> I'm also not entirely sure that fetchmail is not the one inserting
> (or handing over, or whatever) the extra blank line upon mailbox creation
> (appends work fine...). I'll have to check later.

My WAG would be on the MDA (i.e., maildrop) not fetchmail.  BTW, I have
had no such problems with procmail regardless of mailbox creation or
appending.

> Anyway, if you've been using fetchmail + procmail since September,
> what's keeping it from being added to the packages list? :) Is it the
> BIND issue?

No, it's not BIND -- it's just laziness on my part.  I really would like
to contribute fetchmail and procmail.  Unfortunately, it appears that I
have chosen unwisely selecting the packages that I currently maintain --
PostgreSQL and Python.  These two seem to keep me quite busy.

Maybe I should have chosen packages that no one ever uses.  You know...
Shelfware.  That would have minimized my support efforts. :,)

> (I'd be glad to lend a hand, mind you...)

If you would like to contribute BIND, fetchmail, or procmail, please let
me know.  I will supply you with my build recipes and help you in anyway
that I can.

Thanks,
Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: fetchmail 5.9.8 and maildrop 1.3.7

[Rui Carmo]

Jason,

On Sat, Mar 02, 2002 at 09:47:19PM -0500, Jason Tishler wrote:
> Rui,
> 
> > I was under the impression that recv() bugs had been twiddled in
> > 1.3.10... Or did the changes in recv() not address MSG_PEEK?
> 
> Hmm, I will look into this.  It would be great if my patch just became
> obsolete.

The release notes (post by Cristopher: http://sources.redhat.com/ml/cygwin/2002-02/msg01350.html) mention recv() explicitly:

> - Implement socket read/write using recv/send. (corinna)

Bit vague, though, so I don't know if Corinna tackled the MSG_PEEK issue. Mind you, the thought has crossed my mind that XP has a tweaked TCP/IP stack, but we're getting into Twilight Zone stuff here... I'll probably filter my e-mail to another box for a few weeks (build up a REAL large mailbox), then let my 'clean' build of fetchmail have a go at 100 or so megs of mail a couple of times, and diff the results ;)

> > I'm also not entirely sure that fetchmail is not the one inserting
> > (or handing over, or whatever) the extra blank line upon mailbox creation
> > (appends work fine...). I'll have to check later.
> 
> My WAG would be on the MDA (i.e., maildrop) not fetchmail.  BTW, I have
> had no such problems with procmail regardless of mailbox creation or
> appending.

Well... Since it's a single blank line, it might actually come from anywhere. I've run maildrop from the command line, faked all the right inputs, and it workedfine (no blank line). But then, I'm not an MTA, so I might have screwed up someplace. Again, I use mutt mostly over IMAP-SSL (and need to access my e-mail from far too many boxes to feel comfortable with it being fetched just to my laptop), so I'm not going to look into this much further for now.

> > Anyway, if you've been using fetchmail + procmail since September,
> > what's keeping it from being added to the packages list? :) Is it the
> > BIND issue?
> 
> No, it's not BIND -- it's just laziness on my part.  I really would like
> to contribute fetchmail and procmail.  Unfortunately, it appears that I
> have chosen unwisely selecting the packages that I currently maintain --
> PostgreSQL and Python.  These two seem to keep me quite busy.

Ouch. :)

> Maybe I should have chosen packages that no one ever uses.  You know...
> Shelfware.  That would have minimized my support efforts. :,)

LOL. Well, I got ion (http://www.students.tut.fi/~tuomov/ion/), the minimalistic screen-like X window manager to run properly under cygwin-xfree, and would hearltily recommend it as one such package :)

(Actually, I find ion pretty useful, although my build of GTKYahoo - yes, under Cygwin - it CAN be done... - tends to freak out under it.)

> > (I'd be glad to lend a hand, mind you...)
> 
> If you would like to contribute BIND, fetchmail, or procmail, please let
> me know.  I will supply you with my build recipes and help you in anyway
> that I can.

Okay. Here's the deal: I'm going to dive into rxvt (the cursor display corruption bug is really annoying for me, since I _want_ to use Lucida Console as a display font under TrueType), and if I can get anywhere, I'll probably take up your offer on fetchmail. 

(procmail is far too arcane for me, I must admit)

Rui Carmo



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

recv(..., MSG_PEEK) (was Re: fetchmail 5.9.8 and maildrop 1.3.7)

[Jason Tishler]

Corinna,

On Sun, Mar 03, 2002 at 03:58:18PM +0000, Rui Carmo wrote:
> On Sat, Mar 02, 2002 at 09:47:19PM -0500, Jason Tishler wrote:
> > > I was under the impression that recv() bugs had been twiddled in
> > > 1.3.10... Or did the changes in recv() not address MSG_PEEK?
> > 
> > Hmm, I will look into this.  It would be great if my patch just became
> > obsolete.
> 
> The release notes (post by Cristopher:
> http://sources.redhat.com/ml/cygwin/2002-02/msg01350.html) mention recv()
> explicitly:
> 
> > - Implement socket read/write using recv/send. (corinna)
> 
> Bit vague, though, so I don't know if Corinna tackled the MSG_PEEK
> issue.

Could you comment as to whether or not the above changes would have any
positive affects on the following?

    http://sources.redhat.com/ml/cygwin/2001-08/msg00628.html

I could just try to determine this empirically, but since this is very
disruptive to my mail delivery, I was hoping for a "warm fuzzy" first.

Thanks,
Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: recv(..., MSG_PEEK) (was Re: fetchmail 5.9.8 and maildrop 1.3.7)

[Corinna Vinschen]

On Mon, Mar 04, 2002 at 10:56:50AM -0500, Jason Tishler wrote:
> Corinna,
> 
> On Sun, Mar 03, 2002 at 03:58:18PM +0000, Rui Carmo wrote:
> > On Sat, Mar 02, 2002 at 09:47:19PM -0500, Jason Tishler wrote:
> > > > I was under the impression that recv() bugs had been twiddled in
> > > > 1.3.10... Or did the changes in recv() not address MSG_PEEK?
> > > 
> > > Hmm, I will look into this.  It would be great if my patch just became
> > > obsolete.
> > 
> > The release notes (post by Cristopher:
> > http://sources.redhat.com/ml/cygwin/2002-02/msg01350.html) mention recv()
> > explicitly:
> > 
> > > - Implement socket read/write using recv/send. (corinna)
> > 
> > Bit vague, though, so I don't know if Corinna tackled the MSG_PEEK
> > issue.
> 
> Could you comment as to whether or not the above changes would have any
> positive affects on the following?
> 
>     http://sources.redhat.com/ml/cygwin/2001-08/msg00628.html

No.  The above change is sort of a code cleanup.  I don't know how
we could workaround that Winsock problem in Cygwin.  It doesn't know
from where you got the `n' parameter and it's perfectly legal for
a read() call to return a number of bytes < n.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: recv(..., MSG_PEEK) (was Re: fetchmail 5.9.8 and maildrop 1.3.7)

[Jason Tishler]

Corinna,

On Tue, Mar 05, 2002 at 10:14:07AM +0100, Corinna Vinschen wrote:
> On Mon, Mar 04, 2002 at 10:56:50AM -0500, Jason Tishler wrote:
> > Could you comment as to whether or not the above changes would have any
> > positive affects on the following?
> > 
> >     http://sources.redhat.com/ml/cygwin/2001-08/msg00628.html
> 
> No.  The above change is sort of a code cleanup.  I don't know how
> we could workaround that Winsock problem in Cygwin.  It doesn't know
> from where you got the `n' parameter and it's perfectly legal for
> a read() call to return a number of bytes < n.

The above is what I thought.  I appreciate you confirming this.

I guess it is time for me to clean up my patch and submit it to fetchmail
CVS for consideration...

Thanks,
Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Cygwin maildrop patches and issues (was Re: fetchmail 5.9.8 ...)

[Jason Tishler]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

Rui,

On Sat, Mar 02, 2002 at 12:45:12AM +0000, Rui Carmo wrote:
> However, mutt then complains that /var/spool/mail/user is not a valid
> mbox file, since somewhere along the line, an extra blank line is inserted
> at the beginning of the mailbox upon creation. Editing it out by hand
> solves the problem, but is a rather lame fix.

The first attachment solves the above problem.

Unfortunately, I have discovered other problems:

1. maildrop appears (at least under Cygwin) to not quite respect
dotlocking and actually removes the lock file created by other
processes!  The second attachment "solves" this problem.

2. maildrop appears to lock in a different order (i.e., dotlock then
fcntl()) than mutt (and procmail) (i.e., fcntl() then dotlock) so I'm
concerned about race conditions.

3. maildrop causes Cygwin to spin while another process has locked a mbox
via fcntl(F_SETLK).  If interested, see the third attachment for details.

I'm interested in getting Cygwin maildrop to work because it is much
easier to build (and maintain) than procmail.  Unfortunately, I'm getting
the impression that maildrop is used more for maildirs than for mboxes...

Thanks,
Jason

[-- Attachment #2: formatmbox.C.diff --]
[-- Type: text/plain, Size: 235 bytes --]

--- formatmbox.C.orig	Mon Apr  1 21:01:02 2002
+++ formatmbox.C	Mon Apr  1 21:01:12 2002
@@ -42,7 +42,7 @@ time_t	tm;
 
 	time(&tm);
 
-	tempbuf="\nFrom ";
+	tempbuf="From ";
 	tempbuf += maildrop.msginfo.fromname;
 	tempbuf += ' ';
 

[-- Attachment #3: dotlock.C.diff --]
[-- Type: text/plain, Size: 235 bytes --]

--- dotlock.C.orig	Tue Apr  2 01:57:49 2002
+++ dotlock.C	Tue Apr  2 01:58:58 2002
@@ -112,7 +112,7 @@ AlarmTimer	stat_timer;
 			}
 			else if (stat_timer.Expired())
 			{
-				unlink(lockfile);
+				// unlink(lockfile);
 			}
 		}
 

[-- Attachment #4: maildrop.log --]
[-- Type: text/plain, Size: 2458 bytes --]

  108  147643 [main] maildrop 1816 fhandler_disk_file::fstat_helper: 0 = fstat (, 0x22C808) st_atime=3CA962A0 st_size=26158, st_mode=0x8180, st_ino=1446857, sizeof=88
  109  147752 [main] maildrop 1816 fstat64: 0 = fstat (3, 0x22C808)
14988895 15136647 [win] maildrop 1816 wndproc 275 WM_TIMER 1 0
  291 15136938 [win] maildrop 1816 _kill: kill (1816, 14)
  242 15137180 [win] maildrop 1816 sig_send: pid 1816, signal 14, its_me 1
   99 15137279 [win] maildrop 1816 sig_send: Waiting for thiscomplete 0x12C
  273 15137552 [sig] maildrop 1816 wait_sig: awake
  134 15137686 [sig] maildrop 1816 wait_sig: processing signal 14
   99 15137785 [sig] maildrop 1816 wait_sig: Got signal 14
   99 15137884 [sig] maildrop 1816 sig_handle: signal 14
  126 15138010 [sig] maildrop 1816 sig_handle: signal 14, about to call 0x41FCF4
  104 15138114 [sig] maildrop 1816 setup_handler: suspending mainthread
  180 15138294 [sig] maildrop 1816 interruptible: pc 0x77F8318B, h 0x77F80000, interruptible 1, testvalid 1
  181 15138475 [sig] maildrop 1816 interruptible: pc 0x77F8318B, h 0x77F80000, interruptible 0, testvalid 0
  111 15138586 [sig] maildrop 1816 setup_handler: couldn't send signal 14
  100 15138686 [sig] maildrop 1816 setup_handler: ResumeThread returned 1
  104 15138790 [sig] maildrop 1816 setup_handler: returning 0
   96 15138886 [sig] maildrop 1816 sig_handle: returning 0
  109 15138995 [win] maildrop 1816 sig_send: returning 0 from sending signal 14
   94 15139089 [win] maildrop 1816 kill_worker: 0 = kill_worker (1816, 14)
  108 15139197 [sig] maildrop 1816 wait_sig: looping
  103 15139300 [sig] maildrop 1816 wait_sig: awake
  103 15139403 [sig] maildrop 1816 wait_sig: processing signal 14
   95 15139498 [sig] maildrop 1816 wait_sig: Got signal 14
   93 15139591 [sig] maildrop 1816 sig_handle: signal 14
   95 15139686 [sig] maildrop 1816 sig_handle: signal 14, about to call 0x41FCF4
   96 15139782 [sig] maildrop 1816 setup_handler: suspending mainthread
  149 15139931 [sig] maildrop 1816 interruptible: pc 0x77F8318B, h 0x77F80000, interruptible 1, testvalid 1
  153 15140084 [sig] maildrop 1816 interruptible: pc 0x77F8318B, h 0x77F80000, interruptible 0, testvalid 0
  105 15140189 [sig] maildrop 1816 setup_handler: couldn't send signal 14
   99 15140288 [sig] maildrop 1816 setup_handler: ResumeThread returned 1
   95 15140383 [sig] maildrop 1816 setup_handler: returning 0
   94 15140477 [sig] maildrop 1816 sig_handle: returning 0


[-- Attachment #5: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwin maildrop patches and issues (was Re: fetchmail 5.9.8 ...)

[Rui Carmo]

Hello Jason.

Nice to hear from you, and exceedingly nice to see that you stuck to 
maildrop. I  reverted to IMAP/SSL to read my mail for a good while 
(since I changed offices and my network connectivity improved 
considerably), and have had little reason to look into the problems in 
more detail.

I have since made a rather dramatic move to the Mac OS X platform (at 
least at home), so that also made a difference... :) But I (and most of 
my team) are still using Cygwin as the cornerstone of our work 
environment, so I'm still paying attention (it's just stuff like this - 
the non-critical work bits) that get put aside for a while.

What you mention is true: maildrop is closely associated with maildirs 
(and it was due to one of my colleagues, who swears by maildir on any 
OS, that I came accross it). I intended to use mutt with maildirs, 
including a shared mail archive we keep, but did not get around to it.

Nevertheless, I'll give your patches a look on my PC. :) Thanks a lot. :)
Will you submit them to the maintainers?

R.

On Friday, April 19, 2002, at 06:48 PM, Jason Tishler wrote:

> Rui,
>
> On Sat, Mar 02, 2002 at 12:45:12AM +0000, Rui Carmo wrote:
>> However, mutt then complains that /var/spool/mail/user is not a valid
>> mbox file, since somewhere along the line, an extra blank line is 
>> inserted
>> at the beginning of the mailbox upon creation. Editing it out by hand
>> solves the problem, but is a rather lame fix.
>
> The first attachment solves the above problem.
>
> Unfortunately, I have discovered other problems:
>
> 1. maildrop appears (at least under Cygwin) to not quite respect
> dotlocking and actually removes the lock file created by other
> processes!  The second attachment "solves" this problem.
>
> 2. maildrop appears to lock in a different order (i.e., dotlock then
> fcntl()) than mutt (and procmail) (i.e., fcntl() then dotlock) so I'm
> concerned about race conditions.
>
> 3. maildrop causes Cygwin to spin while another process has locked a 
> mbox
> via fcntl(F_SETLK).  If interested, see the third attachment for 
> details.
>
> I'm interested in getting Cygwin maildrop to work because it is much
> easier to build (and maintain) than procmail.  Unfortunately, I'm 
> getting
> the impression that maildrop is used more for maildirs than for 
> mboxes...
>
> Thanks,
> Jason
>




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwin maildrop patches and issues (was Re: fetchmail 5.9.8 ...)

[Jason Tishler]

Rui,

[Sorry, for the sluggish response time...]

On Fri, Apr 19, 2002 at 09:56:58PM +0100, Rui Carmo wrote:
> Nice to hear from you, and exceedingly nice to see that you stuck to 
> maildrop.

Thanks.

> What you mention is true: maildrop is closely associated with maildirs 
> (and it was due to one of my colleagues, who swears by maildir on any 
> OS, that I came accross it). I intended to use mutt with maildirs, 
> including a shared mail archive we keep, but did not get around to it.

I tried Cygwin mutt 1.3.24 with maildirs and it did not seem to like the
ones generated by maildrop.  If it did, this would "solve" (OK workaround)
any locking problems.

Has anyone had success with mutt and maildirs?

> Nevertheless, I'll give your patches a look on my PC. :) Thanks a lot. :)

You very are welcome.

> Will you submit them to the maintainers?

Possibly the first one, but most likely not the second (it's a hack).
Actually, I would not go upstream until I have things working much better
than they are now.

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Cygwin maildrop patches and issues (was Re: fetchmail 5.9.8 ...)

[Gary R. Van Sickle]

> > What you mention is true: maildrop is closely associated with maildirs
> > (and it was due to one of my colleagues, who swears by maildir on any
> > OS, that I came accross it). I intended to use mutt with maildirs,
> > including a shared mail archive we keep, but did not get around to it.
>
> I tried Cygwin mutt 1.3.24 with maildirs and it did not seem to like the
> ones generated by maildrop.  If it did, this would "solve" (OK workaround)
> any locking problems.
>
> Has anyone had success with mutt and maildirs?
>

FWICT maildirs have some filename issues (illegal chars in the names) that
Windows chokes on.  I can get inboxes to work OK, but e.g. mutt puts ":"'s and
","'s in the filenames it tries to create in your "received" folder.  I do have
a build of 1.3.28 that works OK with its *own* inbox maildir.  Do you want the
EXE to try out?

--
Gary R. Van Sickle
Brewer.  Patriot.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Cygwin maildrop patches and issues (was Re: fetchmail 5.9.8 ...)

[Jason Tishler]

Gary,

On Thu, Apr 25, 2002 at 11:45:45PM -0500, Gary R. Van Sickle wrote:
> > Has anyone had success with mutt and maildirs?
> >
> 
> FWICT maildirs have some filename issues (illegal chars in the names) that
> Windows chokes on.  I can get inboxes to work OK, but e.g. mutt puts ":"'s
> and ","'s in the filenames it tries to create in your "received" folder.
> I do have a build of 1.3.28 that works OK with its *own* inbox maildir.
> Do you want the EXE to try out?

No, because I need it to work when my MDA creates the maildirs and not
just when mutt creates them.

Thanks,
Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/