Re: [Dovecot] sievec error: "fileinto require missing"

[Braden McDaniel]

On Sun, 2009-06-28 at 11:33 +0200, Thomas Leuxner wrote:
> On Sun, Jun 28, 2009 at 05:25:28AM -0400, Braden McDaniel wrote:
> > .dovecot.sieve just looks like this:
> > 
> > $ cat .dovecot.sieve
> > if header :contains ["List-Id"] ["dovecot.dovecot.org"]
> > {
> > fileinto "INBOX.dovecot";
> > stop;
> > }
> 
> You need to include the referenced functions in the script via require:
> 
> require ["include","copy","fileinto","vacation"];
> #nclude :global "global.sieve";
> 
> In your case require require ["fileinto"]; will do at the top of the script.

Aha.  Thank you.

-- 
Braden McDaniel 

[Dovecot] System users, mbox format and global ACLs

[Axel Luttgens]

I need some help here... ;-)
I'm experimenting with global ACLs, but just fail to understand very  
basic behaviors.
So, before digging into the source code, I would really be delighted  
if someone could immediately point a mistake I'm making and miserably  
overlooking.


The output of dovecot -n is provided at the end of this email.
Just in case, conforming to the suggestion made in http://wiki.dovecot.org/ACL 
, I've specified a CONTROL directory; but I get a similar behavior  
without it.
As far as the acl plugin is concerned, I've just specified a directory  
for global ACLs; whether that directory is populated or not doesn't  
seem to have an impact on the observed behavior.


Here's the structure of the test user's home directory:

total 0
drwx--  4 testuser  people  136 26 jui 13:52 .
drwxr-xr-x  3 root  admin   102 19 mai 16:56 ..
drwxr-xr-x  4 testuser  people  136 28 jui 17:09 _mailboxes
drwxr-xr-x  2 testuser  people   68 28 jui 17:07 _mboxesctrl

./_mailboxes:
total 96
drwxr-xr-x  4 testuser  people136 28 jui 17:09 .
drwx--  4 testuser  people136 26 jui 13:52 ..
drwx--  3 testuser  people102 19 mai 17:02 .imap
-rw---  1 testuser  people  48685 25 jui 16:58 inbox

./_mailboxes/.imap:
total 0
drwx--  3 testuser  people  102 19 mai 17:02 .
drwxr-xr-x  4 testuser  people  136 28 jui 17:09 ..
drwx--  5 testuser  people  170 23 jui 18:02 INBOX

./_mailboxes/.imap/INBOX:
total 88
drwx--  5 testuser  people170 23 jui 18:02 .
drwx--  3 testuser  people102 19 mai 17:02 ..
-rw---  1 testuser  people   1376 23 jui 18:02 dovecot.index
-rw---  1 testuser  people  26624 28 jui 10:23 dovecot.index.cache
-rw-rw-rw-  1 testuser  people  10284 25 jui 17:57 dovecot.index.log

./_mboxesctrl:
total 0
drwxr-xr-x  2 testuser  people   68 28 jui 17:07 .
drwx--  4 testuser  people  136 26 jui 13:52 ..

I've tried various combinations of permissions and ownership, again  
without any obvious influence.
The manual creation of directory ~/_mboxesctrl/.imap doesn't seem to  
be more helpful.


So, let's go to the heart of my "problem":

# telnet 127.0.0.1 imap
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
	* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE  
AUTH=PLAIN] Dovecot ready.

a1 login testuser **
	a1 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID  
ENABLE SORT THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE  
CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC  
ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH] Logged in

a2 list "" *
* LIST (\NoInferiors \UnMarked) "/" "dovecot-acl-list"
* LIST (\HasNoChildren \UnMarked) "/" "INBOX"
a2 OK List completed.
a3 logout
* BYE Logging out
a3 OK Logout completed.
Connection closed by foreign host.

And indeed, a file named "dovecot-acl-list" has now been created under  
the _mailboxes directory:


./_mailboxes:
total 96
drwxr-xr-x  5 testuser  people170 28 jui 17:11 .
drwx--  4 testuser  people136 26 jui 13:52 ..
drwx--  3 testuser  people102 19 mai 17:02 .imap
-rw-r--r--  1 testuser  people  0 28 jui 17:11 dovecot-acl-list
-rw---  1 testuser  people  48685 25 jui 16:58 inbox

This is the only file to have been created consecutively to the telnet  
session.


Is such a file supposed to be created there?
If yes, why? I would have tended to believe that it is more a server  
internal matter than a name having to appear in the namespace.


More generally, is such a file supposed to be created at all? After  
all, the configuration doesn't explicitely mention per-mailbox ACLs at  
all...


Anyway, this is what gets written in mail.log for the whole telnet  
session:


dovecot[82305]: auth(default): new auth connection: pid=82374
	dovecot[82305]: auth(default): client in: AUTH	1	PLAIN	service=imap	 
secured	lip=127.0.0.1	rip=127.0.0.1	lport=143	rport=49879	resp=
	dovecot[82305]: auth-worker(default): pam(testuser,127.0.0.1): lookup  
service=imap
	dovecot[82305]: auth-worker(default): pam(testuser,127.0.0.1): #1/1  
style=1 msg=Password:

dovecot[82305]: auth(default): client out: OK   1   user=testuser
dovecot[82305]: auth(default): master in: REQUEST   8   82327   
1
dovecot[82305]: auth(default): passwd(testuser,127.0.0.1): lookup
	dovecot[82305]: auth(default): master out: USER	8	testuser	 
system_groups_user=testuser	uid=2001	gid=2001	home=/Volumes/ALMbpSpare/ 
People/a/testuser
	dovecot[82305]: imap-login: Login: user=, method=PLAIN,  
rip=127.0.

Re: [Dovecot] 1.2rc5 Panic: file virtual-sync.c

[Timo Sirainen]

On Jun 28, 2009, at 7:11 AM, e-frog wrote:


Timo Sirainen wrote:

On Mon, 2009-06-22 at 20:39 +0200, e-frog wrote:
Trying to find a condition to reproduce the above issue I've seen  
an imap process
consuming 100% CPU. Attaching gdb to the process I got the  
backtrace below.

..
#1  0xb7e9771c in virtual_sync_backend_boxes (ctx=0x935cca0) at  
virtual-sync.c:790


Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/86c32eb84dfa



Thanks Timo!

Could this have been also the root cause for the crash earlier  
reported?


No. It could only have caused infinite looping.

[Dovecot] Dovecot 1.2rc7 / Sieve Plugin problem / Namespaces

[reg9009]

Hi,

I've got a problem with Dovecot 1.2rc7 and a Sieve script which should
store eMails in a subfolder. It always fails with

Jun 28 14:56:43 deliver(): Error: sieve:
msgid=<4a47687d.30...@some.domain>: failed to store into mailbox '':
Invalid mailbox name
Jun 28 14:56:43 deliver(): Error: sieve: script
/home/dovecot/sieve/info/dovecot.sieve failed with unsuccessful implicit
keep

This is with dovecot-libsieve.

Same happens with cmusieve, though the message is slightly different:

Jun 28 14:55:39 deliver(): Info: cmusieve: Executing script
/home/dovecot/sieve/info/dovecot.sievec
Jun 28 14:55:39 deliver(): Info: sieve runtime error: Keep: Generic Error

Sieve script:

if header :comparator "i;ascii-casemap" :contains "X-Spam-Level" "*"  {
fileinto "INBOX/Junk";
stop;
}

I tried "INBOX.Junk", "Junk", etc., but no success.

Namespace section in dovecot.conf:

namespace private {
  separator = /
  prefix = INBOX/
  inbox = yes
  #hidden = yes
  #list=yes
}


Same configuration works with cmusieve and Dovecot 1.1.16. I assume some
problems with the namespace separator. Anyone got any ideas or got sieve
running with namespace separator "/" and prefix "INBOX"?

Regards,
Sebastian

Re: [Dovecot] 1.2rc5 Panic: file virtual-sync.c

[e-frog]

Timo Sirainen wrote:
> On Mon, 2009-06-22 at 20:39 +0200, e-frog wrote:
>> Trying to find a condition to reproduce the above issue I've seen an imap 
>> process
>> consuming 100% CPU. Attaching gdb to the process I got the backtrace below.
> ..
>> #1  0xb7e9771c in virtual_sync_backend_boxes (ctx=0x935cca0) at 
>> virtual-sync.c:790
> 
> Thanks, fixed: http://hg.dovecot.org/dovecot-1.2/rev/86c32eb84dfa
> 

Thanks Timo!

Could this have been also the root cause for the crash earlier reported?

Re: [Dovecot] ACLs, imap and launchd

[Axel Luttgens]

Le 28 juin 09 à 03:54, Timo Sirainen a écrit :


On Fri, 2009-06-26 at 10:33 +0200, Axel Luttgens wrote:

Wouldn't it be possible, for example, to consider using a system user
such as "nobody" (unless I'm wrong, it should be defined on any unix
flavor)?


I guess. Done: http://hg.dovecot.org/dovecot-1.2/rev/2db158dd88be


Wow! Thank you, Timo.

So, I tried the patch but unfortunately got this in system.log:

	org.dovecot[41675]: Error: User dump-capability is missing GID (see  
mail_gid setting)
	org.dovecot[41675]: Fatal: Invalid configuration in /usr/local/etc/ 
dovecot.conf

com.apple.launchd[1] (org.dovecot[41675]): Exited with exit code: 89
	com.apple.launchd[1] (org.dovecot): Throttling respawn: Will start in  
10 seconds

... and so on ...

Seems to be related to the checks in create_mail_process(), where it  
is relied on a value of -1 as an indicator for "unset".
Now, on OSX, user "nobody" has 4294967294/4294967294 for uid/gid, or  
-2/-2; on the other hand, group "nogroup" has a gid equal to  
4294967295, or... -1.


Defining some value for mail_gid in dovectot.conf, even if otherwise  
not needed, makes above problem disappear.


But again, this is somewhat artificial (the same way I had to create a  
system user with an uid/gid set to 65534/65534).


I thus tried this variant:

} else {
/* try to use some existing user. at least osx launchd
doesn't like non-existing users. */
struct passwd *pw;

/* written that way, this could be extended to some other
candidate system users (e.g. daemon?) */
if ( ((pw = getpwnam("nobody")) != NULL)
&& (pw->pw_uid != (uid_t)-1) && (pw->pw_gid != 
(gid_t)-1) )
{
args[0] = t_strdup_printf("uid=%s", 
dec2str(pw->pw_uid));
args[1] = t_strdup_printf("gid=%s", 
dec2str(pw->pw_gid));
}
}

and dovecot now launched without complaining, even with an unset  
mail_gid.


Of course, this "solves" the problem in the precise case of OSX; but  
should be OK with, for example, Redhat or Solaris as well.



Sincerely,
Axel

Re: [Dovecot] Capability COMPRESS implemented?

[Ed W]

Timo Sirainen wrote:

On Thu, 2009-06-25 at 23:21 +0100, Ed W wrote:
  

Yeah, not for next half a year at least. Anyway, it would basically need
istream and ostream implementations for zlib. istream implementation
kind of already exists in zlib plugin, except it's using gz*() functions
instead of doing everything in memory. So:
  
  
I might have missed the subtleties since it's a while since I wrote 
anything against the gz interface, but there shouldn't be much 
difference between interfaces I think?



I don't know. I've never written anything using the deflate/inflate*()
interfaces. I just quickly looked up from zlib.h that those are probably
what's needed.

  


I think what you see as a "stream" is just the API name for a memory 
buffer.  The input output variables point to a struct which is something 
like:


char *buffer_ptr;
long bytes_left_in_buffer;

As you call the function it consumes bytes from the input buffer and may 
optionally squirt some data into the output buffer.  The structs you 
pass are updated to show the new values.  The compress/decompress 
functions return a value which shows if it's finished doing it's thing 
or required more output buffer space, etc


I suppose the only subtlety is that the compressor (and decompressor) 
may keep some bytes in it's internal state (ie unflushed).  So if you 
ask it to compress the string "dovecot" and uncompress the ouput bytes 
you might only get "dove" (say).  The key thing is to call the flush 
function where it's necessary.  However, the unflushed characters are 
those the compressor thinks it can batch with later input, so clearly 
you minimise the amount of flushing when dealing with small input 
strings.  In terms of big picture compression though it's a very small 
decrease in efficiency, but clearly it's desirable to minimise flushes 
where possible (ie only at the end of each command output would be the 
obvious solution)


I don't know the internals of dovecot too well, but I would have thought 
that you would add this the network output abstraction.  So you 
presumably already buffer and spool command output to the network 
socket, now you simply run the output through gzip before each write and 
after each read.  Note there is some potential efficiency gains in 
compressing attachments slightly differently to other data, hence the 
compressor might potentially gain by being nearer the code which is 
generating network output (the decompressor on input data can clearly be 
right in the network input code) but my opinion is that this is barely 
relevant for real users with sensible size emails (the zlib dictionary 
sizes are just too small to get massive compression ratios)



Hopefully this is a fairly easy thing to insert into the current code path?

Cheers

Ed W

Re: [Dovecot] sievec error: "fileinto require missing"

[Thomas Leuxner]

On Sun, Jun 28, 2009 at 05:25:28AM -0400, Braden McDaniel wrote:
> .dovecot.sieve just looks like this:
> 
> $ cat .dovecot.sieve
> if header :contains ["List-Id"] ["dovecot.dovecot.org"]
> {
> fileinto "INBOX.dovecot";
> stop;
> }

You need to include the referenced functions in the script via require:

require ["include","copy","fileinto","vacation"];
#nclude :global "global.sieve";

In your case require require ["fileinto"]; will do at the top of the script.

Rgds
Thomas

[Dovecot] sievec error: "fileinto require missing"

[Braden McDaniel]

I'm getting this error when compiling .dovecot.sieve:

$ /usr/libexec/dovecot/sievec .dovecot.sieve .dovecot.sievec
Info: line 3: fileinto require missing

Unable to parse script: script errors:
line 3: fileinto require missing

.dovecot.sieve just looks like this:

$ cat .dovecot.sieve
if header :contains ["List-Id"] ["dovecot.dovecot.org"]
{
fileinto "INBOX.dovecot";
stop;
}

I'm probably doing something silly; but I don't see how what I've done
differs significantly from examples I've found.  And googling for
"fileinto require missing" just got me to the sievec source code.

What might be the problem here?

-- 
Braden McDaniel 

Re: [Dovecot] SSL / TLS

[Marko Weber | Salondigital.de]

Michael Orlitzky schrieb:

Timo Sirainen wrote:

On Fri, 2009-06-26 at 23:39 +0400, Proskurin Kirill wrote:

SSL just binds to special port(like 993 in IMAP by default).


No, SSL is a protocol, just like TLS. It doesn't bind to any ports.
http://wiki.dovecot.org/SSL



To illustrate, both SSL and TLS as implemented in Dovecot utilize "SSL 
certificates."


A typical "TLS" session will work as follows:

1  The client connects to the IMAP service on port 143, unencrypted.
2  The server announces that it speaks TLS.
3  The client says "Ok, let's talk encrypted."
4  Magic occurs, and the session becomes encrypted. This step is where
   your "SSL" certificate is used.
5  The rest of the session is encrypted.

/Usually/, when people refer to SSL as opposed to TLS, they mean IMAPS 
or POPS. These differ in that there's no "Hey, I speak TLS" step. It 
is assumed that the conversation will begin according to some secure 
protocol, kind of like when you connect to a web server on port 443.


1  The client connects to IMAPS on port 993, and performs the secure
   handshake. Your "SSL" certificate is used in here somewhere.
2  Once the handshake has completed, the rest of the session is secure.

When implementing IMAPS/POPS you will usually use a different port, 
because if you tried to talk plaintext to the server, it would appear 
to be speaking gibberish (whatever secure protocol is being used).


With TLS enabled on a normal IMAP port, the switch from plaintext to 
encrypted is optional. Although, it's usually a good idea to force 
TLS, too.


Much of the confusion comes from the fact that you can use either 
protocol, TLSv1 or SSLv3 after the "Hey I speak TLS" step. Likewise, 
you can use TLSv1 with IMAPS or POPS, though it's use will be implied 
and there will be no "Hey, I speak TLS" step. There's really no 
agreement amongst mail clients as to the meaning of "Use SSL" and "Use 
TLS."


You may find it easiest to concentrate on the one distinction: does 
the session begin encrypted, or does it switch from plaintext to 
encrypted at some point? Once you've answered that, either of the 
SSLv3 or TLSv1 protocols can be used, and they will both use your 
"SSL" certificate.


Ultimately, you may wind up using both, depending on your user base. 
Many versions of Outlook are screwy with regard to one or both of 
these methods.


From Outllok  Version 2007 u can choose between SSL / TLS in Settings 
of the mailaccount. In Outlook 2003 we experienced the only choosable 
SSL can also work

with TLS.
BUT, we found out, Outlook 2000 & 2002 cant work with any of our 
"forced" TLS Mailservers.
Also Microsofts ENTOURAGE or whatever named Client cant work with TLS 
and some "Mail" Clients from OS X, but latest do.

hope that helps

marko
--


*Marko Weber* | Administration

*SALON DIGITAL* Media GmbH
Rothenbaumchaussee 19a
20148 Hamburg

T. (040) 429 48 68 - 23
F. (040) 429 48 68 - 20

marko.we...@salondigital.de 
www.salondigital.de 

--
Geschäftsführung: Stephan Michalik, Ekkehart Opitz
Registergericht: Amtsgericht Hamburg, NR: HRB 78111

NOTE: This communication is confidential and is intended for the use of 
the individual or entity to which it is directed. It may contain 
information that is privileged and exempt from disclosure under 
applicable law. If you are not the intended recipient please notify us 
immediately. You should not copy it or disclose its contents to any 
other person.