I can confirm that Dovecot 1.2 (I started with 0.9 back in the day and just
didn't yet upgrade to 2.x) works fine under NetBSD.
> I'm still thinking this has more to do with your system than anything in
> Dovecot.
Yes. We were finally able to reliably reproduce this.
It looks like a strange bug in NetBSD's NFS: If you are over quota and write a
small amount (probably less tha an NFS block) of data, the write() call will
s
Sounds like a reasonable idea, but one has to keep in mind that file system
quotas never work that way. So that change would make quota=fs behave
differently from the rest. So it should at least be configurable, I think.
Is there, among the dovocot community, any preferred LDAP schema and attribute
to use for setting the home/mail storage location?
Some people seem to use the qmail schema, some a Jamm schema (whatever that
is), and Markus Effinger has even created a dovecot schema
(https://www.effinger.org/blog
> The "mail" field defaults to mail_location setting.
Ah, yes, thanks. So simple I didn't think of it.
Will it default when the LDAP attribute is not present or will I have to check
the attribute's presence in the LDAP filter?
With 1.2, is there a syntax to, for LDAP lookups, use a given fixed replacement
for a non-present LDAP attribute?
E.g. something that would extend
user_attrs = mailFileServer=mail=maildir:/import/mail/%$/%d
to use maildir:/import/mail/foo/%d in case the mailFileServer attribute is not
pre
> But that requires Dovecot v2.1.
I was refering to
http://wiki1.dovecot.org/VirtualUsers/Home
which, to my understanding, should apply to 1.2.
I don't understand the Example at the bottom:
> LDAP with relative directory paths
>
> If your LDAP database uses e.g. mailDirectory = domain/user
> Mail/Sieve dirs can be relative to home dir, not vice versa.
OK, thanks.
> Yeah, that would probably work.
I'll try that.
> Maybe look into changing your directory hierarchy so mails are under home.
Too late. Also, as directories corresponding to IMAP folders always start with
a dot, it appear
> With 1.2, is it possible to specify home, sieve and sieve_dir relative to
> mail_location?
No-one, this one?
Too simple? Too stupid? Too obvious? Not possible?
With 1.2, is it possible to specify home, sieve and sieve_dir relative to
mail_location?
I have
mail_location =
maildir:/import/mail/%n/:INDEX=/var/db/dovecot/indexes/%n
and, in the plugin section,
home = /import/mail/%n/home
sieve = /import/mail/%n/dovecot.sieve
I have the following for 1.2. You may search the list archive, I asked that
question about halv a year ago and Timo answererd it for both 1.2 and 2.0.
auth default {
[...]
# Master-Benutzer für Sieve.
# Wirkt nur für Sieve, weil es master.imap und master.pop nicht gibt.
passdb passwd-file {
> You don't have any Thunderbird clients accessing this box do you?
Yes, I have. But I also experienced the problem myself only using mutt and
Apple Mail.
> I have some w[ei]rd issue where our TB with the option
> "don't mark message read", still triggers messages to be marked read
It's the othe
> That shouldn't happen because of Dovecot's indexes.
Hm, also if the indexes are local? Fine.
> Then the 'S' flag is added to the current Maildir filename without
> losing any other changes.
And this is supposed to work even over NFS? Great.
So, what can I do to track down the problem as, accord
We have two dovecot 1.2 instances sharing Maildirs on NFS. Indexes are local to
the individual servers.
Occasionally (no idea how to trigger this), the Seen flag gets lost on some
messages. I've verified that actually the ``S'' is missing from the filename.
I suspect something like server A cachi
> You are welcome to login to this box and spot the difference to Linux
Could this be a problem similar to that mentioned in
http://mail-index.NetBSD.org/tech-pkg/2011/09/05/msg007628.html and its
follow-ups?
> Another possibility would be to use %s, e.g.:
>
> passdb {
> driver = passwd-file
> master = yes
> args = /etc/dovecot/master.%s
> }
>
> Then use master.sieve file.
I guess that should read
passdb passwd-file {
master = yes
args = .../master.%s
}
instead. Thanks, seems to work great
> In v2.0 I believe it's possible to do:
Thanks. I guess it's impossible with 1.2 to have master access for sieve only
and not for IMAP?
Is there a method for using master credentials for sieve only? We sometimes
need to install/edit sieve script for some of our users. Currently, we just
edit the files on the file server, but that doesn't appear the most sensible
way for me
> and gives any user logging in a canned mail
> (e.g. "We're doing maintenance, go away")
Wouldn't a client that keeps local copies of all IMAP boxes then synchronize to
that canned state, i.e., delete all locally cached mails?
> Yes. Sieve uses the same functions for saving mails as the rest of
> Dovecot.
It happened again, so I have more input:
I have several of these:
Oct 9 00:41:22 xxx dovecot: deliver(xx):
fdatasync(/import/mail/xx/dovecot-uidlist) failed: Disc quota exceeded
Oct 9 00:41:22 xxx dovecot: d
> It would log an error and delete the tmp file.
Excellent. Does this also apply if sieve is involved?
> Even if close() fails, the file is still in tmp/ and Dovecot aborts the
> save.
I don't know whether the NFS server behaves that way (I would have to try out),
but how would dovecot's LDA behave if, for a small message, upon the write (to
tmp) the write() succeeds and the close() (which would a
What if you create the topmost mail directory (and everyting below) with setgid
set (or use BSD mkdir semantics)?
> Are your NFS Maildirs mounted on more than one server?
Yes.
> Check the list archive for "nfs director".
I do read the list.
> There has been a good bit of discussion about this recently.
As I recall, this is about index corruption. What we face is not index
corruption, but zero-length data fi
We are using Postfix as an MTA delivering via Dovecot's LDA (with sieve). We
also use Dovecot as a POP/IMAP server. Mail storage is Maildir on NFS, indexes
are stored locally. Quotas are FS quotas enforced by the NFS server. The
Dovecot version is 1.2.11.
Recently, for one user being over quota
> The NFS server sits in user space.
Oops? I don't know what Linux does, but with BSD, it has always been in-kernel.
> The file size isn't known beforehand.
I thought that because it's known to be >128k, it's known.
> Any thoughts?
Could the location be made dependant on the file size?
My usual setup is mfs on /tmp and ffs on /var/tmp, so /tmp being smaller and
faster and /var/tmp being larger and slower.
> This is a bashism. The script should begin #!/bin/bash, not #!/bin/sh.
Or rewrite it in plain sh:
l=""
for i in ${MAIL_PLUGINS}; do
case $i in
imap_quota|mail_log) ;;
*) l="$l $i";;
esac
done
MAIL_PLUGINS="${l# }"
> But it (-n) will deliver (rather than reject) into the regular INBOX
> if the folder for the extension does not exist?
Yes, but isn't that what you were asking for?
> I wonder if that ${EXTENSION} works in master.cf.
No. In master.cf, its ${extension}.
With Postfix, I use
mailbox_command = DOVECOT_LDA -n -e -m "${EXTENSION}"
where DOVECOT_LDA is the path do dovecot's deliver. The -n switch prevents
creation of the IMAP folder.
See http://wiki.dovecot.org/LDA
B> Group always is "wheel". Autocreating ignores gid from DB and uses the
B> group of the parent directory - in this case /var/mail.
TSS> Does /var/mail directory have setgid bit enabled? See if chmod
TSS> g-s /var/mail helps.
For the record: BSD always inherits the group from the parent directory
> Does somebody use this Perl library?
I use Mario Domgörgen's excellent App::Siesh which builds on Net::ManageSieve.
I must admit getting somewhat tired of this discussion, but I simply don't want
people investigating the original problem being distracted.
EF> I'm a bit surprised by this. Which "discussion group"?
DA> The RFC, one for NFSv4.0
Oh, you mean you posted to n...@ietf.org? Oh yes,
http://www.nfsv4.o
doveegg? dove_egg?
> These web servers also use the nullfs mount which is actually a NFS
> mount via the host machine to get the content that it serves to the
> reverse proxy.
But Web servers usually don't delete or rename files, do they?
> I was part of the discussion group for NFSv4 spec
> the short comings of v2 and v3 have been fixed
I'm a bit surprised by this. Which "discussion group"?
> NFSD (v2/v3) is stateless other than the information provided by
> mountd (mount requests) and lockd (file locking).
NFS is stateless save t
> Each one is over 2MB in size, and all of those imap processes share close
> to 2MB of memory pages that are identical, because the code is identical.
You may wish to learn how shared text works, I guess. Or do I miss something?
Did the Penguins do away with shared text?
> To fix (well work around) a security issue, for about 10+ years now,
> when a NFS server reboots, it generates a new random handle for the
> NFS Share. (sever may generate a new random handle per mount
> request)
I don't concur.
NFS is stateless and designed to survive server reboots (why would
> No, commit actually. create() is asynchronous.
Silly me.
> I mean it's going to use fcntl() or whatever OS locking (as opposed
> to some slow remote locking with remote storages).
But fcntl() will use NLM if the file is on NFS.
> I tried a few Google searches first, but I didn't then find anyth
> handle = open(path, mode)
> - this function can't fail. it's executed asynchronously.
Does that mean you can successfully open("/nonexistent", mode); write() to it
over and over again and only the commit() fails?
> handle = create(path, mode, permissions)
[...]
> - mode=fail-if-exists: commit
> Most curious.
Hm, I had two servers NFS-sharing mail data (and, in turn, dovecot.sieve*). One
was at 1.2.3 and a sieve not supporting the date extension, the other one was
at 1.2.7nb1 (meaning 1.2.7 plus e47eb506eebd) and I was getting errors also on
that server. I updated the other one to 1.2
> What's going on? It's probably some totally stupid typo on my side.
Any comments on this? Anyone with a working date extension?
Probably I'm doing something stupidly wrong.
I have dovecot 1.2.7 and sieve 0.1.13.
I have a sieve script starting with
#
require ["vacation", "date", "relational"];
I get
main_script: line 2: error: require command: unknown Sieve capability 'date'.
Just to make sure I haven't messed up the d
I would like deliver to reject certain users.
Since supposedly deliver only uses userdb, not passwd, I can't use deny=yes for
that. Or does userdb support deny=yes?
Yes, I should rather reject them right in the MTA, but that currently takes too
long to implement. Or how to reject gast* in postfi
We have users existing in LDAP but not supposed to receive mail.
We used to handle that (somewhat ungracefully) by simply not creating the top
mail directory for those accounts.
Since switching to Dovecots LDA, these non-existing dirs are considered
temporary failures and so the junk mails pile u
> I'm interested to find out what it logs now
Nothing.
> and if there are any user-visible errors.
No.
It simply seems to work?!
I've still disabled the 1.2.7 server and am only testing with my own account
(which triggered the error). I can re-enable the server for public use if that
helps.
I'm getting this Panic with some users on dovecot-1.2.7:
Panic: file maildir-uidlist.c: line 1242
(maildir_uidlist_records_drop_expunges): assertion failed: (recs[i]-
>uid < rec->
uid)
There's another dovecot-1.2.3 running on identical hardware accessing
the same NFS mail storage without p
> Could you test whether the following change fixes your problem?
Yes, thanks!
Without having looked into the code: Does Pigeonhole automatically compile a
sieve script if the compiled form is not /strictly/ newer than the text form?
I'm running into the problem that during automatic installation of a global
sieve-after script, my Makefile has a rule to compile, yet afterwa
newsyslog: illegal signal number in config file:
/var/log/dovecot.log root:wheel 0666 1 * $M1D0 CJ /var/run/
dovecot/master.pid USR1
I'm not sure about FreeBSD, but I think in NetBSD, that had to be
SIGUSR1, not USR1.
> touch foo
> tail -f foo&
> rm -f foo
> fg
>
> Does it complain about stale NFS handle?
On NetBSD, it doesn't complain.
I'm somewhat astonished that FreeBSD does complain. I thought those .nfsX
entries (which cover exactly this situation) were an original 4.4BSD invention.
> Success on NetBSD 5.0_STABLE on amd64 (64-bit).
Also on 3.1.0_PATCH/i386, 3.0.1/sparc and 4.0.1/{amd64,i386}
> See if this works:
>
> plugin {
> home = /blah/%u
> }
YES! Thanks!
Regarding your response time, sometimes I'm convinced that ,,Timo Sirainen'' is
really a pseudonym for a group of some ten people operating in 12-hour shifts,
half of whose keep hacking on dovecot around the clock while the
> If you're not giving -d parameter to deliver, it doesn't do userdb
> lookup at all.
Ouch! I seem to be not only blind, but stupid, too. Of course, what should it
look up otherwise!
However, I would still prefer an easier solution.
I just want deliver/Sieve. Sieve wants .dovecot.lda-dupes, ther
> I will send you that information in private mail.
OH NO! It seems to be entirely our fault.
After spending about an hour excerpting, editing and commenting the mail log
(Postfix->Dspam->Postfix->deliver/Sieve plus forward), and finally pasting the
Sieve script, I noticed there seems to be an e
> No, when delivery fails entirely, the deliver binary should give an
> appropriate exit code, indicating that the MTA needs to try again later
> or bounce the message.
OK, I would have expected that.
> What do the Dovecot and MTA logs say?
I will send you that information in private mail.
Is it defined whether, in case a message should be delivered to
multiple destinations via a sieve script, and one of those
destinations fail, then the whole delivery is to be considered as
successful or not?
My case:
A sieve script forwarding to and external destinations plus local keep.
Th
.., =home=/import/mail/%u/home
Unfortunately, the whole thing doesn't work.
I'm using Postfix with mailbox_command set to dovecot's deliver.
Now, Postfix seems to use nss to get the user's home dir and passes
this to mailbox_command as HOME.
It looks like deliver prefers the environment variabl
> .., =home=/import/mail/%u/home
Ah, using % Expansion works even if returned from an LDAP query? Great.
Is this == form documented somewhere? I mean, is
it documented that the LDAP Attribute is allowed to be empty?
Thanks.
> It doesn't matter if Dovecot's home directories are different from the
> users' primary home directories. It's probably even better if they're
> different.
Yes, I thought so.
> http://wiki.dovecot.org/VirtualUsers#homedirs should apply to your use
> case as well.
Yes, I read that one. But I coul
I'm somewhat confused regarding Home Directories needed by sieve and
setting them for an LDAP userdb.
We have system users, passdb ldap, userdb ldap, but home directories
are not mounted on the mail server.
Now apparently, sieve needs the home directory for .dovecot.lda-dupes.
Is there an
> What OpenSSL version do you have? I thought those compression functions
> were new enough that everyone would have them by now..
Same on NetBSD 3.1.0 (which admittedly is unsupported by now) with OpenSSL
0.9.7d. I can pull in a newer version from pkgsrc, of course.
> There is a way to add 'alternate names'
Subject Altenative Names.
> but I don't think TBird (or most other Clients) will recognize them.
The only client I know of NOT suporting subjectAltName is plain old pine.
You may have a try at imaps://imap.math.uni-bonn.de (or at
https://www.math.uni-bon
> http://dovecot.org/releases/1.2/dovecot-1.2.5.tar.gz
Does the ManageSieve patch for 1.2.4 work with 1.2.5?
> but I'm still not sure why it would happen and I can't reproduce it.
Hm.
> You didn't happen to get a core dump?
No, sorry. And I would not like to provoke the panic again.
> I'd really like to know what "p *file" and "p *file.buffer" says in gdb.
Sorry.
Any details of our installation that mi
I got the following panic on 1.2.3:
Panic: file mail-transaction-log-append.c: line 88 (log_buffer_move_to_memory):
assertion failed: (file->buffer_offset + file->buffer->used ==
file->sync_offset)
It's probably related to the file system holding the indexes being full.
I would suppose that partly overlapping rules are most often a sign of a
configuration error.
So how about
1) most specific rule wins (or last rule wins, forcing more specific rules to
appear further down the file)
2) partly overlapping flag an error, except for
3) using != (or whatever) instead
This is 1.2.3, but there are also two older dovecots (with different machine
architecture) sharing the mail store:
dovecot: IMAP(xxx): Panic: file mail-index-transaction-view.c: line 106
(tview_apply_flag_updates): assertion failed: (map->hdr.record_size <=
tview->record_size)
> [...] mv foo.tmp foo [...]
>
[...]
>
> So, apparently HFS+'s rename() isn't really atomic after all..
Are you sure OS X's mv(1) simply calls rename(2)? Maybe some magic in mv(1) for
._xxx resource forks or directory hardlinks?
The Wiki includes several comments about sieve_* variables which are not
mentioned in dovecot-example.conf, especially sieve_{before,after} and
sieve_extensions and sieve_subaddress_sep.
Could these be added to the commented config file?
> I'm using the Mercurial repository, see
> http://wiki.dovecot.org/ManageSieve#Mercurial
I guess this is not an option for pkgsrc.
> managesieve works fine for me on 1.2.0
How do you make that work?
$ tail +41 dovecot-1.2.0/src/imap-login/client.c | head -3
#if CLIENT_LOGIN_IDLE_TIMEOUT_MSECS < AUTH_REQUEST_TIMEOUT*1000
# error client idle timeout must be larger than authentication timeout
#endif
$ tail +47 dovecot-1.2-mana
Sorry to ask again, but what's the status of the ManageSieve patch for 1.2? The
rc5 version doesn't work and I would like to get 1.2 into pkgsrc.
The ManageSieve patch for rc5 applies to rc7, but doesn't build.
The problem is obvoiusly that dovecot-managesive/src/managesieve-login/client.c
tests:
#if CLIENT_LOGIN_IDLE_TIMEOUT_MSECS >= AUTH_REQUEST_TIMEOUT*1000
# error client idle timeout must be smaller than authentication timeout
#endif
I'm integrating Sieve (the new one) and ManageSieve into wip/dovecot.
Currently, this works as dovecot options because dovecot must be built before
sieve can be configured and sieve must be built before managesieve can be
configured/built.
Now, the question arose what the long-term solution (in
http://dovecot.org/patches/1.1/tcp-wrappers.patch should work.
I'll attach an updated version for 1.2. Remember to run auto
{conf,header,make} after applying.
tcp-wrappers.patch
Description: Binary data
> Dovecot assumes it's the only one changing the cur/ directory
Does this mean "there's no program that's not dovecot accesssing cur" or
"there's no other process than this dovecot accessing cur"?
I.e., what about two dovecots on two servers with Maildirs on NFS?
> What is pkgsrc?
A package system (see www.pkgsrc.org)
Originally the package system of NetBSD, but then ported to 13 other platforms,
Darwin being the second one. Extremly flexible, quarterly stable branches, 7300
packages.
It's really nice to have the same package system on my Macs and NetBS
> A couple of us are working on a macports project for dovecot, postfix,
> mysql, bind9 dlz etc... virtual everything.
pkgsrc has all of these.
> Also, the way we are building should easily move to bsd's and linux
> distros.
pkgsrc already does that (and even Solaris, Irix and HP-UX).
> I
I'm trying to integrate both the new sieve implementation and managesieve into
pkgsrc.
Managesieve seems to need some dovecot libraries that dovecot doesn't install
(lib-storage/libstorage.a, lib-auth/libauth.a, lib-imap/libimap.a,
lib-index/libindex.a, lib-mail/libmail.a, lib-charset/libcharse
> what I would like is to have email directed to user+...@example.com
> delivered to the IMAP folder foo
mailbox_command = /usr/libexec/dovecot/deliver -n -e -m "${EXTENSION}"
> Is there a simple robust IMAP client
Yes: mutt. One of the reasons we use mutt not only for regular mail access, but
for troubleshooting: it simply does what you tell it to do. It doesn't try to
be clever or try to do what it thinks you actually wanted to do.
Apart from that, it's scriptable an
> an imap process running at 100%, kill -9 was unable to kill it.
I'm no a Linux expert, but from a BSD perspective, that seems to contradict
each other. Either the process is doing an uninterruptable sleep or consumes
CPU time. As said, I'm not a Linux expert, but can you find out what state the
> If you can't kill a process with -9, the bug is in the kernel and
> there's nothing Dovecot can do about it. User spaces processes can't
> create unkillable processes unless something's broken.
It just means the process is doing an uninterruptable sleep (in BSD notation, a
tsleep() without PCATC
> Oh yes sorry, indeed ./configure generates dovecot-config.in from
> dovecot-config.in.in (been a while since I looked at this). Upon
> executing 'make' it is transformed into the definitive dovecot-config
> using the following make rule (Makefile.am in top Dovecot source dir):
Yes, after (p
> Dovecot needs to be compiled first for this to work.
Yes, of course.
> The dovecot-config file is produced upon executing ./configure.
Not with me. I get a dovecot-config.in generated from dovecot-config.in.in
during configure and a .../lib/dovecot/dovecot-config installed during install.
> Th
> Finally, after little more than a year, I finished the first release of
> the new Sieve implementation for Dovecot.
Great! I immediately tried to put this into pkgsrc, but ...
> The compilation procedure is identical to the cmusieve plugin
> (http://wiki.dovecot.org/LDA/Sieve).
I cannot see
> then I ran it with gmake LDFLAGS+=-lwrap and it worked
Looks like you forgot to run automake after patching in order to re-generate
the makefiles.
You may also wish to trim your quoted text before posting to the list.
Generated the configure script with autoconf.
Did you run autohader (and automake), too?
> After compiling and running it
Just to make sure: You did run autoconf/automake/autoheader before configuring?
Btw, I've updated the patch for 1.1.6, see attached file.
--- configure.in.orig 2008-06-22 13:02:27.0 +0200
+++ configure.in2008-07-23 15:05:00.0 +0200
@@ -61,6 +61,15 @@
notify=$withval,
notify=)
+AC_ARG_WITH(libwrap,
+[ --with-libwrap Build wi
> "Error: login_tcp_wrappers can't be used because Dovecot wasn't built with
> libwrap"
What does the configure script tell you about "tcpd.h usability" and "tcpd.h
presence"? What does config.log say about them?
Is there some simple textual frontend to the ManageSieve protocol somewhat
easier to use than gnutls-cli? I.e. something to use like
managesieve -u ef putscript myscript < /tmp/myscript
Password:
managesieve -u ef setactive myscript
Password:
simply doing the TLS authentication and length computat
> quota = fs:user:noenforcing
Thanks.
> I guess I should add all these extra parameters to the wiki page..
Yes, please.
I suppose CONTROL has to be shared by different dovecot instances so I can't
simply put them on local storage like INXEX, right?
> Dovecot doesn't try to enforce filesystem quota limits.
I'm admittedly feeling utterly stupid in trying to tell an author what his
programm is doing, but ...
> It just handles the EDQUOT error from write().
... I ktrace'd imap and there was no failing write(), only suspicious rpcs to
the file
Yes. I could spend more time testing this myself or examining the code.
It looks to me that, with fs quota, dovecot refuses to store a mail
(e.g. when the client moves a mail from one IMAP folder to another)
if the user is beyond his soft limit.
Is this correct/intended? Knowing nothing about
Try with manual IMAP commands instead:
Yes, sorry, I should have checked that before.
Does it return correct output?
Yes.
IIRC some clients (maybe Apple Mail?) had problems listing quota if
quota root was empty.
Hmpf. So I was just using a defective client to test my presumably
defective
I'm confident that the question has been asked before, but I can't
remember the answer.
I have
-- dovecot 1.1.2
-- Mail storage (maildir format) on NFS
-- Quotas on that file system
-- A working rquotad
-- mail_plugins = quota imap_quota in the protocol imap section
-- quota=fs in the plugin se
Is there a place to store unofficial patches to ManageSieve?
The attached patch is supposed to make ManageSieve (more precisely,
managesieve-login) co-operate with a libwrapped
(http://www.dovecot.org/patches/1.1/tcp-wrappers.patch) dovecot.
--- configure.in.orig 2008-07-01 20:17:21.0
1 - 100 of 116 matches
Mail list logo
