Re: [Dovecot] Dovecot 2.0.rc3 Capability response
A.L.E.C a...@alec.pl writes: On 04.08.2010 12:25, Craig Whitmore wrote: Looking at the RFC.. and if dovecot is doing this then its going against the RFC and doing it wrong. As it says This listing of capabilities is not dependent upon connection state or user. http://tools.ietf.org/search/rfc1730#section-6.1.1 http://tools.ietf.org/search/rfc2060#section-6.1.1 Timo will know better. Just want to say, that this sentence has been removed in RFC3501. I agree this wording has quite explicitly been removed from RFC 3501. Maybe Timo can point to some explicit wording which I have been unable to find but my reading of various bits of RFC 3501 (which btw obsoletes 2060 which in turn obsoletes 1730, i.e. 3501 is _the_ reference) seems to suggest that doing a CAPABILITY (or the moral equivalent of recognizing a CAPABILITY response) after both STARTTLS and AUTHENTICATE is in fact necessary. I don't see why it would be important to add these CAPABILITY responses unless the expectation is that the CAPABILITY response is now different as a result of the STARTTLS, AUTHENTICATE or indeed LOGIN. The case seems clear for STARTTLS; you advertise only non-plaintext AUTH mechanisms and LOGINDISABLED initially and after successful STARTTLS you can advertise plaintext AUTH mechanisms and remove LOGINDISABLED. I must confess I am having trouble untangling the precise meaning of the text related to AUTHENTICATE though. For reference some selected text from RFC 3501: 6.2.1. STARTTLS Command [...] Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in- the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS. [...] 6.2.2. AUTHENTICATE Command [...] A server MAY include a CAPABILITY response code in the tagged OK response of a successful AUTHENTICATE command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. This should only be done if a security layer was not negotiated by the AUTHENTICATE command, because the tagged OK response as part of an AUTHENTICATE command is not protected by encryption/integrity checking. [SASL] requires the client to re-issue a CAPABILITY command in this case. [...] B. Changes from RFC 2060 [...] 77) Add optional CAPABILITY response code in the initial OK or PREAUTH. 78) Add note that server can send an untagged CAPABILITY command as part of the responses to AUTHENTICATE and LOGIN. 79) Remove statement about it being unnecessary to issue a CAPABILITY command more than once in a connection. That statement is no longer true. [...] 83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE command should only be done if a security layer was not negotiated. [...] 91) Change recommendation of optional automatic capabilities in LOGIN and AUTHENTICATE to use the CAPABILITY response code in the tagged OK. This is more interoperable than an unsolicited untagged CAPABILITY response.
Re: [Dovecot] SSL / TLS Problem
Leander S. leander.schae...@googlemail.com writes: server [~]# cat /etc/ssl/mail/mail.key -BEGIN RSA PRIVATE KEY- [...] Hmm, you have apparently posted your private key to a public maillist. You might want to generate a new key and cert.
Re: [Dovecot] [dovecot]
Rick Romero r...@havokmon.com writes:
Yeah.. procmail filter to modify the subject would satisfy me.
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [dovecot] $MATCH
}
I realise this is a late response on this thread and is probably overly
pedantic but RFC 2919 (List-Id) is clear about which bit of the List-ID:
header is actually the list-id. It's the bit in angle brackets:
The List-Id header MAY optionally include a description by including
it as a phrase [DRUMS] before the angle-bracketed list identifier.
[...]
For many MUAs the parsing of the List-Id header will simply consist of
extracting the list identifier from between the delimiting angle
brackets.
The syntax of the List-Id header follows:
list-id-header = List-ID: [phrase] list-id CRLF
So if you are going to do List-ID filtering I suggest doing it on the bit
in angle brackets not the phrase part as has been done in the procmail
recipe above. Thus in procmail:
:0 fhw
* ^List-Id:.*dovecot\.dovecot\.org
[...]
and in sieve:
if header :contains list-id dovecot.dovecot.org {
[...]
Re: [Dovecot] dovecot auth is case insensitive, but fs is sensitive :)
Noel Butler noel.but...@ausics.net writes: On Wed, 2009-08-19 at 01:41 -0400, Timo Sirainen wrote: Dovecot auth isn't case-insensitive. But MySQL is, and I guess you're using it? There are several different ways around it. Which is not a problem since most (all) MTA's normally treat user@ as case insensitive. But the username in the authentication db is completely independent of any localpart that might be used to deliver to a mailbox - access to which is authenticated by providing creds for that username. I don't see how the fact that MTAs may or may not consider localparts to be case-sensitive has any bearing on the case-sensitivity of usernames stored in the authentication database.
Re: [Dovecot] sieve rules processing
Stephan Bosch step...@rename-it.nl writes:
Yes, your second rule is an elsif, meaning that it is only executed when
the first if-condition is not 'true'. Since that first rule has a forced
true' result, the second rule is absolutely never executed. You script
should be:
require [fileinto,copy];
# rule:[redirect]
if true
{
redirect :copy al...@domain.com;
}
# rule:[Cron]
if header :contains Subject Cron
{
fileinto INBOX/Cron;
}
Note that the anyof() commands are only necessary when you have multiple
tests per if command. Also, I removed the envelope require, since it is
not used.
Out of interest is the conditional around
if true
{
redirect :copy al...@domain.com;
}
necessary? Does a plain inline
redirect :copy al...@domain.com;
not behave in exactly the same manner?
I'm afraid it's a while since I read RFC 5228 (Sieve) and I was unfamiliar
with RFC 3894 (:copy) but on scanning through them I can't see anything to
indicate that behaviour should differ inside and outside an if.
So I suppose my question is does redirect :copy have different behaviour
based on whether it is inline or inside an if?
Re: [Dovecot] POP3 flag updates
Timo Sirainen t...@iki.fi writes: Why does Dovecot add \Seen flag for mails that have been RETRed? Does anyone really want to use this feature? I can't remember why I implemented it originally, perhaps it was just because other servers do that too. I'm thinking about at least changing pop3_no_flag_updates=yes to be default. Doesn't it just keep things looking consistent for a user if they happen to be using both a POP3 client and an IMAP client? Sound implausible? Say for normal use they have a desktop configured that does POP3 (but doesn't DELE after RETR, obviously) but they are away from the desk and use a Web to Mail gateway which happens to be an IMAP client. It is presumably considered a nice feature that messages they last POPped show up as \Seen in the web interface and consequently stuff that has arrived since shows up as not \Seen. Maybe.
Re: [Dovecot] v3.0 architecture
Timo Sirainen t...@iki.fi writes: I do kind of like that idea, but I don't really se how it would be practical here, especially if high performance is wanted. I don't really see why a priori it would be any less performant than any other particular RPC mechanism. 1. I'm not implementing Dovecot to Plan9, so the filesystem would still have to be wrapped in some kind of a protocol. I suppose you could get them visible to filesystem using FUSE, but that would still be Linux-only. I probably didn't explain well enough. One doesn't need to be implementing for or on a Plan9 system and there's no need for there to be any involvement with the OS or kernel's notion of filesystem. 9P is a _wire_ protocol for expressing filesystem hierarchy and I/O on files and dirs within that filesystem. I would like to say think of it as NFS simplified but even that will, I suspect, for lots of people draw with it far too much irrelevant baggage. It is a perfectly tractable proposition to implement both 9P servers and clients, e.g. wmii [1], solely with the assistance of a userland library, e.g. libixp [2]. 2. Latency over network is pretty high, so a nice clean filesystem layout wouldn't probably be possible without sacrificing performance. And a non-clean layout probably would just make it horrible to use in all ways. Agreed, careful design of the layout is rather important. But, I suggest, it requires no more or less care than goes into the design of a more traditional RPC mechanism - how are errors signalled, can more than one RPC be in flight at any one time, how is data marshalling done, etc. Using a synthetic filesystem at least provides a layer of abstraction that might help. I don't claim it makes it easier - it just provides a layer in which some of these questions are already answered. It's an alternate way to factorise the problem. Actually I think even the current lib-storage API won't be low-enough latency. Most IMAP commands should be able to be done by sending a single request and then reading responses. Well, I'm not going to start coding this anytime soon. I'm afraid I am sufficiently unfamiliar with the lib-storage API to comment on how straightforwardly one might map it to a 9P-using world. Anyway, I'm still more concerned about how to implement the client side so that a single process can asynchronously process commands and handle multiple connections, without the code looking awful difficult to understand mess. I think it might be possible with C, but I'm not aware of any existing code that does it as cleanly as synchronous code looks like. Very valid concerns. I don't think I am able to offer further insight though :-( Please forgive me if I come across as overly evangelistic. I do not intend to. It is an area of personal interest to me and it felt like it mapped onto your problem nicely. Thanks for listening. Footnotes: [1] http://wmii.suckless.org/ [2] http://libs.suckless.org/libixp
Re: [Dovecot] v3.0 architecture
Timo Sirainen t...@iki.fi writes: The big problem is what the protocol should be. Use some existing RPC protocol? It should be something extensible so that a plugin in imap process can talk to a plugin in storage process, without the base processes knowing anything about the details (e.g. imap-quota plugin asking quota usage from storage's quota plugin). In any case the client side API should be asynchronous. That can make it annoyingly difficult to use though. Wonder if I could switch to erlang or something for the imap/pop3 processes :) I realise I'm coming a little late to this conversation. Various people have suggested various RPC mechanisms. Might I humbly suggest also looking at 9P (or 9P2000) the Plan9 filesystem protocol. [1] The general design philosophy in Plan9 is not to use an increasing number of application specific RPC mechanisms but instead to implement everything in a synthetic filesystem tree. The 9P protocol handles the basic operations required to navigate the filesystem tree and read/write to the files within. The semantics of RPC are then relegated to the specification for the layout of the filesystem and meaning assigned to reading or writing to files within that tree. This allows for extensibility (and incidently discoverability) - new features or plugins appear as a new file or directory hierarchy in the presented filesystem layout. As a concrete example the so called upas/fs [2] presents a view of a mailbox independent of the actual storage mechanism used for the data contained in the mailbox. From the manpage The mailbox itself becomes a directory under /mail/fs. Each message in the mailbox becomes a numbered directory in the mailbox directory, and each attachment becomes a numbered directory in the message directory. Since an attachment may itself be a mail message, this structure can recurse ad nauseam. See [2] for more details. I'm not suggesting this layout would be exactly right for the Dovecot storage protocol but it may provide a starting point. It's probably worth noting the irony, given this is a maillist about Dovecot, in that this approach almost obsoletes the need for an IMAP protocol in the first place (the upas/fs style layout as documented doesn't really provide sufficient support for server side search for example). Footnotes: [1] http://plan9.bell-labs.com/magic/man2html/5/0intro [2] http://plan9.bell-labs.com/magic/man2html/4/upasfs
Re: [Dovecot] Migration questions...
Richard Hobbs richard.ho...@crl.toshiba.co.uk writes: 19. Once everything is working perfectly, send an email to the entire company instructing them what to do after the outage and arrange an outage and do the following steps as soon as the outage begins: a. Unplug DMZ switch from firewall to make delivered mail wait at the sender. [...] i. Plug DMZ switch back into firewall and begin monitoring exim logs to check that mail is being delivered. If I'm not misunderstanding the steps between 19.a -- 19.i are going to be done while not network connected? I'd be slightly concerned that these steps may involve anything some that needs to do DNS lookups or the like at which point they may hit long(ish) timeouts or just fail completely.
Re: [Dovecot] v 1.1.13 / GSSAPI / Timeout waiting for handshake from auth server
Timo Sirainen t...@iki.fi writes: On Wed, 2009-03-25 at 15:31 +0100, Jahnke-Zumbusch, Dirk wrote: 1. I am puzzled about the credentials i...@my.host.name being obtained; shouldn't this be something like imap/my.host.n...@my.realm ? I don't know anything about Kerberos. I suspect the i...@my.host.name refers to the subject at the GSSAPI layer. This is certainly the form one would use in gss_import_name() in order to construct the name of the peer one might then subsequently use in a call to gss_init_sec_context() or, as in this case, gss_acquire_cred(). If the underlying mechanism in use by the GSSAPI layer is Kerberos then it will be translated to an appropriately named principal, such as imap/my.host.n...@my.realm, but that name will not in general be exposed above the GSSAPI layer. This anyway means that dovecot-auth process is hanging for over 30 seconds. Probably the obtaining credentials is taking for a long time. But why that is, I've no idea. Wild guess: maybe the underlying Kerberos libraries are attempting to canonicalise the host part by doing DNS lookups which are timing out as a result of a non-responsive DNS server?
Re: [Dovecot] Unable To Move IMAP Folder (Dovecot)
CW == Carlos Williams [EMAIL PROTECTED] writes: CW This folder shows up as a sub folder to his Inbox on his CW Thunderbird client and I tried using the cp command to move this CW over to my Maildir/ directory on the same server and when I launch CW Thunderbird, that folder is not visible for me. I made sure CW permissions are correct and even reloaded Dovecot. [...] CW Does anyone know what I am doing wrong? Maybe you need to subscribe to your new test folder from your Thunderbird session.
Re: [Dovecot] Sieve fileinto a subfolder fails
EK == Eduardo M KALINOWSKI [EMAIL PROTECTED] writes: EK Try fileinto Lists.NCCC, the . is the default folder EK separator. EK It should be possible to change it to a / with namespaces, but EK it would make a cosmetic change, and judging by other posts in the EK list, it seems to cause a lot more trouble than benefits. :-) Though I don't think this will work with 1.0 deliver since it doesn't understand namespaces. IMHO the sieve spec missed a trick in this respect. Given that there are many other places in sieve where a list of strings can be supplied as arguments it seems like it would be obvious that fileinfo [foo bar]; could carry the meaning of file into the bar subfolder of foo and just short circuit the what's the hierarchy separator? question. Maybe this was considered during the standardization process and rejected.
Re: [Dovecot] Allowing tilde at start of mailbox names [listescape-plugin.c]
AM == Adam McDougall [EMAIL PROTECTED] writes: AM I have been using it for a few weeks and it has been working well, AM but yesterday I noticed it also seems to be escaping the \ AM (backslash) character in folder names. listescape has to escape '\' so that applications of decode-encode and encode-decode are idempotent. If it did not do this a client that asked, for example, to create a folder called a\2eb (i.e. issues CREATE a\2eb) would be shown the folder as a.b by dovecot in a subsequent folder listing. AM This wouldn't be a problem except it breaks operation of folders AM that already had a \ in the name before the plugin was loaded. AM This isn't a huge problem for us but I want to figure out if I AM should special case migration of folder names containing a \ to be AM the new internal representation \5c or if the plugin should just AM deal with normal \'s in the foldernames properly. Yes, I think you need to rename folders that contained a '\' in the name before you started using listescape, but clearly you should not rename any folders that have subsequently been created by the listescape plugin that contain a '\'.
Re: [Dovecot] Not using . as separator?
GE == Grant Edwards [EMAIL PROTECTED] writes:
GE When using maildir storage, is there any way to use something
GE besides . as the folder separator?
Please note that the following relates to dovecot 1.0. I've not looked to
see if 1.1 behaves differently.
Yes you can use a namespace
namespace private {
# empty prefix indicates the default namespace
prefix =
inbox = yes
separator = /
}
However using just this dovecot will still not allow maildir mailbox names
to contain a '.'.
GE I like to use folder names that match people's e-mail addresses
GE (that's a default behavior in mutt), and . is a pretty popular
GE character in e-mail addresses. Ideally, I'd like to use /.
The (unofficial) listescape plugin
http://www.dovecot.org/patches/1.0/listescape-plugin.c
will allow maildir folder names to contain '.' (and '~' at the start
incidentally). Note however that this is only a good solution if you are
offering exclusively IMAP/POP3 access to the mailstore. If you are also
exposing mailboxes directly by a filesystem interface then standard
Maildir++ utilities are likely to get confused because a folder known to
the client as a.b will appear in the filesystem with a name of 'a\2eb'.
We have used this feature to migrate from a UW imapd based service to a
dovecot based service with (what I believe to be) no user visible
change. [1]
GE Is . allowed in mailbox names when using mbox storage?
Yes, I believe so.
Footnotes:
[1] Except that folders can now contain sub folders and messages.
Re: [Dovecot] Automatically subscribe to folder?
NS == Nikolay Shopik [EMAIL PROTECTED] writes: NS I forgot to add some MUA don't like be subscribed to folders which NS doesn't exist so you should probably aware of this too in case NS such MUA used in your environment . While it doesn't surprise me that there may well be MUAs which don't like subcriptions to folders that don't exist it seems to me that such MUAs are sailing pretty close to the wind as regards RFC 3501. The wording of sections 6.3.6 and 6.3.9 as I read it pretty heavily imply that clients must be prepared to deal with subscribed folders that no longer exist because a server is explicitly prevented from attempting to 'protect' a client from such a situation. 6.3.6. SUBSCRIBE Command [...] A server MAY validate the mailbox argument to SUBSCRIBE to verify that it exists. However, it MUST NOT unilaterally remove an existing mailbox name from the subscription list even if a mailbox by that name no longer exists. Note: This requirement is because a server site can choose to routinely remove a mailbox with a well-known name (e.g., system-alerts) after its contents expire, with the intention of recreating it when new contents are appropriate. [...] 6.3.9. LSUB Command [...] The server MUST NOT unilaterally remove an existing mailbox name from the subscription list even if a mailbox by that name no longer exists.
Re: [Dovecot] Variable krb5 cache location
TS == Timo Sirainen [EMAIL PROTECTED] writes:
TS I'm beginning to think that maybe something more generic is
TS needed, such as:
TS auth default {
TS ..
TS environment {
TS krb5_ktname = ..
TS krb5ccname = ...
TS who_knows_what_else_in_future = ..
TS }
TS }
TS I think LDAP library also can accept settings from environment.
TS Anyone on mailing list have better ideas?
I'm certainly not going to claim this is a better idea.
Instead of explicitly setting the environment vars from dovecot.conf how
about instead have a mechanism for listing those vars that are acceptable
to pass through from the invoking environment.
Re: [Dovecot] dovecot.index mtime
M == Matt [EMAIL PROTECTED] writes: M What if the script only touched the dovecot.index if it exists? M That would likely not be too difficult to test for with shell M script. Might be tricky to do in shell without a race. On the other hand maybe a race in this case is not significant. On the other hand it's possible that a running user imap process uses timestamps on the index file to determine whether it needs to update its idea of the content and gratuitously changing it on connect may cause already running processes to do more work that strictly necessary. Haven't looked at the actual code to asses the credibility of this though. On the other hand I've run out of hands now :)
Re: [Dovecot] dovecot.index mtime
BH == Benjamin R Haskell [EMAIL PROTECTED] writes: Can I just touch the dovecot.index instead? BH Maybe. Not sure what environment variable holds its location, BH though. And I'm not 100% sure it always exists or whether you'd BH have to special-case the first-time login. (Will 'touch' creating BH a zero-length index cause trouble for dovecot? I suspect not.) Also be aware that the script is not being run with the uid of the user - it is /usr/libexec/dovecot/imap that drops privs - so touching the index file if it does not already exist may cause problems later when the user process wants to update the index file. If you have sessreg from the X11 distribution you could also try: #!/bin/sh if test -z $DUMP_CAPABILITY; then /usr/bin/sessreg -a -L /var/log/lastlog -u none -w none -l imap -h $IP $USER fi exec /usr/libexec/dovecot/imap to put an entry into /var/log/lastlog (though note you need two scripts for both IMAP and POP logins). Also, I am bit confused. Why must the script exec imap? It doesn't _have_ to. It's a micro-optimisation. If the script did not exec the user imap process then a /bin/sh process would be sitting around waiting for the user imap process to exit and when it did then the /bin/sh process would itself just exit.
Re: [Dovecot] global sieve script
LS == Lars Stavholm [EMAIL PROTECTED] writes:
LS For example:
LS /etc/dovecot/dovecot.conf:
LS ...
LS protocol lda {
LS ...
LS sieve_global_path = /etc/dovecot/sieve/
LS ...
LS }
LS /etc/dovecot/global:
LS if header :contains X-Spam-Flag YES {
LS fileinto Spam;
LS stop;
LS }
LS ...or something similar.
Definitely take the something similar option since the above likely
won't work.
sieve_global_path should point to a _file_ containing a sieve script and
both the script _and_ the byte-compiled version (same name with 'c'
appended) should exist and the compiled output file should have an mtime
later than the source. If the cmusieve plugin can't find the compiled
version (or the mtime of the source is later than the mtime of the
compiled version) it will attempt to write it out a compiled version and
filesystem permissions really ought to prevent that.
So
/etc/dovecot/dovecot.conf:
...
protocol lda {
...
sieve_global_path = /etc/dovecot/global.sieve
...
}
/etc/dovecot/global.sieve:
if header :contains X-Spam-Flag YES {
fileinto Spam;
stop;
}
AND remember to byte-compile the script
/usr/libexec/dovecot/sievec /etc/dovecot/global.sieve /etc/dovecot/global.sievec
[Dovecot] potential maildir folder rename bug
Admittedly not a common situation but:
MAIL=maildir:~/tmp/dovecot/Maildir ./src/imap/imap
* PREAUTH [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND
UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS] Logged in as pod
01 LIST *
* LIST (\HasNoChildren) . INBOX
01 OK List completed.
02 CREATE a
02 OK Create completed.
03 LIST *
* LIST (\HasNoChildren) . a
* LIST (\HasNoChildren) . INBOX
03 OK List completed.
04 RENAME a a.b
04 OK Rename completed.
05 LIST *
* LIST (\HasNoChildren) . a.b.b
* LIST (\HasNoChildren) . INBOX
05 OK List completed.
I was expecting to wind up with two folders INBOX and a.b. Instead I
got INBOX and a.b.b.
I think the problem is that .a gets renamed in the filesystem to .a.b
before src/lib-storage/index/maildir/maildir-storage.c rename_subfolders()
is called, which then finds .a.b, assumes b was a subfolder of a so
renames it.
The following may or may not be an appropriate fix. It certainly feels
rather ad hoc and I've not thought too deeply about other circumstances
where this code is called. I'd certainly appreciate a second opinion.
diff -r 8d6433652a33 src/lib-storage/index/maildir/maildir-storage.c
--- a/src/lib-storage/index/maildir/maildir-storage.c Sun Sep 30 18:03:17
2007 +0300
+++ b/src/lib-storage/index/maildir/maildir-storage.c Mon Oct 01 20:13:27
2007 +0100
@@ -937,6 +937,10 @@ static int rename_subfolders(struct inde
t_push();
old_listname = t_strconcat(oldname, names[i], NULL);
+ if (strcmp(old_listname, newname) == 0) {
+ t_pop();
+ continue;
+ }
new_listname = t_strconcat(newname, names[i], NULL);
oldpath = maildir_get_path(storage, old_listname);
newpath = maildir_get_path(storage, new_listname);
Re: [Dovecot] deliver w/quotas - MDN after accept mail?
KA == Ken A [EMAIL PROTECTED] writes: KA Tried with -e, but sendmail says EX_NOPERM is a permanent error, KA and issues it's own DSN immediately. dsn=5.0.0, stat=Insufficient KA permission. :-( Not unexpected. I assumed (but neglected to express the assumption :) one could configure sendmail to consider the EX_NOPERM a temporary failure if one wanted that sort of behaviour. Not great I admit.
Re: [Dovecot] Dovecot + Sieve
DM == Daniel L Miller [EMAIL PROTECTED] writes: DM I did make a discovery - hardcoding the sieve path, without DM variables, e.g. sieve = /var/mail/amfes.com/dmiller/sieve - DM worked! DM Is there a problem using the domain / user variables in the DM configuration file? get_sieve_path() from cmusieve-plugin.c doesn't do % expansions. The result of get_sieve_path() names a file that gets processed. Here's what it does: - look at sieve var - if it is set but empty no sieve processing will occur at all (i.e. sieve_global_path, see below, will _not_ be considered) - if it doesn't begin with a '/' prepend $HOME/ - if it is not set then use ~/.dovecot.sieve (which is equivalent to $HOME/.dovecot.sieve in this case) If the file found above doesn't exist (strictly speaking if stat(2) returns a negative result) use sieve_global_path. If that is not set, for backwards compatibilty, use global_script_path. Note that whatever gets returned by get_sieve_path() is expected to name a _file_ containing sieve statements.
Re: [Dovecot] maildir rename_subfolders() and listescape interaction
pod == pod [EMAIL PROTECTED] writes:
pod I'd like to flag a problem we are observing that looks like it is
pod caused by the listescape-plugin.c. I realize that this plugin is
pod not part of the standard Dovecot 1.0 distribution but I would
pod appreciate any insights or suggestions for fixes that anyone is
pod kind enough to offer.
[...]
Update: my original analysis of this was incorrect. The 'internal'
functions are correctly using 'internal' names, however
maildir_mailbox_list_next() references storage-hierarchy_sep to obtain a
char with which to join together path elements. Under listescape however
storage-hierarchy_sep == '/' so non-existent pathnames are generated.
I've come up with the following workaround but I can't help feeling it is
maybe a little fragile.
Timo: please consider applying this to
http://dovecot.org/patches/1.0/listescape-plugin.c
diff -r 70cc4b8884ef src/plugins/listescape/listescape-plugin.c
--- a/src/plugins/listescape/listescape-plugin.cTue Jul 31 19:42:03
2007 +0100
+++ b/src/plugins/listescape/listescape-plugin.cFri Aug 31 19:21:05
2007 +0100
@@ -160,10 +160,16 @@ listescape_mailbox_rename(struct mail_st
{
struct listescape_mail_storage *mstorage =
LIST_ESCAPE_CONTEXT(storage);
+ char saved_hierarchy_sep;
+ int ret;
oldname = list_escape(oldname);
newname = list_escape(newname);
- return mstorage-super.mailbox_rename(storage, oldname, newname);
+ saved_hierarchy_sep = storage-hierarchy_sep;
+ storage-hierarchy_sep = REAL_SEP;
+ ret = mstorage-super.mailbox_rename(storage, oldname, newname);
+ storage-hierarchy_sep = saved_hierarchy_sep;
+ return ret;
}
static int listescape_set_subscribed(struct mail_storage *storage,
[Dovecot] maildir rename_subfolders() and listescape interaction
I'd like to flag a problem we are observing that looks like it is caused by the listescape-plugin.c. I realize that this plugin is not part of the standard Dovecot 1.0 distribution but I would appreciate any insights or suggestions for fixes that anyone is kind enough to offer. The problem concerns subfolder renames when used in conjunction with Maildir folders (I've not tested this against any other folder type). Without listescape plugin: mail_location: maildir:%h/Maildir:INDEX=%h/index:CONTROL=%h/control mail_plugins(default): quota imap_quota mail_plugins(imap): quota imap_quota namespace: type: private separator: / inbox: yes 01 LIST * * LIST (\HasNoChildren) / INBOX 01 OK List completed. 02 CREATE a 02 OK Create completed. 03 CREATE a/b 03 OK Create completed. 04 LIST * * LIST (\HasChildren) / a * LIST (\HasNoChildren) / INBOX * LIST (\HasNoChildren) / a/b 04 OK List completed. 05 RENAME a c 05 OK Rename completed. 06 LIST * * LIST (\HasChildren) / c * LIST (\HasNoChildren) / INBOX * LIST (\HasNoChildren) / c/b 06 OK List completed. 07 LOGOUT * BYE Logging out 07 OK Logout completed. With listescape plugin: mail_location: maildir:%h/Maildir:INDEX=%h/index:CONTROL=%h/control mail_plugins(default): quota imap_quota listescape mail_plugins(imap): quota imap_quota listescape namespace: type: private separator: / inbox: yes 01 LIST * * LIST (\HasNoChildren) / INBOX 01 OK List completed. 02 CREATE a 02 OK Create completed. 03 CREATE a/b 03 OK Create completed. 04 LIST * * LIST (\HasChildren) / a * LIST (\HasNoChildren) / INBOX * LIST (\HasNoChildren) / a/b 04 OK List completed. 05 RENAME a c 05 NO Internal error occurred. Refer to server log for more information. [2007-08-30 19:33:41] 06 LIST * * LIST (\HasNoChildren) / a/b * LIST (\HasNoChildren) / c * LIST (\HasNoChildren) / INBOX 06 OK List completed. 07 LOGOUT * BYE Logging out 07 OK Logout completed. Seemingly the only relevant log entry is @400046d70d8f1f72b66c dovecot: Error: IMAP(pod): rename(/srv/mail/home/test0/pod/Maildir/.a/b, /srv/mail/home/test0/pod/Maildir/.c/b) failed: No such file or directory Note the response to tag 05 in each case. The 06 list response in the listescape case is not unexpected given the nature of the failure. My initial reading of rename_subfolders() from maildir-storage.c suggests that the calls through maildir_mailbox_list_init() and maildir_mailbox_list_next() are returning external style names (i.e. ones that present / as the hierarchy separator) to rename_subfolders(), which is an internal helper function. This is supported by the logged error message. I am afraid I am yet to get my head around the actual code path and the escaping and unescaping that is going on so am not able to suggest a fix as yet.
Re: [Dovecot] deliver copies ^From header lines when delivering to Maildir
TS == Timo Sirainen [EMAIL PROTECTED] writes: TS Well, doing it only if it's the first header would make it better. Sure, I considered that. I note though that the save_header_callback() from mbox-save.c also does not make this distinction and will strip a ^From anywhere in the headers so I am going to claim I followed suit on grounds of consistency :-)
[Dovecot] logging dovecot-sieve vacation responses
I attach a patch that adds some informational logging for the vacation
outcome in a similar style as the 'notify', 'redirect' and 'reject' cases.
I considered adding logging for the not-willing-to-respond case since I
think that would greatly assist testing/debugging vacation responses, but
couldn't see where to put it that wasn't in the CMU code.
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1187020492 -3600
# Node ID 88b201d37835eb841fba76b9e918857f7236eafa
# Parent 5132f4b25eb08437f22ce2458bfa6b1e4d27ae9c
informational logging of vacation response outcome
diff -r 5132f4b25eb0 -r 88b201d37835 src/sieve-cmu.c
--- a/src/sieve-cmu.c Tue Aug 07 20:24:57 2007 +0100
+++ b/src/sieve-cmu.c Mon Aug 13 16:54:52 2007 +0100
@@ -346,23 +346,25 @@ static int autorespond(void *ac,
static int autorespond(void *ac,
void *ic __attr_unused__,
void *sc,
- void *mc __attr_unused__,
+ void *mc,
const char **errmsg __attr_unused__)
{
sieve_autorespond_context_t *arc = (sieve_autorespond_context_t *) ac;
script_data_t *sd = (script_data_t *) sc;
-int ret;
+sieve_msgdata_t *md = mc;
/* ok, let's see if we've responded before */
-ret = duplicate_check(arc-hash, arc-len, sd-username) ?
- SIEVE_DONE : SIEVE_OK;
-
-if (ret == SIEVE_OK) {
- duplicate_mark(arc-hash, arc-len, sd-username,
- ioloop_time + arc-days * (24 * 60 * 60));
-}
-
-return ret;
+if (duplicate_check(arc-hash, arc-len, sd-username)) {
+ i_info(msgid=%s: discarded duplicate vacation response to %s,
+ md-id == NULL ? : str_sanitize(md-id, 80),
+ str_sanitize(md-return_path, 80));
+ return SIEVE_DONE;
+}
+
+duplicate_mark(arc-hash, arc-len, sd-username,
+ ioloop_time + arc-days * (24 * 60 * 60));
+
+return SIEVE_OK;
}
static int send_response(void *ac,
@@ -409,6 +411,9 @@ static int send_response(void *ac,
if (smtp_client_close(smtp_client) == 0) {
duplicate_mark(outmsgid, strlen(outmsgid),
sdata-username, ioloop_time + DUPLICATE_DEFAULT_KEEP);
+ i_info(msgid=%s: sent vacation response to %s,
+ md-id == NULL ? : str_sanitize(md-id, 80),
+ str_sanitize(md-return_path, 80));
return SIEVE_OK;
} else {
*errmsg = Error sending mail;
Re: [Dovecot] Maildir Skeleton
SG == Sebastian Ganschow [EMAIL PROTECTED] writes: SG Even if I set global_script_dir = /var/vmail dovecot won't use SG the global filter. shell$ cd dovecot-sieve-1.0.2 shell$ find . -type f -name \*.[ch] -print0 | xargs -0 grep -i -e global_script ./src/cmusieve-plugin.c:script_path = getenv(GLOBAL_SCRIPT_PATH); shell$ Have you tried global_script_path = /var/vmail/script.sieve Note that the var name is _path not _dir, and the value should be a script file not a directory. I'm just jumping in here mid-thread so apologies if I'm misunderstanding the nature of your problem.
[Dovecot] dovecot-sieve vacation changes
I'd like to put forward the following patch for dovecot-sieve.
Essentially this just merges in some changes made in CMU sieve 2.3.8 and
as such brings the behaviour more in line with RFC 3834 Recommendations
for Automatic Responses to Electronic Mail:
- fixes erroneous sender -request substring match
- checks for existence of a selection of list-* headers
- expands named-as-recipient header checks to Resent-To, Resent-CC
and Resent-BCC fields. Note that the appended patch also includes a
fix for some missing parentheses in the resent-to test which resulted
in some extra work being done but was otherwise harmless. The fix has
been sent to [EMAIL PROTECTED]
- prefixes subject in response with Auto: rather than (non-expanding)
Re:
I also, mostly for kicks, attach two sieve-like scripts that attempt to
encapsulate the when-not-to-respond logic as implemented (if the patch
were to be applied) and as advised by RFC 3834 respectively. I wrote
these as an exercise to help me gain a better understanding of sieve and
the CMU implementation. I'm not sure they are otherwise useful.
#
# An attempt to render, as SIEVE, the actions of shouldRespond() from CMU
# sieve/bc_eval.c as distributed with cyrus-imapd 2.3.8
#
# This is not valid SIEVE; The following expansions must first be
# performed:
#
# - %myaddrs% list of valid recipient addresses
# - %envrcpt% the actual envelope recipient
#
# Example:
#
# sed -e 's/%myaddrs%/[[EMAIL PROTECTED], [EMAIL PROTECTED]]/' \
# -e 's/%envrcpt%/[EMAIL PROTECTED]/' vacation.sieve.in
#
require [envelope];
if anyof ( exists list-id,
exists list-help,
exists list-subscribe,
exists list-unsubscribe,
exists list-post,
exists list-owner,
exists list-archive,
# XXX bc_eval.c also skips leading whitespace
not header :is auto-submitted no,
# XXX bc_eval.c also skips leading whitespace
header :is precedence [junk, bulk, list],
# XXX does this really catch null sender?
envelope :all :is from ,
# envelope sender equals envelope recipient; redundant if we assume
# %envrcpt% is an element in %myaddrs%
envelope :all :is from %envrcpt%,
envelope :all :is from %myaddrs%,
envelope :localpart :is from [mailer-daemon,
listserv,
majordomo],
envelope :comparator i;octet
:localpart :matches from [*-request,
owner-*],
not address :all :is [to,
cc,
bcc,
resent-to,
resent-cc,
resent-bcc] %myaddrs%
) {
discard;
}
#
# An attempt to render, as SIEVE, the advice from RFC 3834 section 2 When
# (not) to send automatic responses. Assumes we are a Personal
# Responder.
#
# This is not valid SIEVE; The following expansions must first be
# performed:
#
# - %myaddrs%list of valid recipient addresses
# - %untrusted% list of untrusted envelope senders
#
# Example:
#
# sed -e 's/%myaddrs%/[[EMAIL PROTECTED], [EMAIL PROTECTED]]/' \
# -e 's/%untrusted%/[[EMAIL PROTECTED]]/' rfc3834.sieve.in
#
require [envelope];
if anyof ( # Fails to account for syntax defined in section 5.1
# SHOULD NOT
not header :is auto-submitted no,
# SHOULD NOT
not address :all :is [to,
cc,
bcc,
resent-to,
resent-cc,
resent-bcc] %myaddrs%,
# MAY
envelope :all :is from %untrusted%,
# XXX Not clear if this correctly expresses a null sender
# MUST NOT
envelope :all :is from ,
# Strictly speaking localparts are case-sensitive hence the
# use of :comparator. In reality the default i;ascii-casemap
# comparator almost certainly make more sense.
# MAY
envelope :comparator i;octet
:localpart :is from [MAILER-DAEMON],
envelope :comparator i;octet
:localpart :matches from [*-request,
owner-*],
# XXX no such recommendation is actually made
# MAY
header :is precedence list,
# Mentions List-* and references RFC2369. Not possible to
# express list-* as a header match in sieve. Instead just
# enumerate the RFC2369 and RFC2919 (List-ID) defined headers.
# MAY
exists list-help,
exists list-unsubscribe,
exists list-subscribe,
exists
Re: [Dovecot] Allowing tilde at start of mailbox names
TS == Timo Sirainen [EMAIL PROTECTED] writes:
TS It's mostly there just to make sure that ~/ or ~user/ can't be
TS used to open mailboxes where you weren't supposed to have access
TS to. I didn't think anyone would really want to have mailboxes
TS beginning with ~. Do you really want them? (I don't think they
TS were possible with UW-IMAP either?)
Unfortunately yes it would be useful in my case to have them because of
historical accident. UW-IMAP does in fact allow it but maybe only if one
is using particular build-time options such as blackBoxDir; I forget the
precise details. Suffice to say at some point users were erroneously told
to configure clients with '~/mail' as a prefix and this in combination
with the particular UW-IMAP build options means we have users with folder
hierarchies beginning ~/mail ('~' uninterpreted). I don't think I can
work around this with a hidden namespace since a client subsequently
configured not to use a prefix will be used to seeing folders under
~/mail ('~' uninterpreted). I'm (increasingly forlornly it seems)
attempting to migrate with no user visible change.
Why is it not possible to have mailbox names that begin with '~'
but without '~' carrying any special meaning?
TS That's what the code does if you don't have
TS mail_full_filesystem_access=yes, but I thought I'd prevent this in
TS no case just in case of a bug somewhere, possibly even outside of
TS Dovecot itself.
I appreciate your reasoning regarding bugs elsewhere. I was, however,
hoping to introduce a mode of behaviour that would allow me to accept the
risk. I'm not using virtual users; every login runs under its own uid so
I still have filesystem permissions as a reasonable fall back.
TS There are too many settings
TS already. mail_full_filesystem_access=no should be enough for this.
I completely understand why you want to keep the number of setting down.
My motivation for introducing a new setting was a vain hope that allowing
uninterpreted (*name == '~') behaviour could go into the 1.0 codebase but
without also changing the meaning of mail_full_filesystem_access=no in
existing deployments.
Re: [Dovecot] Allowing tilde at start of mailbox names
TS == Timo Sirainen [EMAIL PROTECTED] writes: TS How about if listescape plugin escaped it? That would make it TS possible to use them but still safe against accidental problems. Yes, I think that would work fine at least for my particular purposes since we'll almost certainly be running with the listescape plugin anyway. TS For others too, I implemented a plugin for escaping mailbox names TS with Maildir so that it's possible to use '.' in mailbox names: TS http://dovecot.org/patches/1.0/listescape-plugin.c Not one to blow your own trumpet are you! For further explanation for the benefit of the list: I recently contacted Timo privately asking if he would consider us funding him to implement a modified maildir layout for us. A few hours later he responded with listescape-plugin.c. What an absolute star.
Re: [Dovecot] Dovecot 1.0.0 and Seive 1.0.1 on FreeBSD
ed == Ed Lucero [EMAIL PROTECTED] writes: ed It creates two binaries sievec and sieved. [...] - sievec is a standalone bytecode compiler - sieved is a standalone bytecode de-compiler You can use them to verify that .dovecot.sieve and .dovecot.sievec are being updated correctly by the cmusieve plugin. The dovecot-sieve tarball bundles CMU libsieve, from which they originate, and they get installed 'for free'.
