Re: [Dovecot] Dovecot 2.0.rc3 Capability response

[pod]

"A.L.E.C"  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

[pod]

"Leander S."  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]

[pod]

"Rick Romero"  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:.*
[...]

and in sieve:

if header :contains "list-id" "" {
[...]

Re: [Dovecot] dovecot auth is case insensitive, but fs is sensitive :)

[pod]

Noel Butler  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

[pod]

Stephan Bosch  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

[pod]

Timo Sirainen  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

[pod]

Peter Lindgren  writes:

> H, there are more things in IMAP than just this. Mail clients (user
> agents) that are independent of the server platform, for instance.

I don't understand what you mean.  Nothing I've said implies a dependence
on the server platform.  The presentation of the hierarchy representing
the mailbox is analogous to how one might design an HTTP URI hierarchy to
present a RESTful interface to a mailbox.

Re: [Dovecot] v3.0 architecture

[pod]

Timo Sirainen  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

[pod]

Timo Sirainen  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...

[pod]

Richard Hobbs  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

[pod]

Timo Sirainen  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)

[pod]

> "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

[pod]

> "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]

[pod]

> "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?

[pod]

> "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?

[pod]

> "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

[pod]

> "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

[pod]

> "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

[pod]

> "BH" == Benjamin R Haskell <[EMAIL PROTECTED]> writes:

BH> Since you're not doing anything protocol-specific (like echo "* OK
BH> [ALERT] Blah"), you could use the symlink trick to only require
BH> one script:

BH> ln -s /path/script /path/imap
BH> ln -s /path/script /path/pop3

BH> Then replace the exec with:
BH> exec /usr/libexec/dovecot/`basename $0`

I was thinking about the "-l imap" in the sessreg invocation but clearly
one could use `basename $0` to handle that too.  My preference is to avoid
scripts whose behaviour is determined by the name by which they were
invoked.

Re: [Dovecot] dovecot.index mtime

[pod]

> "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

[pod]

> "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

[pod]

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?

[pod]

> "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] deliver w/quotas - MDN after accept mail?

[pod]

> "KA" == Ken A <[EMAIL PROTECTED]> writes:

KA> I'm testing deliver with sendmail and fs quotas.

KA> On an over quota condition, deliver accepts the mail, deletes it,
KA> then issues a MDN immediately.

KA> Is there a way to get deliver to soft fail like procmail does with
KA> a 400 error and queue the mail, then let sendmail handle the MDN,
KA> following it's "confTO_QUEUEWARN" and "confTO_QUEUERETURN" ?

Last time I looked at deliver it seemed like there were very few
conditions it considered as a temporary failure and thus for it to return
EX_TEMPFAIL.  I also was considering over-quota conditions (also
filesystem quotas).

The '-e' option to deliver will, possibly by accidental side-effect, avoid
calling the deliver-generated bounce code.  Instead deliver will write
some error text on stderr and exit EX_NOPERM.

The code in question is src/deliver/deliver.c lines 810 -- 835 which
occurs right after attempting to save the message (i.e. ret is the return
code from the save attempt).  The '-e' option is what sets
stderr_rejection.

if (ret < 0) {
const char *error, *msgid;
bool syntax, temporary_error;
int ret;

error = mail_storage_get_last_error(storage, &syntax,
&temporary_error);
if (temporary_error)
return EX_TEMPFAIL;

msgid = mail_get_first_header(mail, "Message-ID");
i_info("msgid=%s: Rejected: %s",
   msgid == NULL ? "" : str_sanitize(msgid, 80),
   str_sanitize(error, 512));

/* we'll have to reply with permanent failure */
if (stderr_rejection) {
fprintf(stderr, "%s\n", error);
return EX_NOPERM;
}
ret = mail_send_rejection(mail, destination, error);
if (ret != 0)
return ret < 0 ? EX_TEMPFAIL : ret;
/* ok, rejection sent */
}

As Timo has said elsewhere "deliver could use a rewrite some day..".

Re: [Dovecot] deliver copies "^From " header lines when delivering to Maildir

[pod]

> "TS" == Timo Sirainen <[EMAIL PROTECTED]> writes:

>> Well, doing it only if it's the first header would make it
>> better. I guess I could do something like that since this is a
>> pretty common problem..

TS> http://hg.dovecot.org/dovecot-1.0/rev/4c807839ac0c

Hasn't create_mbox_stream() returned by the time save_header_callback() is
called?  Doesn't that mean that the &first passed as *context to
save_header_callback() is of dubious validity?

Re: [Dovecot] quota reporting and mail.app

[pod]

> "RS" == Rich at Whidbey Telecom <[EMAIL PROTECTED]> writes:

RS> If I remember right, this is a known issue, where Mail.app won't
RS> report the quota when QUOTAROOT is "".  We've found no fix for it
RS> here as it seems to be a Mail.app issue.

Our local Mac expert here informs me that this problem is fixed in
Leopard.

Re: [Dovecot] Dovecot + Sieve

[pod]

> "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] Dovecot + Sieve

[pod]

> "DM" == Daniel L Miller <[EMAIL PROTECTED]> writes:

DM> I've tried manually compiling the script.  I now have a "sieve"
DM> and a "sievec" in my mail folder, and the "sieve" variable in
DM> dovecot.conf (1.0.3) is set to /var/mail/%d/%u/sieve (The filename
DM> specified should be the script source, not the compiled version,
DM> correct?).

DM> I receive no errors from deliver using this method - but no
DM> evidence that the script is being followed, either.  I thought I'd
DM> start with something simple - when that didn't work I added a
DM> global fileinto directive - still not doing anything.  Do I need
DM> to set execute permissions or turn off world-readable permissions
DM> on the script or compiled version?

Create the following config file or something similar:

log_path = /dev/stderr
info_log_path = /dev/stderr

mail_debug = yes
mail_location = maildir:%h/tmp/Maildir

protocol lda {
  postmaster_address = [EMAIL PROTECTED]
  mail_plugins = cmusieve
}

put it in, say, ~/tmp/dovecot.lda-debug.conf.  Directly invoke deliver as
a regular user with the -c option pointing to this config file, e.g.

[EMAIL PROTECTED] date | /usr/libexec/dovecot/deliver -c 
~/tmp/dovecot.lda-debug.conf

Observe the output.

DM> require ["fileinto"];
DM> if header :contains ["From","To"] ["[EMAIL PROTECTED]","[EMAIL 
PROTECTED]"] {
DM>   fileinto "System-Messages";
DM> }
DM> fileinto "System-Messages";

I think you ought to consider using an ADDRESS test rather than a HEADER
test for this sort of match, thus

if address :is :all ["from", "to"] ["[EMAIL PROTECTED]", "[EMAIL PROTECTED]"] {
  # ... etc
}

which will do proper address matching (i.e. phrase or comment parts in
headers won't match) against a reasonable set of sender and recipient
headers (for example a CC header).

Re: [Dovecot] maildir rename_subfolders() and listescape interaction

[pod]

>>>>> "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

[pod]

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

[pod]

> "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] deliver copies "^From " header lines when delivering to Maildir

[pod]

deliver appears to copy "^From " header lines from stdin when delivering
to Maildir.  The header filtering in mbox-save.c prevents this when
delivering to an mbox and instead a synthesized "^From " header is
written.

This is an issue when using, for example, Postfix and

  mailbox_command = /usr/libexec/dovecot/deliver

which does not appear to have an option not to write a "^From " header on
the mailbox_command input.

I'm attaching a patch that adds a save_header_callback() along the same
lines as in mbox-save.c but I'm really not sure this is the right way to
do it.
diff -r a0c3daf7e501 src/deliver/deliver.c
--- a/src/deliver/deliver.c Mon Aug 13 18:00:18 2007 +0300
+++ b/src/deliver/deliver.c Tue Aug 14 16:47:34 2007 +0100
@@ -16,6 +16,7 @@
 #include "strescape.h"
 #include "var-expand.h"
 #include "message-address.h"
+#include "message-parser.h"
 #include "istream-header-filter.h"
 #include "mbox-storage.h"
 #include "dict-client.h"
@@ -410,6 +411,18 @@ static const char *address_sanitize(cons
return ret;
 }
 
+static void save_header_callback(struct message_header_line *hdr,
+ bool *matched, void *context)
+{
+   i_assert(matched && context == NULL);
+   if (hdr != NULL) {
+   if (strncmp(hdr->name, "From ", 5) == 0) {
+   *matched = TRUE;
+   }
+   }
+   return;
+}
+
 static struct istream *create_mbox_stream(int fd, const char *envelope_sender)
 {
const char *mbox_hdr;
@@ -426,7 +439,7 @@ static struct istream *create_mbox_strea
 HEADER_FILTER_NO_CR,
 mbox_hide_headers,
 mbox_hide_headers_count,
-NULL, NULL);
+save_header_callback, 
NULL);
i_stream_unref(&input);
 
input_list[0] = i_stream_create_from_data(default_pool, mbox_hdr,

[Dovecot] logging dovecot-sieve vacation responses

[pod]

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

[pod]

> "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

[pod]

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 he

Re: [Dovecot] Allowing tilde at start of mailbox names

[pod]

> "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] Vacation message functionality

[pod]

> "CM" == Charles Marcus <[EMAIL PROTECTED]> writes:

CM> The only response I got did seem to have a few very good
CM> suggestions for additional conditions to test for, so I'm posting
CM> the response here to see if they can be incorporated (I'm not a
CM> coder or I'd attempt it myself).

These certainly do look like reasonable suggestions.  I am going to be
looking at exactly the vacation handling code over the next few days and
already suspect that I need to make some changes.  I'll certainly look at
adding the suggested tests but see below.

CM> The original text (prefixed by double quote characters) in the
CM> following exchange is what I copied/pasted from the wiki, [...]

Assuming the wiki text has not changed significantly it is I believe a
rendering, in english, of the tests performed all the way down in the CMU
Cyrus sieve code.  So strictly speaking this is not a Dovecot specific
issue other than that  contains
a copy of the sieve code from Cyrus imapd.

Re: [Dovecot] Allowing tilde at start of mailbox names

[pod]

> "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.

[Dovecot] Allowing tilde at start of mailbox names

[pod]

In lib-storage/index/maildir/maildir-storage.c
maildir_is_valid_create_name() and maildir_is_valid_existing_name() the
following sequence of tests appear but I don't really understand why

if ((storage->flags & MAIL_STORAGE_FLAG_FULL_FS_ACCESS) != 0)
return TRUE;

if (*name == '~' || strchr(name, '/') != NULL)
return FALSE;

If MAIL_STORAGE_FLAG_FULL_FS_ACCESS is set then the validator funcs return
TRUE immediately and code elsewhere will do appropriate home_exapand for
mailbox names.  However if MAIL_STORAGE_FLAG_FULL_FS_ACCESS is not set the
(*name == '~') test prevents mailbox names that begin with '~'.

Why is it not possible to have mailbox names that begin with '~' but
without '~' carrying any special meaning?

I have been working on a patch (appended but incomplete; the option only
works against maildir atm) that adds a new option mail_allow_tilde and my
admittedly limited testing seems to indicate that it does the right thing
but maybe I am barking up the wrong tree.  Am I missing something here?


# HG changeset patch
# User <[EMAIL PROTECTED]>
# Date 1185368923 -3600
# Node ID ab9cf3790ea9b5486afa6498f60c6bf6fb2e5f1e
# Parent  a23be695672737967a10613d7dca2a6f53b5d96d
create new option mail_allow_tilde

diff -r a23be6956727 -r ab9cf3790ea9 
src/lib-storage/index/maildir/maildir-storage.c
--- a/src/lib-storage/index/maildir/maildir-storage.c   Tue Jul 24 05:48:03 
2007 +0300
+++ b/src/lib-storage/index/maildir/maildir-storage.c   Wed Jul 25 14:08:43 
2007 +0100
@@ -240,7 +240,9 @@ static bool maildir_is_valid_create_name
if ((storage->flags & MAIL_STORAGE_FLAG_FULL_FS_ACCESS) != 0)
return TRUE;
 
-   if (*name == '~' || strchr(name, '/') != NULL)
+   if ((*name == '~' &&
+(storage->flags & MAIL_STORAGE_FLAG_ALLOW_TILDE) == 0) ||
+strchr(name, '/') != NULL)
return FALSE;
 
if (name[0] == '.' && (name[1] == '\0' ||
@@ -264,7 +266,9 @@ static bool maildir_is_valid_existing_na
if ((storage->flags & MAIL_STORAGE_FLAG_FULL_FS_ACCESS) != 0)
return TRUE;
 
-   if (*name == '~' || strchr(name, '/') != NULL)
+   if ((*name == '~' &&
+(storage->flags & MAIL_STORAGE_FLAG_ALLOW_TILDE) == 0) ||
+   strchr(name, '/') != NULL)
return FALSE;
 
if (name[0] == '.' && (name[1] == '\0' ||
diff -r a23be6956727 -r ab9cf3790ea9 src/lib-storage/mail-storage.c
--- a/src/lib-storage/mail-storage.cTue Jul 24 05:48:03 2007 +0300
+++ b/src/lib-storage/mail-storage.cWed Jul 25 14:08:43 2007 +0100
@@ -66,6 +66,8 @@ void mail_storage_parse_env(enum mail_st
*flags_r = 0;
if (getenv("FULL_FILESYSTEM_ACCESS") != NULL)
*flags_r |= MAIL_STORAGE_FLAG_FULL_FS_ACCESS;
+   if (getenv("ALLOW_TILDE") != NULL)
+   *flags_r |= MAIL_STORAGE_FLAG_ALLOW_TILDE;
if (getenv("DEBUG") != NULL)
*flags_r |= MAIL_STORAGE_FLAG_DEBUG;
if (getenv("MMAP_DISABLE") != NULL)
diff -r a23be6956727 -r ab9cf3790ea9 src/lib-storage/mail-storage.h
--- a/src/lib-storage/mail-storage.hTue Jul 24 05:48:03 2007 +0300
+++ b/src/lib-storage/mail-storage.hWed Jul 25 14:08:43 2007 +0100
@@ -34,7 +34,9 @@ enum mail_storage_flags {
   fail to create the storage. */
MAIL_STORAGE_FLAG_NO_AUTOCREATE = 0x200,
/* Rely on O_EXCL when creating dotlocks */
-   MAIL_STORAGE_FLAG_DOTLOCK_USE_EXCL  = 0x400
+   MAIL_STORAGE_FLAG_DOTLOCK_USE_EXCL  = 0x400,
+   /* Allow folder names to begin with '~' TILDE */
+   MAIL_STORAGE_FLAG_ALLOW_TILDE   = 0x800
 };
 
 enum mail_storage_lock_method {
diff -r a23be6956727 -r ab9cf3790ea9 src/master/mail-process.c
--- a/src/master/mail-process.c Tue Jul 24 05:48:03 2007 +0300
+++ b/src/master/mail-process.c Wed Jul 25 14:08:43 2007 +0100
@@ -254,6 +254,8 @@ mail_process_set_environment(struct sett
env_put("DEBUG=1");
if (set->mail_full_filesystem_access)
env_put("FULL_FILESYSTEM_ACCESS=1");
+   if (set->mail_allow_tilde)
+   env_put("ALLOW_TILDE=1");
if (set->pop3_no_flag_updates)
env_put("POP3_NO_FLAG_UPDATES=1");
if (set->pop3_reuse_xuidl)
diff -r a23be6956727 -r ab9cf3790ea9 src/master/master-settings-defs.c
--- a/src/master/master-settings-defs.c Tue Jul 24 05:48:03 2007 +0300
+++ b/src/master/master-settings-defs.c Wed Jul 25 14:08:43 2007 +0100
@@ -67,6 +67,7 @@ static struct setting_def setting_defs[]
DEF(SET_INT, mailbox_idle_check_interval),
DEF(SET_BOOL, mail_debug),
DEF(SET_BOOL, mail_full_filesystem_access),
+   DEF(SET_BOOL, mail_allow_tilde),
DEF(SET_INT, mail_max_keyword_length),
DEF(SET_BOOL, mail_save_crlf),
DEF(SET_BOOL, mail_read_mmaped),
diff -r a23be6956727 -r ab9cf3790ea9 src/master/master-setting

Re: [Dovecot] Sieve Vacation Auto-Reply Exclusions

[pod]

> "BB" == Bruce Bodger <[EMAIL PROTECTED]> writes:

BB> The Dovecot Wiki is quite clear regarding its vacation auto-reply
BB> mechanism http://wiki.dovecot.org/LDA/Sieve and under what
BB> circumstances the automatic replies will NOT be sent. However, is
BB> it possible to manually add a list of envelope senders that the
BB> script will not respond to?

Beyond putting the vacation clause inside a conditional?

require ["envelope", "vacation"];
if not envelope :all :is "from" ["[EMAIL PROTECTED]", "[EMAIL PROTECTED]"] {
  vacation;
}

Re: [Dovecot] Dovecot 1.0.0 and Seive 1.0.1 on FreeBSD

[pod]

> "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'.

Re: [Dovecot] Building problem on FreeBSD with GSSAPI

[pod]

> "TS" == Taras Savchuk <[EMAIL PROTECTED]> writes:

TS> gw# krb5-config --version
TS> FreeBSD heimdal 0.6.3 $Id: krb5-config.in,v 1.9 2002/09/09 22:29:06 
joda Exp $
TS> gw# krb5-config --libs gssapi
TS> -L/usr/lib -lgssapi -lkrb5 -lasn1 -lcrypto -lroken -lcrypt -lcom_err

I'm not sure how much further I can help you since I don't have access to
any FreeBSD compilation environments.  Maybe someone else on this list can
at least either confirm success or report similar problems building
dovecot on FreeBSD 6.2.

Are you able to compile and link the appended C without error?

  cc $(krb5-config --cflags gssapi) -o gssapi.o -c gssapi.c
  cc $(krb5-config --libs gssapi) -o gssapi gssapi.o

If not then it's probably not a dovecot specific problem.


#include 
#include 

int
main(int argc, char *argv[])
{
  OM_uint32 rc_major, rc_minor;
  gss_name_t name;

  rc_major=gss_import_name(&rc_minor, GSS_C_NO_BUFFER, GSS_C_NO_OID, &name);

  return EXIT_SUCCESS;
}

Re: [Dovecot] Building problem on FreeBSD with GSSAPI

[pod]

> "TS" == Taras Savchuk <[EMAIL PROTECTED]> writes:

TS> I have error while compiling dovecot with GSSAPI under FreeBSD
TS> 6.2: Is this dovecot-related or not?

One suspects not since none of the dovecot code directly calls into the
krb5 API.  It looks like a linkage problem with /usr/lib/libgssapi.so.  Do
you have a 'krb5-config' and if so what is the output of

krb5-config --version
krb5-config --libs gssapi