[Dovecot] dovecot-antispam crm114 config

[Peter Fern]

Hi list,
Does anyone have a working crm114 config for dovecot-antispam?  I have
mailreaver running perfectly otherwise, but it doesn't seem to be called
correctly from dovecot-antispam - the css files show no change.  Piping
a message to the command...

`/usr/share/crm114/mailreaver.crm --good -u
/shared/domains/domain.tld/users/pfern/.crm/`

works as expected, and the logs don't indicate anything useful that I
can see as to why it isn't working from dovecot.

Log follows:

Nov 11 12:56:48 mx0 dovecot: imap-login: Login: user=<[EMAIL PROTECTED]>,
method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): Loading modules
from directory: /usr/lib64/dovecot/imap
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): Module loaded:
/usr/lib64/dovecot/imap/lib90_antispam_plugin.so
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): Effective
uid=x, gid=x, home=/shared/domains/domain.tld/users/pfern
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: plugin
initialising (unknown)
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: "trash"
is trash folder
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: "Trash"
is trash folder
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: "Deleted
Items" is trash folder
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: "-SPAM-"
is spam folder
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam:
"-UNSURE-" is unsure folder
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: reaver
binary set to /usr/share/crm114/mailreaver.crm
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: reaver
extra arg -u
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: reaver
extra arg /shared/domains/domain.tld/users/pfern/.crm/
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: signature
header line is "X-CRM114-CacheID"
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): maildir:
data=/shared/domains/domain.tld/users/pfern/.maildir:INDEX=/var/lib/dovecot/indexes/domain.tld/p/pfern
Nov 11 12:56:48 mx0 dovecot: IMAP([EMAIL PROTECTED]): maildir++:
root=/shared/domains/domain.tld/users/pfern/.maildir,
index=/var/lib/dovecot/indexes/domain.tld/p/pfern, control=,
inbox=/shared/domains/domain.tld/users/pfern/.maildir
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam:
mailbox_is_unsure(INBOX.Noojee): 0  
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam:
mailbox_is_trash(-UNSURE-): 0
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam:
mailbox_is_trash(INBOX.Noojee): 0
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: mail
copy: from trash: 0, to trash: 0
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam:
mailbox_is_spam(-UNSURE-): 0
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam:
mailbox_is_spam(INBOX.Noojee): 0
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam:
mailbox_is_unsure(-UNSURE-): 1
Nov 11 12:56:56 mx0 dovecot: IMAP([EMAIL PROTECTED]): antispam: mail
copy: src spam: 0, dst spam: 0, src unsure: 1

[Dovecot] NFS Unbreakable lock issues

[Rod Treweek]

Hello All,

We are struggling to find a solution to a problem we are encountering
with a load-balanced email setup. Currently, we have a Coyote loadbalancer,
and 3 Postfix/Dovecot nodes that then get their information from a mysql
database.  The problem is that after a couple weeks, we start seeing NFS
locking issues occur, which then takes email completely down, requiring a
site visit to basically do an interactive mode reboot to shut off NFS so
that we can remount the filesystem again.  We have our mailstore on an
Aberdeen NAS which is accessed over NFS v. 4.

 Dovecot version 1.1.2

Here's the relevant mysql string:

grep -v '^ *\(#.*\)\?$' dovecot-mysql.conf
driver = mysql
connect = host=X.X.X.X dbname=Something user=Something password=Something
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/',
maildir) as userdb_home, concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir)
as userdb_mail, 143 as userdb_uid, 143 as userdb_gid, concat('*:bytes=',
floor(quota*1024)) AS quota_rule FROM mailbox WHERE username = '%u' AND
active = '1'
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as maildir, 143 AS uid,
143 AS gid, concat('*:bytes=', floor(quota*1024)) AS quota_rule FROM mailbox
WHERE username = '%u' AND active = '1'


And here's what our configuration is on each of the nodes:

 dovecot -n
# 1.1.2: /usr/local/etc/dovecot.conf
protocols: imap pop3
ssl_ca_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_cert_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_key_file: /usr/local/etc/dovecot/certs/tdpserver.key
ssl_parameters_regenerate: 0
ssl_cipher_list: ALL:!LOW:!SSLv2
disable_plaintext_auth: no
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(pop3): /usr/local/libexec/dovecot/pop3-login
login_user: postfix
login_greeting: Something witty here..
login_process_per_connection: no
login_max_connections: 512
max_mail_processes: 2048
mail_max_userip_connections: 50
verbose_proctitle: yes
first_valid_uid: 69
last_valid_uid: 500
first_valid_gid: 69
last_valid_gid: 500
mail_access_groups: postfix
mail_privileged_group: postfix
mail_location:
mbox:/NFS1MAILDIR/mailSysV2/%d/%u:INDEX=/usr/local/mail/indexes/%d/%1n/%n
mmap_disable: yes
dotlock_use_excl: no
mail_nfs_storage: yes
mail_nfs_index: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
imap_client_workarounds(default): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(imap): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(pop3):
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
auth default:
  mechanisms: login plain
  user: dovecot
  passdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
  userdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix
master:
  path: /var/run/dovecot/auth-master
  mode: 384
  user: dovecot
  group: dovecot
plugin:
  quota: dict:user::proxy::quota
  imap_quota: dict:user::proxy::quota
  quota_rule: *:storage=528576
dict:
  quota: mysql:/usr/local/etc/dovecot/dovecot-dict-quota.conf



Any help you can offer is greatly appreciated, as well as opinions on any
other 'validated' postfix/dovecot email enterprise design solutions.

Thanks Very Much In Advance,

R.T

[Dovecot] Unbreakable NFS locking issues...

[Rod Treweek]

Hello All,

We are struggling to find a solution to a problem we are encountering
with a load-balanced email setup. Currently, we have a Coyote loadbalancer,
and 3 Postfix/Dovecot nodes that then get their information from a mysql
database.  The problem is that after a couple weeks, we start seeing NFS
locking issues occur, which then takes email completely down, requiring a
site visit to basically do an interactive mode reboot to shut off NFS so
that we can remount the filesystem again.  We have our mailstore on an
Aberdeen NAS which is accessed over NFS v. 4.

 Dovecot version 1.1.2

Here's the relevant mysql string:

grep -v '^ *\(#.*\)\?$' dovecot-mysql.conf
driver = mysql
connect = host=X.X.X.X dbname=Something user=Something password=Something
password_query = SELECT username as user, password,
concat('/NFS1MAILDIR/mailSysV2/', maildir) as userdb_home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as userdb_mail, 143 as
userdb_uid, 143 as userdb_gid, concat('*:bytes=', floor(quota*1024)) AS
quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
user_query = SELECT concat('/NFS1MAILDIR/mailSysV2/', maildir) as home,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as mail,
concat('maildir:/NFS1MAILDIR/mailSysV2/', maildir) as maildir, 143 AS uid,
143 AS gid, concat('*:bytes=', floor(quota*1024)) AS quota_rule FROM mailbox
WHERE username = '%u' AND active = '1'


And here's what our configuration is on each of the nodes:

 dovecot -n
# 1.1.2: /usr/local/etc/dovecot.conf
protocols: imap pop3
ssl_ca_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_cert_file: /usr/local/etc/dovecot/certs/tdpserver.crt
ssl_key_file: /usr/local/etc/dovecot/certs/tdpserver.key
ssl_parameters_regenerate: 0
ssl_cipher_list: ALL:!LOW:!SSLv2
disable_plaintext_auth: no
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(pop3): /usr/local/libexec/dovecot/pop3-login
login_user: postfix
login_greeting: Something witty here..
login_process_per_connection: no
login_max_connections: 512
max_mail_processes: 2048
mail_max_userip_connections: 50
verbose_proctitle: yes
first_valid_uid: 69
last_valid_uid: 500
first_valid_gid: 69
last_valid_gid: 500
mail_access_groups: postfix
mail_privileged_group: postfix
mail_location:
mbox:/NFS1MAILDIR/mailSysV2/%d/%u:INDEX=/usr/local/mail/indexes/%d/%1n/%n
mmap_disable: yes
dotlock_use_excl: no
mail_nfs_storage: yes
mail_nfs_index: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
imap_client_workarounds(default): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(imap): delay-newmail netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(pop3):
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
auth default:
  mechanisms: login plain
  user: dovecot
  passdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
  userdb:
driver: sql
args: /usr/local/etc/dovecot-mysql.conf
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix
master:
  path: /var/run/dovecot/auth-master
  mode: 384
  user: dovecot
  group: dovecot
plugin:
  quota: dict:user::proxy::quota
  imap_quota: dict:user::proxy::quota
  quota_rule: *:storage=528576
dict:
  quota: mysql:/usr/local/etc/dovecot/dovecot-dict-quota.conf



Any help you can offer is greatly, greatly appreciated, as well as opinions
on any other 'validated' postfix/dovecot email enterprise design solutions.

Thanks Very Much In Advance,

R.T

Re: [Dovecot] Another dovecot-antispam plugin can't call dspam

[Eugene]

Hi  Johannes,

From: "Johannes Berg" <[EMAIL PROTECTED]>


> Do you plan to implement 'out of band' dspam calling?
> BTW maybe there is no need for a separate 'queue' folder especially as 
> we
> only need a message signature. I think it can be stored in some buffer 
> array

> so as the dspam calls are made i.e. during idle time (or during final
> cleanup at the latest).



Well, I tried doing that with the signature-log backend, but that seemed
somewhat problematic to me although somebody said it actually works for
him.


Well, the performance of current approach seems acceptable, so it is 
probably not worth the trouble.




Thanks, I've added the Makefile patch, but the other one I'm not too
sure about, it seems it would print things twice if the loop actually
looped, so I left it for now. Also, your code can access
buf[sizeof(buf)] which would be a buffer overrun.


My idea was that if the loop actually loops (i.e. more that 1024 bytes 
returned), we just log several lines in debug log.

Sorry for buffer overrun, we have to check readsize of course.
Or just pass sizeof(buf)-1 to read()

Eugene 

Re: [Dovecot] antispam plugin claims "antispam signature not found"

[Eugene]

Jakob Curdes wrote

Some weeks ago I asked a question on the antispam plugin; obviously
nobody could help me. I just worked on it again but made no progress.
Is actually anybody out there running the antispam plugin with dspam?? I
am willing to write a Wiki page for configuring this as soon as I get it
to work.
.
- as soon as I move a message into the spam folder it gives an error
message saying "antispam signature not found"


Just had this error myself. In my case, the cause was a large spam message 
(above the configured MaxMessageSize parameter for DSPAM) that was skipped 
during tests and thus no signature was added. Might this be true in your 
case?


As a general suggestion for Johannes: maybe it is better to ignore this 
error silently, just move the message and don't call DSPAM?



I checked that the given location for the dspam executable is correct,
that the user executing it (dovecot?) is actually able to execute dspam
and that dspam trusts this user. I triple-checked that the signature is
configured correctly. I have lines like



X-DSPAM-Signature: 1,49084a24139132188715614


Another guess: if that comma is not a misprint, something is wrong in your 
setup.


Regards
Eugene 

Re: [Dovecot] First release (v0.1.0) of the new Sieve implementation for Dovecot v1.2

[Stephan Bosch]

Edgar Fuß schreef:
Oh yes sorry, indeed ./configure generates dovecot-config.in from  
dovecot-config.in.in (been a while since I looked at this). Upon  
executing 'make' it is transformed into the definitive dovecot-config  
using the following make rule (Makefile.am in top Dovecot source dir):

Yes, after (pkgsrc) make build it's there.


For compilation of these tools and the testsuite, the fully built sources
are needed because the Dovecot static libraries are linked  

But these are all in .../lib/dovecot (/usr/pkg/lib/dovecot, in my case),
aren't they?
Normally, the Dovecot libraries are not installed (just compiled in to 
the various executables). Unless something was changed in the Makefile 
structure, that is still the case at your end. But, I have no experience 
with BSD or pkgsrc whatsoever, so I really wouldn't know for sure.



If you care only for the Sieve plugin, this should not not matter.

I'm mostly after the plugin.

BTW, I am wondering: did you do exactly the same for the old cmusieve  
before? And you didn't encounter any problems?

With cmusieve, $dovecotdir pointed to .../lib/dovecot, not the source tree.
I have re-enabled the support for compiling dovecot-libsieve against 
Dovecot headers:


http://hg.rename-it.nl/dovecot-libsieve/rev/36e00217bdd2

From what I've understood from you thus far, this should give you the 
ability to compile it again as you did before with cmusieve.


Regards,

--
Stephan Bosch
[EMAIL PROTECTED]

Re: [Dovecot] Dovecot and Bogofilter

[Matthias Andree]

On Mon, 10 Nov 2008, Matthias-Christian Ott wrote:

> > it's not quite clear to me how this would work with bogofilter as a
> > mailbox_transport - bogofilter isn't designed to do final delivery.
> > 
> > It's also not quite clear to me why people would use procmail. Although
> > defended by its maintainers, it's an unusable and unconfigurable piece
> > of software from ancient past -- getting error handling right in
> > procmail is next to impossible, requires forfeiting :e rules and
> > bloating procmailrc with explicit error handling recipes.
> 
> If you haven't puked today, just look at their source code and programming
> style. I think the configuration and exit code handling is not the worst
> problem in this software.

I know that I don't want to read that code. It looks like something in
between a "dirty C tricks to squeeze the final cycle from compilers that
predate even peephole optimization" and a submission to obfuscated C
contest. User interface? Fallthrough behaviour on delivery errors?
Nevermind how randomly mail is spread across your mailboxen :-)

> > If you want something and Dovecot's deliver doesn't fit your needs,
> > consider maildrop, 
> 
> Looks a bit bloated to me.

Nevermind the bloated build, it works like a charm and has a rather
concise source (if you read a bit of C++, that is).

> > Bogofilter has an "integrating-with-postfix" document in the doc/
> > directory that shows how to use Postfix's content_filter and does not
> > need procmail. Unfortunately, it does not show how to integrate updates;
> > there are several approaches to achieve that. One way is to use separate
> > mailboxes where users can send mail to and where they are picked up by
> > cron - best when using Dovecot is probably to make users move spam into
> > particular folders via IMAP.
> 
> I read that document some days ago, but the content_filter approach
> looks strange to me, because they use sendmail to reinject the E-Mail
> in the queue.

Well, I co-authored that document, but it's just a refined version of
the "Simple Content Filter" as per Postfix's FILTER_README... check


Postfix's content_filter=... setting diverts the mail from regular
routing, and the sendmail command (without -t!) reinjects with original
headers and recipients (from envelope) for then regular routing.

Looks scary to some, but works.

BTDT, although I've moved on to amavisd-new since. Saves the hassle of
training spamfilters with virucide fodder...

-- 
Matthias Andree

Re: [Dovecot] Dovecot setup -correction

[Geoff Powell]

as you can see in the config the dir structure on the drive is
/var/mail/folders/user and not /var/mail/user as I have below. Sorry. Also
all permissions are set with user as owner and mail as group with rw
permissions.

Thanks,
Geoff

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Geoff Powell
Sent: Monday, November 10, 2008 3:51 PM
To: dovecot@dovecot.org
Subject: [Dovecot] Dovecot setup

Hello,

I am trying to set up dovecot for IMAP where I have a few maildirs. 
I'm using version 1.0.10.

Basically one for each email account I have (3 at the moment).
Call them account1, account2, and account3.

I have the basic maildir location as /var/mail/user/ and I set up .Account1
.Account2 and .Account3 under my user.

So it looks like this.

/var/mail/user/new/
/var/mail/user/cur/
/var/mail/user/dovecot files
/var/mail/user/.Account1
/var/mail/user/.Account1/new/
/var/mail/user/.Account1/cur/
/var/mail/user/.Account1/dovecot files
/var/mail/user/.Account2
/var/mail/user/.Account2/new/
/var/mail/user/.Account2/cur/
/var/mail/user/.Account2/dovecot files
/var/mail/user/.Account3
/var/mail/user/.Account3/new/
/var/mail/user/.Account3/cur/
/var/mail/user/.Account3/dovecot files

The mail gets delivered fine with fetchmail/procmail in maildir format under
.Account1 2 or 3 but I can't get dovecot to index it (ie move it to new so
that it shows up on the client - outlook). My config looks like the
following:

# 1.0.10: /etc/dovecot/dovecot.conf

log_timestamp: %Y-%m-%d %H:%M:%S

protocols: imap imaps pop3 pop3s

login_dir: /var/run/dovecot/login

login_executable(default): /usr/lib/dovecot/imap-login

login_executable(imap): /usr/lib/dovecot/imap-login

login_executable(pop3): /usr/lib/dovecot/pop3-login

mail_privileged_group: mail

mail_location: maildir:/var/mail/folders/%u

mail_executable(default): /usr/lib/dovecot/imap

mail_executable(imap): /usr/lib/dovecot/imap

mail_executable(pop3): /usr/lib/dovecot/pop3

mail_plugin_dir(default): /usr/lib/dovecot/modules/imap

mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap

mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3

pop3_uidl_format(default):

pop3_uidl_format(imap):

pop3_uidl_format(pop3): %08Xu%08Xv

auth default:

  passdb:

  driver: pam

  userdb:

  driver: passwd


Any help would be appreciated. TIA,

Geoff

[Dovecot] Dovecot setup

[Geoff Powell]

Hello,

I am trying to set up dovecot for IMAP where I have a few maildirs. 
I'm using version 1.0.10.

Basically one for each email account I have (3 at the moment).
Call them account1, account2, and account3.

I have the basic maildir location as /var/mail/user/ and I set up .Account1
.Account2 and .Account3 under my user.

So it looks like this.

/var/mail/user/new/
/var/mail/user/cur/
/var/mail/user/dovecot files
/var/mail/user/.Account1
/var/mail/user/.Account1/new/
/var/mail/user/.Account1/cur/
/var/mail/user/.Account1/dovecot files
/var/mail/user/.Account2
/var/mail/user/.Account2/new/
/var/mail/user/.Account2/cur/
/var/mail/user/.Account2/dovecot files
/var/mail/user/.Account3
/var/mail/user/.Account3/new/
/var/mail/user/.Account3/cur/
/var/mail/user/.Account3/dovecot files

The mail gets delivered fine with fetchmail/procmail in maildir format under
.Account1 2 or 3 but I can't get dovecot to index it (ie move it to new so
that it shows up on the client - outlook). My config looks like the
following:

# 1.0.10: /etc/dovecot/dovecot.conf

log_timestamp: %Y-%m-%d %H:%M:%S

protocols: imap imaps pop3 pop3s

login_dir: /var/run/dovecot/login

login_executable(default): /usr/lib/dovecot/imap-login

login_executable(imap): /usr/lib/dovecot/imap-login

login_executable(pop3): /usr/lib/dovecot/pop3-login

mail_privileged_group: mail

mail_location: maildir:/var/mail/folders/%u

mail_executable(default): /usr/lib/dovecot/imap

mail_executable(imap): /usr/lib/dovecot/imap

mail_executable(pop3): /usr/lib/dovecot/pop3

mail_plugin_dir(default): /usr/lib/dovecot/modules/imap

mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap

mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3

pop3_uidl_format(default):

pop3_uidl_format(imap):

pop3_uidl_format(pop3): %08Xu%08Xv

auth default:

  passdb:

  driver: pam

  userdb:

  driver: passwd


Any help would be appreciated. TIA,

Geoff

Re: [Dovecot] Dovecot and Bogofilter

[Matthias-Christian Ott]

Patrick Nagel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Matthias
> 
> Matthias Andree wrote:
> > On Mon, 10 Nov 2008, Patrick Nagel wrote:
> >> The problem with modifying the mail after reclassification persists, hope 
> >> this
> >> can be solved. Then I could also finally move from
> >> postfix-procmail-bogofilter-cron-dovecot to
> >> postfix-deliver-antispam-bogofilter-dovecot. :)
> > 
> > Hi,
> > 
> > it's not quite clear to me how this would work with bogofilter as a
> > mailbox_transport - bogofilter isn't designed to do final delivery.
> > 
> > It's also not quite clear to me why people would use procmail. Although
> > defended by its maintainers, it's an unusable and unconfigurable piece
> > of software from ancient past -- getting error handling right in
> > procmail is next to impossible, requires forfeiting :e rules and
> > bloating procmailrc with explicit error handling recipes.
> 
> You're right, and that's why I don't want to continue using it. It had a lot 
> of
> security issues, and the syntax of procmailrc looked like a bad joke to me 
> when
> I encountered it for the first time.

I think the syntax is not that worse if got a bit used to it. Even this
exitcode issues are just a matter of standardisation. But look at this
(taken from procmail.c):

[...]
int main(argc,argv)int argc;const char*const argv[];
{ register char*chp,*chp2;
#if 0   /* enable this if you want to trace procmail */
  kill(getpid(),SIGSTOP);/*raise(SIGSTOP);*/
#endif
  newid();
  ;{ int presenviron,override;char*fromwhom=0;
 const char*idhint=0;gid_t egid=getegid();
 presenviron=Deliverymode=mailfilter=override=0;
 Openlog(procmailn,LOG_PID,LOG_MAIL); /* for the syslogd */
 if(argc)  /* sanity check, any argument at all? */
  { Deliverymode=!!strncmp(lastdirsep(argv0=argv[0]),procmailn,
 STRLEN(procmailn));
[...]

The whole source code looks like this. I mean, who is supposed to
read this and who wrote this? I don't want to use such software, it's
a nightmare.
 
> Not being able to pipe mail through an arbitrary program surely makes sieve
> more secure, but it also makes things much more complicated sometimes. Also I
> think beginners tend to use procmail, just because in many guides / tutorials 
> /
> howtos it's the LDA of choice. (I, for example, started out with this howto:
> http://www.gentoo-wiki.info/HOWTO_Email_System_for_the_Home_Network )
> 
> > If you want something and Dovecot's deliver doesn't fit your needs,
> > consider maildrop, 
> 
> I didn't even know about it until very recently. ;)

$ aptitude search ~dprocmail
[...]
p   maildrop
- mail delivery agent with filtering abilities
[...]

That's how I found it ;).
 
> > Bogofilter has an "integrating-with-postfix" document in the doc/
> > directory that shows how to use Postfix's content_filter and does not
> > need procmail. Unfortunately, it does not show how to integrate updates;
> > there are several approaches to achieve that. One way is to use separate
> > mailboxes where users can send mail to and where they are picked up by
> > cron - best when using Dovecot is probably to make users move spam into
> > particular folders via IMAP.
> 
> That's how I'm doing it, but surely the Antispam plugin is a nicer (and more
> user-friendly) approach - the classification direction (Spam->Ham or 
> Ham->Spam)
> is determined by the source and target mailbox.

You could simply run the cron on your SPAM folder and also delete old
spam mail during that run. That's how I initially planned it.
 
> Patrick.

Regards,
Matthias-Christian

Re: [Dovecot] Dovecot and Bogofilter

[Matthias-Christian Ott]

Matthias Andree wrote:
> On Mon, 10 Nov 2008, Patrick Nagel wrote:
> 
> > Thorsten Vollmer wrote:
> > > On Sun, 2008-11-09 at 22:39 +0100, Matthias-Christian Ott wrote:
> > >> An other problem is that each mail needs to be initially classified and
> > >> due to the fact that sieve is not able to execute external programmes,
> > >> deliver has to do this task. I'm currently thinking of possibilities to
> > >> implement this, so far I came up with the following:
> > >>
> > >>   1. Write a generic pipe plugin which can execute an arbitrary number of
> > >>  programmes. The problem with this is that I'm not sure how to
> > >>  integrate this is in Dovecot's configuration file. I thought of
> > >>  something like this: pipe = prg1 | prg2
> > > 
> > > You do not need a plugin if you do the classification before the
> > > delivery: MTA | classification | LDA
> > 
> > With postfix, just add bogofilter as transport to master.cf and make it the
> > 'mailbox_transport'.
> > 
> > The problem with modifying the mail after reclassification persists, hope 
> > this
> > can be solved. Then I could also finally move from
> > postfix-procmail-bogofilter-cron-dovecot to
> > postfix-deliver-antispam-bogofilter-dovecot. :)
> 
> Hi,
> 
> it's not quite clear to me how this would work with bogofilter as a
> mailbox_transport - bogofilter isn't designed to do final delivery.
> 
> It's also not quite clear to me why people would use procmail. Although
> defended by its maintainers, it's an unusable and unconfigurable piece
> of software from ancient past -- getting error handling right in
> procmail is next to impossible, requires forfeiting :e rules and
> bloating procmailrc with explicit error handling recipes.

If you haven't puked today, just look at their source code and programming
style. I think the configuration and exit code handling is not the worst
problem in this software.
 
> If you want something and Dovecot's deliver doesn't fit your needs,
> consider maildrop, 

Looks a bit bloated to me.
 
> Bogofilter has an "integrating-with-postfix" document in the doc/
> directory that shows how to use Postfix's content_filter and does not
> need procmail. Unfortunately, it does not show how to integrate updates;
> there are several approaches to achieve that. One way is to use separate
> mailboxes where users can send mail to and where they are picked up by
> cron - best when using Dovecot is probably to make users move spam into
> particular folders via IMAP.

I read that document some days ago, but the content_filter approach
looks strange to me, because they use sendmail to reinject the E-Mail
in the queue.

Regards,
Matthias-Christian 

Re: [Dovecot] ocfs2 dovecot

[Robert Schetterer]

Robert Schetterer schrieb:
> Hi Timo,
> in the wiki there is only talked about gfs filesystem
> are there any known breaking problems using ocfs2 with dovecot ?
> 
> 
> in my vmware setup ocfs2 seems to be more
> debian/ubuntu config friendly like gfs
> dont got gfs to run, perhaps this might be better on suse/centos/redhat
> but i simply want to use ubuntu hardy server version
> 
ups
there is
ocfs2 in the wiki
http://wiki.dovecot.org/MailLocation/SharedDisk
anybody with negative thoughts about using dovecot
with drbd ocfs2 on 2 node mailserver ?

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

[Dovecot] ocfs2 dovecot

[Robert Schetterer]

Hi Timo,
in the wiki there is only talked about gfs filesystem
are there any known breaking problems using ocfs2 with dovecot ?


in my vmware setup ocfs2 seems to be more
debian/ubuntu config friendly like gfs
dont got gfs to run, perhaps this might be better on suse/centos/redhat
but i simply want to use ubuntu hardy server version

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Dovecot] First release (v0.1.0) of the new Sieve implementation for Dovecot v1.2

[Edgar Fuß]

> Oh yes sorry, indeed ./configure generates dovecot-config.in from  
> dovecot-config.in.in (been a while since I looked at this). Upon  
> executing 'make' it is transformed into the definitive dovecot-config  
> using the following make rule (Makefile.am in top Dovecot source dir):
Yes, after (pkgsrc) make build it's there.

> For compilation of these tools and the testsuite, the fully built sources
> are needed because the Dovecot static libraries are linked  
But these are all in .../lib/dovecot (/usr/pkg/lib/dovecot, in my case),
aren't they?

> If you care only for the Sieve plugin, this should not not matter.
I'm mostly after the plugin.

> BTW, I am wondering: did you do exactly the same for the old cmusieve  
> before? And you didn't encounter any problems?
With cmusieve, $dovecotdir pointed to .../lib/dovecot, not the source tree.

[Dovecot] How to specify /var/spool/mail/m/i/mike

[Network Operations]

I was wondering if somebody could tell me how I can tell dovecot (IMAP) 
to read users' mail boxes at /var/spool/mail/{1st char}/{2nd 
char}/username .


For example:
Mailbox for user 'mike' would be located at /var/spool/mail/m/i/mike
'karen' would be at /var/spool/mail/k/a/karen
etc...

Is this possible is version 1.1.6?

Please advise.

Thanks
JB

Re: [Dovecot] First release (v0.1.0) of the new Sieve implementation for Dovecot v1.2

[Stephan Bosch]

Edgar Fuß wrote:

Dovecot needs to be compiled first for this to work.

Yes, of course.
If Dovecot is compiled, Dovecot's top source directory should contain 
the dovecot-config file (as explained below). Strange that it is missing 
at your end.



The dovecot-config file is produced upon executing ./configure.

Not with me. I get a dovecot-config.in generated from dovecot-config.in.in 
during configure and a .../lib/dovecot/dovecot-config installed during install.
Oh yes sorry, indeed ./configure generates dovecot-config.in from 
dovecot-config.in.in (been a while since I looked at this). Upon 
executing 'make' it is transformed into the definitive dovecot-config 
using the following make rule (Makefile.am in top Dovecot source dir):


dovecot-config: dovecot-config.in Makefile
cat dovecot-config.in | sed \
-e "s|^moduledir=|moduledir=$(moduledir)|" \
-e "s|^dovecot_incdir=|dovecot_incdir=$(pkgincludedir)|" > 
dovecot-config


So, if you are pointing dovecot-sieve's --with-dovecot to a completely 
built Dovecot source tree, it should find the dovecot-config file. If it 
is missing for some reason or you do not want to build dovecot 
completely, executing 'make dovecot-config' in the dovecot source tree 
should produce the dovecot-config file. However, as I explain below, a 
fully built Dovecot source tree is currently necessary to build the 
Sieve package.



This is no different from the old cmusieve plugin.

In pkgsrc, this was always built against headers only.


I can change this for the next release

Would probably be nice.

I'll give it a look.


Btw: What exactly does your sieve need dovecot sources for? It looks a bit hard 
to get this done correctly with pkgsrc. Do you just need an unpacked (patched?) 
source or does it have to be configured?
The sources are needed to build the command line tools like sievec, 
sieved and sieve-test. Also the testsuite needs it. So, if I change the 
package to allow building against the bare headers, these things cannot 
be compiled. For compilation of these tools and the testsuite, the fully 
built sources are needed because the Dovecot static libraries are linked 
into these binaries. If you care only for the Sieve plugin, this should 
not not matter.


BTW, I am wondering: did you do exactly the same for the old cmusieve 
before? And you didn't encounter any problems?


Regards,

Stephan.

Re: [Dovecot] First release (v0.1.0) of the new Sieve implementation for Dovecot v1.2

[Edgar Fuß]

> Dovecot needs to be compiled first for this to work.
Yes, of course.

> The dovecot-config file is produced upon executing ./configure.
Not with me. I get a dovecot-config.in generated from dovecot-config.in.in 
during configure and a .../lib/dovecot/dovecot-config installed during install.

> This is no different from the old cmusieve plugin.
In pkgsrc, this was always built against headers only.

> I can change this for the next release
Would probably be nice.

Btw: What exactly does your sieve need dovecot sources for? It looks a bit hard 
to get this done correctly with pkgsrc. Do you just need an unpacked (patched?) 
source or does it have to be configured?

[Dovecot] nfs_flush_fcntl failed: No locks available

[Mark Zealey]

Hi there,

I've been seeing this error in our logs quite frequently on our nfs
storage (v3):

2008-11-10T13:24:26+00:00 mail8 dovecot: IMAP([EMAIL PROTECTED]):
nfs_flush_fcntl: fcntl(/var/spool/mail/XXX/Maildir/dovecot.index.cache,
F_RDLCK) failed: No locks available

Which is because we don't run lockd on our servers. Why is dovecot
trying to use fcntl() ? I explicitly set it to use dotlocks in the
dovecot config:

# 1.1.6: /etc/dovecot.conf
# OS: Linux 2.6.18-92.el5 i686 CentOS release 5.2 (Final)
base_dir: /var/run/dovecot/
protocols: imap pop3
mail_location: maildir:~/Maildir
mmap_disable: yes
mail_nfs_storage: yes
mail_nfs_index: yes
lock_method: dotlock
maildir_copy_preserve_filename: yes
mbox_write_locks: dotlock

This happens for both pop and imap (however more frequently with imap).

Thanks,

Mark

--
Mark Zealey -- Shared Hosting Team Leader
Product Development * Webfusion
123-reg.co.uk, webfusion.co.uk, donhost.co.uk, supanames.co.uk

This mail is subject to http://www.gxn.net/disclaimer

Re: [Dovecot] First release (v0.1.0) of the new Sieve implementation for Dovecot v1.2

[Stephan Bosch]

Edgar Fuß wrote:
Finally, after little more than a year, I finished the first release of  
the new Sieve implementation for Dovecot.

Great! I immediately tried to put this into pkgsrc, but ...

The compilation procedure is identical to the cmusieve plugin  
(http://wiki.dovecot.org/LDA/Sieve).

I cannot see how this part of configure

[SNIP]

is supposed to work. Either I point $dovecotdir to the source directory
and get a complaint about a missing dovecot-config or I point it to
the library directory and get a complaint that it can't compile
against headers only.

Dovecot needs to be compiled first for this to work. The dovecot-config
file is produced upon executing ./configure. This is no different from
the old cmusieve plugin.

However, it does indeed currently not allow you to build against dovecot
headers only. I can change this for the next release, but then the sieve
tools and the testsuite will not be compiled.

Regards,

Stephan

Re: [Dovecot] First release (v0.1.0) of the new Sieve implementation for Dovecot v1.2

[Edgar Fuß]

> Finally, after little more than a year, I finished the first release of  
> the new Sieve implementation for Dovecot.
Great! I immediately tried to put this into pkgsrc, but ...

> The compilation procedure is identical to the cmusieve plugin  
> (http://wiki.dovecot.org/LDA/Sieve).
I cannot see how this part of configure

if ! test -f "$dovecotdir/dovecot-config"; then
  echo
  echo "dovecot-config not found from $dovecotdir, use --with-dovecot=PATH"
  echo "to give path to compiled Dovecot sources or to a directory with the"
  echo "installed dovecot-config file."
  AC_MSG_ERROR([dovecot-config not found])
fi

if test -d "$dovecotdir/src"; then
  # compiling against sources
  have_dovecot_libs=yes
else
  # compiling against installed headers
  echo 
  echo "Cannot compile against the installed headers only."
  AC_MSG_ERROR([dovecot-source not found]);
fi

is supposed to work. Either I point $dovecotdir to the source directory
and get a complaint about a missing dovecot-config or I point it to
the library directory and get a complaint that it can't compile
against headers only.

[Dovecot] libwrap patch

[Edgar Fuß]

> then I ran it with gmake LDFLAGS+=-lwrap and it worked
Looks like you forgot to run automake after patching in order to re-generate 
the makefiles.

You may also wish to trim your quoted text before posting to the list.

Re: [Dovecot] Dovecot and Bogofilter

[Patrick Nagel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Matthias

Matthias Andree wrote:
> On Mon, 10 Nov 2008, Patrick Nagel wrote:
>> The problem with modifying the mail after reclassification persists, hope 
>> this
>> can be solved. Then I could also finally move from
>> postfix-procmail-bogofilter-cron-dovecot to
>> postfix-deliver-antispam-bogofilter-dovecot. :)
> 
> Hi,
> 
> it's not quite clear to me how this would work with bogofilter as a
> mailbox_transport - bogofilter isn't designed to do final delivery.
> 
> It's also not quite clear to me why people would use procmail. Although
> defended by its maintainers, it's an unusable and unconfigurable piece
> of software from ancient past -- getting error handling right in
> procmail is next to impossible, requires forfeiting :e rules and
> bloating procmailrc with explicit error handling recipes.

You're right, and that's why I don't want to continue using it. It had a lot of
security issues, and the syntax of procmailrc looked like a bad joke to me when
I encountered it for the first time.

Not being able to pipe mail through an arbitrary program surely makes sieve
more secure, but it also makes things much more complicated sometimes. Also I
think beginners tend to use procmail, just because in many guides / tutorials /
howtos it's the LDA of choice. (I, for example, started out with this howto:
http://www.gentoo-wiki.info/HOWTO_Email_System_for_the_Home_Network )

> If you want something and Dovecot's deliver doesn't fit your needs,
> consider maildrop, 

I didn't even know about it until very recently. ;)

> Bogofilter has an "integrating-with-postfix" document in the doc/
> directory that shows how to use Postfix's content_filter and does not
> need procmail. Unfortunately, it does not show how to integrate updates;
> there are several approaches to achieve that. One way is to use separate
> mailboxes where users can send mail to and where they are picked up by
> cron - best when using Dovecot is probably to make users move spam into
> particular folders via IMAP.

That's how I'm doing it, but surely the Antispam plugin is a nicer (and more
user-friendly) approach - the classification direction (Spam->Ham or Ham->Spam)
is determined by the source and target mailbox.

Patrick.

- --
STAR Software (Shanghai) Co., Ltd.  http://www.star-group.net/
Phone:+86 (21) 3462 7688 x 826   Fax:   +86 (21) 3462 7779

PGP key:  E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc
Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFJF/pB7yMg/OiDoAURAmNyAJ9rFGEPU/mylzF9ec+I07sfMo2q6QCgnGbQ
j4SQHfYXV3zt7FNVXDMA+YE=
=qeP/
-END PGP SIGNATURE-

Re: [Dovecot] Dovecot and Bogofilter

[Matthias Andree]

On Mon, 10 Nov 2008, Patrick Nagel wrote:

> Matthias-Christian Ott wrote:
> > Patrick Nagel wrote:
> >> With postfix, just add bogofilter as transport to master.cf and make it the
> >> 'mailbox_transport'.
> > 
> > Does Postfix understand the pipe syntax? If so everything would be fine.
> 
> Umm, well, it "pipes" the mail through the command specified as
> 'mail_transport' - don't know if that works with shell script style pipes (|)
> directly - but in any case you could easily create a wrapper shell script.

Postfix's pipe(8) transport runs the command directly rather than
spawning /bin/sh; so it does not support shell expansions such as pipes.

-- 
Matthias Andree

Re: [Dovecot] Dovecot and Bogofilter

[Matthias Andree]

On Mon, 10 Nov 2008, Patrick Nagel wrote:

> Thorsten Vollmer wrote:
> > On Sun, 2008-11-09 at 22:39 +0100, Matthias-Christian Ott wrote:
> >> An other problem is that each mail needs to be initially classified and
> >> due to the fact that sieve is not able to execute external programmes,
> >> deliver has to do this task. I'm currently thinking of possibilities to
> >> implement this, so far I came up with the following:
> >>
> >>   1. Write a generic pipe plugin which can execute an arbitrary number of
> >>  programmes. The problem with this is that I'm not sure how to
> >>  integrate this is in Dovecot's configuration file. I thought of
> >>  something like this: pipe = prg1 | prg2
> > 
> > You do not need a plugin if you do the classification before the
> > delivery: MTA | classification | LDA
> 
> With postfix, just add bogofilter as transport to master.cf and make it the
> 'mailbox_transport'.
> 
> The problem with modifying the mail after reclassification persists, hope this
> can be solved. Then I could also finally move from
> postfix-procmail-bogofilter-cron-dovecot to
> postfix-deliver-antispam-bogofilter-dovecot. :)

Hi,

it's not quite clear to me how this would work with bogofilter as a
mailbox_transport - bogofilter isn't designed to do final delivery.

It's also not quite clear to me why people would use procmail. Although
defended by its maintainers, it's an unusable and unconfigurable piece
of software from ancient past -- getting error handling right in
procmail is next to impossible, requires forfeiting :e rules and
bloating procmailrc with explicit error handling recipes.

If you want something and Dovecot's deliver doesn't fit your needs,
consider maildrop, 

Bogofilter has an "integrating-with-postfix" document in the doc/
directory that shows how to use Postfix's content_filter and does not
need procmail. Unfortunately, it does not show how to integrate updates;
there are several approaches to achieve that. One way is to use separate
mailboxes where users can send mail to and where they are picked up by
cron - best when using Dovecot is probably to make users move spam into
particular folders via IMAP.

I'm happy to update or add instructions to bogofilter, but may not have
the time to do sufficient R&D myself in the near future to obtain
relevant knowledge that I could document myself.

-- 
Matthias Andree

Re: [Dovecot] Dovecot and Bogofilter

[Patrick Nagel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias-Christian Ott wrote:
> Patrick Nagel wrote:
>> With postfix, just add bogofilter as transport to master.cf and make it the
>> 'mailbox_transport'.
> 
> Does Postfix understand the pipe syntax? If so everything would be fine.

Umm, well, it "pipes" the mail through the command specified as
'mail_transport' - don't know if that works with shell script style pipes (|)
directly - but in any case you could easily create a wrapper shell script.

Patrick.

- --
STAR Software (Shanghai) Co., Ltd.  http://www.star-group.net/
Phone:+86 (21) 3462 7688 x 826   Fax:   +86 (21) 3462 7779

PGP key:  E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc
Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFJF/TX7yMg/OiDoAURArRMAJ98wma7/pjbcS7bcUCV1DqMBszUSQCgl4ay
GxESbmr50vW8/OMyZGXqjqY=
=g2O6
-END PGP SIGNATURE-