Re: locking mechanism

[Vincent Lefevre]

On 2020-05-12 12:38:52 -0700, Kevin J. McCarthy wrote:
> On Tue, May 12, 2020 at 02:43:44AM +0200, Vincent Lefevre wrote:
> >  * one should be able to specify the location of the dotlock program
> >at run time (so that non-root users could install a more recent
> >version of Mutt in their home directory);
> 
> I think you can already, by setting $dotlock_program.  (Assuming the
> external dotlock program is configured).

I think I may have been confused by the fact that at configure/build
time, Mutt insists on using its own. For instance, "make install"
fails with

chgrp: changing group of '/tmp/mutt-test/bin/mutt_dotlock': Operation not 
permitted
Can't fix mutt_dotlock's permissions!  This is required to lock mailboxes in 
the mail spool directory.

The error should not be fatal. I also think that in case of error, the
install rule should check whether a mutt_dotlock is already available
in the path with the right permissions; if it is available, the one
that has just been built (with insufficient permissions) should not be
installed.

> I guess you could disable the dotlock by setting $dotlock_program to
> "/bin/true".

If this works, it could be worth documenting.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: locking mechanism

[Kevin J. McCarthy]

On Tue, May 12, 2020 at 02:43:44AM +0200, Vincent Lefevre wrote:

Now, even if dotlocking isn't dropped, I don't think that it
should be mandatory. IMHO,


I'll look into this, but it should be no surprise that I'd prefer to 
make it "opt-out" rather than "opt-in".



 * one should be able to specify the location of the dotlock program
   at run time (so that non-root users could install a more recent
   version of Mutt in their home directory);


I think you can already, by setting $dotlock_program.  (Assuming the 
external dotlock program is configured).



 * one should be able to use dotlocking in an optional way, i.e.
   just as an additional security, in addition to fcntl: if there
   is no sufficient directory permission to create a lock file,
   then ignore dotlocking and just rely on fcntl (which should be
   fine for most users).


Right now, the code will first perform fcntl/flock and then *also* 
perform a dotlock.


I guess you could disable the dotlock by setting $dotlock_program to 
"/bin/true".


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: locking mechanism

[Steffen Nurpmeso]

Derek Martin wrote in
<20200512021313.ge20...@bladeshadow.org>:
 |On Mon, May 11, 2020 at 08:38:19PM +0200, Steffen Nurpmeso wrote:
 |> Vincent Lefevre wrote in
 |> <20200510204809.ga71...@zira.vinc17.org>:
 |>|Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
 |>|dotlocking still used nowadays?
 |> 
 |> I find yes.  Or at least last i looked, some MTAs aka MDA or
 |> whatever the right name is (LDA?  postfix
 |> (configurable), i think OpenBSDs mail.local (which saw heavy
 |> modifications lately though)) create these files, and then i think
 |> it seems sensible to embed in this locking strategy.
 |
 |IIRC most of the MDAs support multiple locking mechanisms, and at
 |least some of them use multiple mechanism simultaneously.  But dot
 |locking is slow, which probably doesn't matter on your home e-mail
 |server, but would matter on a mail server that handles millions of
 |messages a day...  And it may still be unreliable, depending on the

Minus that dotlocking applies to local MBOX delivery only.  And
minus comparison to the quite complicated local delivery pipe
chains that many of you seem to use.  And also minus the very long
backing store synchronizations that many use, the dotlock file may
even never reach backing store.
That reminds me that the mailer i maintain does not use fsync() on
mailboxes, also something i never thought could happen in real
life.

 |exact mix of things you have.  If you have one mechanism that's known
 |to work reliably across your whole mail system, you should use that,
 |and hope that it's not dot locking.
 |
 |>|Let's recall that dotlocking alone is not safe with some file systems,
 |>|such as NFS, since even if the client has an exclusive access to the
 |>|mailbox file, there is no guarantee that the synchronization will be
 |>|done before another program accesses the mailbox. In short, a working
 |>|fcntl locking is needed. But if it is available, then dotlocking is
 |>|useless. So, IMHO, if still supported, dotlocking should just be seen
 |>|as a fallback, and if mutt_dotlock cannot be installed with the right
 |>|permissions, the installation of Mutt should not fail.
 |> 
 |> I do not think so.  fcntl is "the new way"
 |
 |I don't think anything that's been available for > 20 years in the
 |world of computing can be considered "new" anymore... =8^)
 |
 |> and used anyway (for my MUA), but embedding into the scheme used by
 |> others is crucial, and as long as they use dotlock files for
 |> synchronization i will use it.
 |
 |All MDAs that are still supported use POSIX locking.  So dot locking
 |is superfluous and only slows you down.
 |
 |But let's not also forget that NFS is not the only problem.  There are
 |a wide array of file systems, and you can't be sure they implement
 |your favorite locking mechanism.   But, t's more likely that if POSIX
 |locking doesn't work on those, since it's one call and its interface
 |expects that it might not be implemented everywhere, you'll likely
 |just get EINVAL back, whereas a dot lock might be more likely to fail
 |silently (as it did under Linux).
 |
 |> NFS locking is "now" ok i have heard (here "now" is maybe almost two
 |> decades),
 |
 |That depends on what you mean:
 |
 |If you're on Linux, and:
 |
 |  - If you mean POSIX locking, yes.  It's worked reliably since at
 |least as far back as 2.4, and I believe earlier. (There was a
 |really old bug in lockd that broke it, but that's been fixed for
 |about 20 years or something)...  AFAIK there have been no reported
 |bugs with it since.
 |
 |  - If you mean dot locking...  In Linux it's been "OK" since 2.6.5,
 |if all of your clients and server are running Linux and NFSv3 or
 |greater.  Maybe. :)
 |
 |If you mean NOT Linux, or you have a mix of things...  file locking
 |over NFS is a horror show, in general, and if your environment is not
 |100% homogenous all bets are off.  There have been various bugs in the
 |NFS and/or locking implementations of pretty much every platform ever,
 |and they don't generally interoperate well.
 |
 |If you have NFS in the picture, and your site isn't 100% homogenous,
 |you'd better know exactly what's supported reliably by all of them,
 |and it's pretty much guaranteed to be POSIX locking, by now--it's kind
 |of the point of POSIX.  Otherwise, you may as well assume data
 |corruption is guaranteed.  Better to avoid accessing your mail spool
 |over NFS, or use Maildir.
 |
 |I'm not sure that it makes sense to remove dot locking from Mutt
 |entirely, but it probably does make sense to turn it off unless
 |explicitly requested.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: locking mechanism

[Steffen Nurpmeso]

Vincent Lefevre wrote in
<20200512004344.ga175...@zira.vinc17.org>:
 |On 2020-05-11 20:38:19 +0200, Steffen Nurpmeso wrote:
 |> Vincent Lefevre wrote in
 |> <20200510204809.ga71...@zira.vinc17.org>:
 |>|Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
 |>|dotlocking still used nowadays?
 |> 
 |> I find yes.  Or at least last i looked, some MTAs aka MDA or
 |> whatever the right name is (LDA?  postfix
 |> (configurable), i think OpenBSDs mail.local (which saw heavy
 |> modifications lately though)) create these files,
 |
 |OK, but it seems that all of them support fcntl locking. Under Debian,
 |procmail, postfix and exim seem to use both by default. Concerning
 |procmail, it is provided with a setgid /usr/bin/lockfile. For postfix,
 |its documentation says:
 |
 |  Note: The dotlock method requires that the recipient UID or GID has |  
write access to the parent directory of the mailbox file.
 |
 |So it seems that dotlocking does not always work.

Well, for my MUA i propagated a >2 decade old piece of code to
a different and standalone context, made it SETUID, and happily
introduced a local root CVE.  That is doable.

 |> and then i think it seems sensible to embed in this locking
 |> strategy. That is what i use for my MUA, though on OpenBSD, MacOS
 |> and some others (Fedora at least) OPT_DOTLOCK is disabled, and on
 |> Debian the maintainer has made the dotlock helper a SETGID instead
 |> of a SETUID program, which should be enough for the plain Debian
 |> mailspool, however.
 |
 |Yes, because the group can write into it:
 |
 |drwxrwsr-x 2 root mail 4096 2020-05-10 22:22:08 /var/mail/
 |
 |Now, even if dotlocking isn't dropped, I don't think that it
 |should be mandatory. IMHO,
 |  * one should be able to specify the location of the dotlock program
 |at run time (so that non-root users could install a more recent
 |version of Mutt in their home directory);

A real problem.

  #?0|kent:src$ ll /usr/local/libexec/s-nail-dotlock
  -r-sr-xr-x 1 root users 50520 Aug 18  2019 /usr/local/libexec/s-nail-dotlock*
  #?0|kent:src$ ll /usr/local/bin/s-nail
  -rwxr-xr-x 1 steffen steffen 4883544 Apr 26 03:01 /usr/local/bin/s-nail*

 |  * one should be able to use dotlocking in an optional way, i.e.
 |just as an additional security, in addition to fcntl: if there
 |is no sufficient directory permission to create a lock file,
 |then ignore dotlocking and just rely on fcntl (which should be
 |fine for most users).

I mean fcntl is more than enough, sure.  It is just that i think
(my MUA allows setting "dotlock-disable") that if you live on
a system where your local MDA uses fcntl+dotlock then you should
embed in fcntl+dotlock.  The situation as you find it on multiple
systems is that the MDA is configured to use dotlock by default
(like i said, postfix release does by default unless my memory
fools me, OpenBSD mail.local also did i think), but user software,
and if only through packager decisions, just does not care.  Too
many captains, too few soldiers, maybe.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: locking mechanism

[Derek Martin]

On Mon, May 11, 2020 at 08:38:19PM +0200, Steffen Nurpmeso wrote:
> Vincent Lefevre wrote in
> <20200510204809.ga71...@zira.vinc17.org>:
>  |Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
>  |dotlocking still used nowadays?
> 
> I find yes.  Or at least last i looked, some MTAs aka MDA or
> whatever the right name is (LDA?  postfix
> (configurable), i think OpenBSDs mail.local (which saw heavy
> modifications lately though)) create these files, and then i think
> it seems sensible to embed in this locking strategy.

IIRC most of the MDAs support multiple locking mechanisms, and at
least some of them use multiple mechanism simultaneously.  But dot
locking is slow, which probably doesn't matter on your home e-mail
server, but would matter on a mail server that handles millions of
messages a day...  And it may still be unreliable, depending on the
exact mix of things you have.  If you have one mechanism that's known
to work reliably across your whole mail system, you should use that,
and hope that it's not dot locking.

>  |Let's recall that dotlocking alone is not safe with some file systems,
>  |such as NFS, since even if the client has an exclusive access to the
>  |mailbox file, there is no guarantee that the synchronization will be
>  |done before another program accesses the mailbox. In short, a working
>  |fcntl locking is needed. But if it is available, then dotlocking is
>  |useless. So, IMHO, if still supported, dotlocking should just be seen
>  |as a fallback, and if mutt_dotlock cannot be installed with the right
>  |permissions, the installation of Mutt should not fail.
> 
> I do not think so.  fcntl is "the new way"

I don't think anything that's been available for > 20 years in the
world of computing can be considered "new" anymore... =8^)

> and used anyway (for my MUA), but embedding into the scheme used by
> others is crucial, and as long as they use dotlock files for
> synchronization i will use it.

All MDAs that are still supported use POSIX locking.  So dot locking
is superfluous and only slows you down.

But let's not also forget that NFS is not the only problem.  There are
a wide array of file systems, and you can't be sure they implement
your favorite locking mechanism.   But, t's more likely that if POSIX
locking doesn't work on those, since it's one call and its interface
expects that it might not be implemented everywhere, you'll likely
just get EINVAL back, whereas a dot lock might be more likely to fail
silently (as it did under Linux).

> NFS locking is "now" ok i have heard (here "now" is maybe almost two
> decades),

That depends on what you mean:

If you're on Linux, and:

  - If you mean POSIX locking, yes.  It's worked reliably since at
least as far back as 2.4, and I believe earlier. (There was a
really old bug in lockd that broke it, but that's been fixed for
about 20 years or something)...  AFAIK there have been no reported
bugs with it since.

  - If you mean dot locking...  In Linux it's been "OK" since 2.6.5,
if all of your clients and server are running Linux and NFSv3 or
greater.  Maybe. :)

If you mean NOT Linux, or you have a mix of things...  file locking
over NFS is a horror show, in general, and if your environment is not
100% homogenous all bets are off.  There have been various bugs in the
NFS and/or locking implementations of pretty much every platform ever,
and they don't generally interoperate well.

If you have NFS in the picture, and your site isn't 100% homogenous,
you'd better know exactly what's supported reliably by all of them,
and it's pretty much guaranteed to be POSIX locking, by now--it's kind
of the point of POSIX.  Otherwise, you may as well assume data
corruption is guaranteed.  Better to avoid accessing your mail spool
over NFS, or use Maildir.

I'm not sure that it makes sense to remove dot locking from Mutt
entirely, but it probably does make sense to turn it off unless
explicitly requested.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: locking mechanism

[Vincent Lefevre]

On 2020-05-11 20:38:19 +0200, Steffen Nurpmeso wrote:
> Vincent Lefevre wrote in
> <20200510204809.ga71...@zira.vinc17.org>:
>  |Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
>  |dotlocking still used nowadays?
> 
> I find yes.  Or at least last i looked, some MTAs aka MDA or
> whatever the right name is (LDA?  postfix
> (configurable), i think OpenBSDs mail.local (which saw heavy
> modifications lately though)) create these files,

OK, but it seems that all of them support fcntl locking. Under Debian,
procmail, postfix and exim seem to use both by default. Concerning
procmail, it is provided with a setgid /usr/bin/lockfile. For postfix,
its documentation says:

  Note: The dotlock method requires that the recipient UID or GID has
  write access to the parent directory of the mailbox file.

So it seems that dotlocking does not always work.

> and then i think it seems sensible to embed in this locking
> strategy. That is what i use for my MUA, though on OpenBSD, MacOS
> and some others (Fedora at least) OPT_DOTLOCK is disabled, and on
> Debian the maintainer has made the dotlock helper a SETGID instead
> of a SETUID program, which should be enough for the plain Debian
> mailspool, however.

Yes, because the group can write into it:

drwxrwsr-x 2 root mail 4096 2020-05-10 22:22:08 /var/mail/

Now, even if dotlocking isn't dropped, I don't think that it
should be mandatory. IMHO,
  * one should be able to specify the location of the dotlock program
at run time (so that non-root users could install a more recent
version of Mutt in their home directory);
  * one should be able to use dotlocking in an optional way, i.e.
just as an additional security, in addition to fcntl: if there
is no sufficient directory permission to create a lock file,
then ignore dotlocking and just rely on fcntl (which should be
fine for most users).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: locking mechanism

[Steffen Nurpmeso]

Vincent Lefevre wrote in
<20200510204809.ga71...@zira.vinc17.org>:
 |Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
 |dotlocking still used nowadays?

I find yes.  Or at least last i looked, some MTAs aka MDA or
whatever the right name is (LDA?  postfix
(configurable), i think OpenBSDs mail.local (which saw heavy
modifications lately though)) create these files, and then i think
it seems sensible to embed in this locking strategy.  That is what
i use for my MUA, though on OpenBSD, MacOS and some others
(Fedora at least) OPT_DOTLOCK is disabled, and on Debian the
maintainer has made the dotlock helper a SETGID instead of
a SETUID program, which should be enough for the plain Debian
mailspool, however.

 |Even if it is, I find annoying that for an end user who probably
 |won't need it, Mutt's installation will fail if he does not provide
 |the --with-homespool option.
 |
 |Let's recall that dotlocking alone is not safe with some file systems,
 |such as NFS, since even if the client has an exclusive access to the
 |mailbox file, there is no guarantee that the synchronization will be
 |done before another program accesses the mailbox. In short, a working
 |fcntl locking is needed. But if it is available, then dotlocking is
 |useless. So, IMHO, if still supported, dotlocking should just be seen
 |as a fallback, and if mutt_dotlock cannot be installed with the right
 |permissions, the installation of Mutt should not fail.

I do not think so.  fcntl is "the new way" and used anyway (for my
MUA), but embedding into the scheme used by others is crucial, and
as long as they use dotlock files for synchronization i will use
it.  NFS locking is "now" ok i have heard (here "now" is maybe
almost two decades), but i got a lot of test errors on the OpenCSW
cluster i have access to in the last year or so, because the NFS
creates a hidden file for each file it creates (links), maybe, but
anyway the rm(1) we do on the test file is not reflected fast
enough for the hidden (dot) file, i got "wrong link count"
failures there.  That is, bugs are everywhere.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: locking mechanism

[Vincent Lefevre]

On 2020-05-11 00:31:43 +0200, Moritz Barsnick wrote:
> Haha, I still have one message in that thread from 15 years ago marked
> as "unread". It was one of the first threads after I subscribed to this
> list. I stumbled back upon it while checking since when Redhat had
> patched mutt's dotlocking away in their packages (which I pointed out
> in that thread).
> 
> https://marc.info/?l=mutt-dev=111443331622131=2

And I'm still using Tamotsu Takahashi's sysdotlock patch,
which I modified each time this was needed. Attached.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff --git a/Makefile.am b/Makefile.am
index 9045b70a..d1c7d9a8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -52,7 +52,7 @@ mutt_DEPENDENCIES = $(MUTT_LIB_OBJECTS) $(LIBOBJS) 
$(LIBIMAPDEPS) \
$(INTLDEPS) $(LIBAUTOCRYPTDEPS)
 
 DEFS=-DPKGDATADIR=\"$(pkgdatadir)\" -DSYSCONFDIR=\"$(sysconfdir)\" \
-   -DBINDIR=\"$(bindir)\" -DMUTTLOCALEDIR=\"$(datadir)/locale\" \
+   -DDOTLOCK_PATH=\"@DOTLOCK_PATH@\" -DMUTTLOCALEDIR=\"$(datadir)/locale\" 
\
-DHAVE_CONFIG_H=1
 
 AM_CPPFLAGS=-I. -I$(top_srcdir) $(IMAP_INCLUDES) $(AUTOCRYPT_INCLUDES) 
$(GPGME_CFLAGS) -Iintl
diff --git a/PATCHES b/PATCHES
index e69de29b..0fb89070 100644
--- a/PATCHES
+++ b/PATCHES
@@ -0,0 +1 @@
+patch-20200424.tamovl.sysdotlock.1
diff --git a/configure.ac b/configure.ac
index 7906ce35..312233dc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -631,8 +631,6 @@ else
 MUTT_LIB_OBJECTS="$MUTT_LIB_OBJECTS dotlock.o"
 fi
 
-AC_SUBST(DOTLOCK_TARGET)
-
 dnl autoconf <2.60 compatibility
 if test -z "$datarootdir"; then
   datarootdir='${prefix}/share'
@@ -657,8 +655,18 @@ else
 DOTLOCK_GROUP=''
 DOTLOCK_PERMISSION=755
 fi
+
+AC_ARG_WITH(system-dotlock, 
AS_HELP_STRING([--with-system-dotlock=PATH],[Specify where mutt_dotlock already 
exists]),
+[DOTLOCK_TARGET=''
+ DOTLOCK_GROUP=''
+ DOTLOCK_PERMISSION=755
+ DOTLOCK_PATH=$withval],
+[DOTLOCK_PATH=$bindir/mutt_dotlock])
+
+AC_SUBST(DOTLOCK_TARGET)
 AC_SUBST(DOTLOCK_GROUP)
 AC_SUBST(DOTLOCK_PERMISSION)
+AC_SUBST(DOTLOCK_PATH)
 
 AC_ARG_WITH(domain, AS_HELP_STRING([--with-domain=DOMAIN],[Specify your DNS 
domain name]),
 [if test $withval != yes; then
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 1cb21b64..315df052 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -12,7 +12,7 @@ if BUILD_DOC
 BUILD_DOC_TARGETS = stamp-doc-chunked manual.html manual.txt $(INFO_DOCFILES)
 endif
 
-DEFS = -DSYSCONFDIR=\"$(sysconfdir)\" -DBINDIR=\"$(bindir)\" -DHAVE_CONFIG_H=1
+DEFS = -DSYSCONFDIR=\"$(sysconfdir)\" -DBINDIR=\"$(bindir)\" 
-DDOTLOCK_PATH=\"@DOTLOCK_PATH@\" -DHAVE_CONFIG_H=1
 AM_CPPFLAGS = -I. -I.. -I$(includedir) -I$(top_srcdir)
 
 MAKEDOC_CPP = $(CPP) $(AM_CPPFLAGS) $(DEFS) $(CPPFLAGS) -D_MAKEDOC -C
diff --git a/init.h b/init.h
index 6cbc30a3..1b2446d3 100644
--- a/init.h
+++ b/init.h
@@ -896,7 +896,7 @@ struct option_t MuttVars[] = {
   ** filtered message is read from the standard output.
   */
 #if defined(DL_STANDALONE) && defined(USE_DOTLOCK)
-  { "dotlock_program",  DT_PATH, R_NONE, {.p=}, {.p=BINDIR 
"/mutt_dotlock"} },
+  { "dotlock_program",  DT_PATH, R_NONE, {.p=}, {.p=DOTLOCK_PATH} 
},
   /*
   ** .pp
   ** Contains the path of the \fCmutt_dotlock(8)\fP binary to be used by

Re: locking mechanism

[Moritz Barsnick]

On Sun, May 10, 2020 at 22:48:09 +0200, Vincent Lefevre wrote:
> Let's recall that dotlocking [...]

Haha, I still have one message in that thread from 15 years ago marked
as "unread". It was one of the first threads after I subscribed to this
list. I stumbled back upon it while checking since when Redhat had
patched mutt's dotlocking away in their packages (which I pointed out
in that thread).

https://marc.info/?l=mutt-dev=111443331622131=2

Funny how stuff comes full-circle once in a while.

Moritz

locking mechanism

[Vincent Lefevre]

Related to commit 7bd57bc3c24adf97f1f57bd6bb2fd18347f8cbbd, is
dotlocking still used nowadays?

Even if it is, I find annoying that for an end user who probably
won't need it, Mutt's installation will fail if he does not provide
the --with-homespool option.

Let's recall that dotlocking alone is not safe with some file systems,
such as NFS, since even if the client has an exclusive access to the
mailbox file, there is no guarantee that the synchronization will be
done before another program accesses the mailbox. In short, a working
fcntl locking is needed. But if it is available, then dotlocking is
useless. So, IMHO, if still supported, dotlocking should just be seen
as a fallback, and if mutt_dotlock cannot be installed with the right
permissions, the installation of Mutt should not fail.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)