[Dovecot] deleted-to-trash plugin problems

2012-07-24 Thread Steve Platt
We have a user who wants to use Outlook with our Dovecot IMAP server but 
doesn't like the way Outlook handles deletion with IMAP.


Ironically she would like Outlook to move the message to her Trash 
folder, just like Outlook does with "local" folders, I guess.


So I enabled the "deleted-to-trash" plugin (v0.3) on our Dovecot 1.2.17 
server (built for SPARC, solaris 10, btw).


The problem is that it doesn't seem to work; the message doesn't even 
appear to get marked for delete.


The imap log says: "opening Trash succeeded" and then nothing else!

I have found that there is a copy of the message in .Trash/tmp/ 
suggesting that the plugin may be bailing out part way through.


Has anyone any idea what's wrong please?

I'll attach the output of dovecot -n ...

Thanks,
Steve
# 1.2.17: /usr/local/etc/dovecot.conf
# OS: SunOS 5.10 sun4u  
base_dir: /var/run/dovecot/
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot-info.log
protocols: imap imaps managesieve
listen(default): *
listen(imap): *
listen(managesieve): *:2000
ssl_ca_file: /etc/ssl/certs/11230895.ca-bundle
ssl_cert_file: /etc/ssl/certs/bernstein.crt
ssl_key_file: /etc/ssl/private/bernstein.key
ssl_cipher_list: TLSv1+HIGH : !SSLv2 : RC4+MEDIUM : !aNULL : !eNULL : !3DES : 
@STRENGTH
verbose_ssl: yes
login_dir: /var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login
mail_location: maildir:~/Maildir
mail_debug: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve
mail_plugins(default): mail_log deleted_to_trash
mail_plugins(imap): mail_log deleted_to_trash
mail_plugins(managesieve): 
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve
lda:
  postmaster_address: postmas...@mrc-bsu.cam.ac.uk
  mail_plugins: sieve
  mail_plugin_dir: /usr/local/lib/dovecot/lda
  log_path: /var/log/dovecot-deliver.log
  info_log_path: /var/log/dovecot-deliver-info.log
  auth_socket_path: /var/run/dovecot/auth-master
auth default:
  mechanisms: plain login
  verbose: yes
  passdb:
driver: passwd-file
args: /var/dovecot/mrc-bsu/etc/passwd-file
  userdb:
driver: static
args: uid=vmail gid=vmail home=/var/dovecot/mrc-bsu/home/%u
  socket:
type: listen
client:
  path: /var/run/dovecot/auth-client
  mode: 438
master:
  path: /var/run/dovecot/auth-master
  mode: 384
  user: vmail
  group: vmail
plugin:
  mail_log_events: delete undelete expunge copy mailbox_delete mailbox_rename
  mail_log_fields: uid box msgid size subject
  sieve_dir: ~/sieve
  deleted_to_trash_folder: Trash


Re: [Dovecot] disabling SSLv2 in dovecot 1.2.17

2012-03-09 Thread Steve Platt

Hi Mark,

I think I may not have been clear enough in my query, sorry!

What I'm trying to do is to prevent SSLv2 connections being made to our IMAP 
server while allowing SSLv3 and TLSv1 connections. I think I've prevented the 
use of SSLv2 ciphers but this does not prevent SSLv2 protocol connections (as 
far as I can tell).

(Once connected, the SSLv2 client finds it has no ciphers so the session fails 
at that point but this is not enough to satisfy our security audit. I want to 
disable the use of the SSLv2 protocol itself, not just the SSLv2 ciphers)


steve.pl...@mrc-bsu.cam.ac.uk said:
> I see Dovecot2 had the following change a year or so ago, in file  src/
> login-common/ssl-proxy-openssl.c:
>
> -   SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL);
> +   SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
>
> I tried making the same change to dovecot1's src tree on our test system and
> it seems to have the desired effect ...

I'm testing this by using:

 openssl s_client -ssl2 -connect mailhost:993

This should fail immediately with "ssl handshake failure" (for a happy audit!).

Thanks again,
Steve



[Dovecot] disabling SSLv2 in dovecot 1.2.17

2012-03-08 Thread Steve Platt

I've set up a list of ciphers that excludes SSLv2 ciphers (and other weak 
ones) in the hope of preventing SSLv2 connections:

 ssl_cipher_list = TLSv1+HIGH : !SSLv2 : RC4+MEDIUM : !aNULL : !eNULL : !3DES 
: @STRENGTH

However, this doesn't prevent the SSLv2 connection being allowed as our Nessus 
scans show and I'm tasked with trying to plug that "hole".

I see Dovecot2 had the following change a year or so ago, in file 
src/login-common/ssl-proxy-openssl.c:

-   SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL);
+   SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);

I tried making the same change to dovecot1's src tree on our test system and 
it seems to have the desired effect; however I am very hesitant  about putting 
this into our production system without seeking advice here first :-)

Have I missed anything that's obviously bad about doing this please?

Thanks again,
Steve Platt



Re: [Dovecot] migrating/converting from system users -> virtual users

2012-03-08 Thread Steve Platt

Thank you for your help, Timo.

> use Dovecot v2.0's dsync

I gather from your reply that it's OK to use Dovecot 2.0 utilities (eg dsync) 
on a dovecot (v1) installation; presumably with its own configuration file(s).

> You could set mail_drop_priv_before_exec=yes ... chgrp vmail ...

Yes, I think we could do that; I should have thought of it myself, thanks 
again.

I think there was one other problem with the automatic conversion which I've 
now remembered: I note that the first time a user connects to th eimap service 
dovecot creates their (virtual) home directory for them with all the right 
permissions. That's great and I use the existence of that directory as an 
indication to our MTA that the user wants delivery into the dovecot store 
rather than their old system mailbox.  However once I tried using the convert 
plugin the process fails because (it seems) the conversion tries to take place 
before the home directory has been created.

Is there any configuration change that might change this order?

Can I configure the convert plugin on LDA delivery, for example, instead of as 
part of the "protocol imap" section?

Many thanks,
Steve Platt



[Dovecot] migrating/converting from system users -> virtual users

2012-02-28 Thread Steve Platt

Hello all,

We currently have a traditional mail server  where all users have system 
accounts (ie entries in the NIS passwd map) and mbox-format mail folders in 
their (system) home directories.

I'm trying to setup a dovecot server in which we want all users to have 
"virtual" accounts (in dovecot) and no entry in the passwd file at all (ie no 
access to the mail server).

This is for security reasons, we want to imagine that users connecting to the 
mail server in future will not be able to access any resources on the server 
other than access their email messages. To this end we've set up a "vmail" 
user that owns all the messages in the Maildir directories.


Most of this is working but I'm stuck on how to convert users' mail folders 
from the existing setup to the new one. I'm using the convert plugin but of 
course the problem is that the plugin executes as the "vmail" user and cannot 
access the existing mail folders that belong to the users: and I'd be worried 
if it could, of course!

So I've converted a few users already by making copies of their old-world 
mailboxes, changing the ownership of the copies and pointing the convert 
plugin to these copies, instead of the originals.

This works (modulo the dreaded "timeouted" error messages) but is very ugly.

So I tried looking at the convert-tool but can't find a man page for it so am 
not sure what I'm doing with it!

I have the idea that I should be able to run some command (as a privileged 
user) on the mail server and have it do the conversion for me, changing the 
ownership/permissions on the way.

Can convert-tool do this?

I'd prefer to go with the automatic (plugin) conversion if I can bodge the 
ownership issues somehow. Failing that, some tool or script may be the next 
best answer.

This is Dovecot 1.2 by the way on Solaris 10.

Any suggestions would be welcome!

Steve Platt