[Dovecot] Configuring Dovecot & Snarf plugin for the first time
I've been using uw-imap for some time on my linux system and have been
running into issues with it so I've decided to move to Dovecote, so far
it seems to have solved the issues I've been having however I need/want
to move the incoming emails out of /var/spool/mail/{user} in the same
(or similar fashion) that uw-imap did, and I found the snarf plugin.
However whenever I enable the snarf plugin using the example on the wiki
page my email is not loaded and when I remove my configuration for snarf
my email re-appears. Based upon what I can tell the snarf plugin is
either not loading (but I see it listed in the logs) or simply not
working (which is probably because its not configured properly).
The system is Fedora 16 (x86_64), the MTA is Exim, and Dovecot is 2.0.21
(version supplied with Fedora). I know I'm making a newbie mistake.
Any guidance would be appreciated.
Thanks, Jeff
dovecot -n provides the following:
[root@xyzzy conf.d]# more /tmp/dovecot.changes
# 2.0.21: /etc/dovecot/dovecot.conf
# OS: Linux 3.4.11-1.fc16.x86_64 x86_64 Fedora release 16 (Verne)
mail_debug = yes
mail_location = mbox:~/mail:INBOX=~/mbox
mail_plugins = " zlib"
mbox_write_locks = fcntl
namespace default {
inbox = yes
location =
prefix =
separator = /
}
namespace snarf {
hidden = yes
list = no
location = mbox:/run/dovecot/empty:INBOX=/var/spool/mail/%u
prefix = /snarf
separator = /
}
passdb {
driver = pam
}
plugin {
mail_log_events = delete undelete expunge copy mailbox_delete
mailbox_rename
snarf = = /snarf/INBOX
}
service imap-login {
inet_listener imap {
address = localhost
}
}
service pop3-login {
inet_listener pop3 {
address = localhost
}
}
ssl_cert = Oct 20 21:29:45 xyzzy dovecot: imap-login: Login: user=,
method=PLAIN, rip=98.109.156.118, lip=132.238.254.34, mpid=19627, TLS
Oct 20 21:29:45 xyzzy dovecot: imap: Debug: Loading modules from
directory: /usr/lib64/dovecot
Oct 20 21:29:45 xyzzy dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib05_snarf_plugin.so
Oct 20 21:29:45 xyzzy dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib20_zlib_plugin.so
Oct 20 21:29:45 xyzzy dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib30_imap_zlib_plugin.so
Oct 20 21:29:45 xyzzy dovecot: imap(jeff): Debug: Effective uid=500,
gid=500, home=/home/jeff
Oct 20 21:29:45 xyzzy dovecot: imap(jeff): Debug: Namespace default:
type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes,
subscriptions=yes location=mbox:~/mail:INBOX=~/mbox
Oct 20 21:29:45 xyzzy dovecot: imap(jeff): Debug: fs:
root=/home/jeff/mail, index=, control=, inbox=/home/jeff/mbox, alt=
Oct 20 21:29:45 xyzzy dovecot: imap(jeff): Debug: Namespace snarf:
type=private, prefix=/snarf, sep=/, inbox=no, hidden=yes, list=no,
subscriptions=yes
location=mbox:/run/dovecot/empty:INBOX=/var/spool/mail/jeff
Oct 20 21:29:45 xyzzy dovecot: imap(jeff): Debug: fs:
root=/run/dovecot/empty, index=, control=, inbox=/var/spool/mail/jeff, alt=
Oct 20 21:29:46 xyzzy dovecot: imap-login: Login: user=,
method=PLAIN, rip=98.109.156.118, lip=132.238.254.34, mpid=19629, TLS
Oct 20 21:29:46 xyzzy dovecot: imap: Debug: Loading modules from
directory: /usr/lib64/dovecot
Oct 20 21:29:46 xyzzy dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib05_snarf_plugin.so
Oct 20 21:29:46 xyzzy dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib20_zlib_plugin.so
Oct 20 21:29:46 xyzzy dovecot: imap: Debug: Module loaded:
/usr/lib64/dovecot/lib30_imap_zlib_plugin.so
Oct 20 21:29:46 xyzzy dovecot: imap(jeff): Debug: Effective uid=500,
gid=500, home=/home/jeff
Oct 20 21:29:46 xyzzy dovecot: imap(jeff): Debug: Namespace default:
type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes,
subscriptions=yes location=mbox:~/mail:INBOX=~/mbox
Oct 20 21:29:46 xyzzy dovecot: imap(jeff): Debug: fs:
root=/home/jeff/mail, index=, control=, inbox=/home/jeff/mbox, alt=
Oct 20 21:29:46 xyzzy dovecot: imap(jeff): Debug: Namespace snarf:
type=private, prefix=/snarf, sep=/, inbox=no, hidden=yes, list=no,
subscriptions=yes
location=mbox:/run/dovecot/empty:INBOX=/var/spool/mail/jeff
Oct 20 21:29:46 xyzzy dovecot: imap(jeff): Debug: fs:
root=/run/dovecot/empty, index=, control=, inbox=/var/spool/mail/jeff, alt=
Re: [Dovecot] LDA without lookup as non-root?
>> 3) The interesting part -- I am invoking LDA from Maildrop. See: >> http://thread.gmane.org/gmane.mail.imap.dovecot/65473 >> So >> when invoked, Maildrop has already dropped to the destination UID/GID >> and the needed paths are available in the environment. However, using >> as many permutations of calling LDA as I can think of (based on >> http://wiki2.dovecot.org/LDA ), I always get this: >> >> (command line usage error. Command output: lda: Fatal: Couldn't lookup > our >> username (uid=2500) ) > > I could not find anything in the mailing list archives to help me, but I > googled > and found a link to a source file: > > http://hg.dovecot.org/dovecot-sieve-1.1/raw-rev/7d85833eff96 > > I read the source, it looks like it's not exactly a userdb lookup - LDA is > trying to get the unix username for the given UID. In my case, UIDs are > "virtual" so there isn't a unix username. The source doesn't > really use the username that it looks up except in a call > "open_logfile." > > Is it possible to avoid this problem? It looks like the answer is no, I have > to > use -d which also forces a userdb lookup. Maybe this limitation can be > removed > in the future? Now I suppose I have to go understand the problems of userdb > lookup permissions, but I think there are solutions for that. FWIW, in this scenario, "service auth" in master config has to have its mode relaxed to 0606 to make userdb lookups work. So ANYONE on the machine can see all userdb lookups. I don't have local users here, so it's probably safe anyway(?). Can anyone explain if there are other security risks of running the auth service at 0606?
Re: [Dovecot] still having difficulties with per-user quotas
David Mehler wrote:
> Thanks for your reply. So with the extending of the query to return a
> default quota rule, do you have an example of that by the way, does
> that mean I only have to put the overrided users in the quota table?
Assuming that quota values are in the dovecot_users table...
# passdb with userdb prefetch and default quota of 1024M for quota=0 rows
# The userdb_ prefix is for prefetch userdb entries in password_query
password_query = SELECT username AS user, \
password AS password, \
home AS userdb_home, \
uid AS userdb_uid, \
gid AS userdb_gid, \
CASE quota \
WHEN 0 \
THEN '*:bytes=1024M:messages=0' \
ELSE \
CONCAT('*:bytes=', CAST(quota AS CHAR), 'M:messages=', CAST(quota_message
AS CHAR)) \
END AS `userdb_quota_rule` \
FROM dovecot_users \
WHERE username='%u';
# user_query with default quota of 1024M for quota=0 rows
user_query = SELECT username AS user, \
home AS home, \
uid AS uid, \
gid as gid, \
CASE quota \
WHEN 0 \
THEN '*:bytes=1024M:messages=0' \
ELSE \
CONCAT('*:bytes=', CAST(quota AS CHAR), 'M:messages=', CAST(quota_message
AS CHAR)) \
END AS `quota_rule` \
FROM dovecot_users \
WHERE username='%u';
Your user_query needs to return a row if the user exists,
otherwise dovecot will assume that the user does not exist
and the mail or user will be rejected.
Regards
Daniel
--
https://plus.google.com/103021802792276734820
Re: [Dovecot] LDA without lookup as non-root?
> 1) If LDA is invoked without > lookups, is it correct to assume that the "service auth" and > "service > auth-worker" can be completely removed from dovecot master > configuration? (I have tried commenting them out and logging into IMAP, > which seems to work, not sure if anyone else needs the auth service) Any confirmation on this? > 2) > If LDA is invoked without lookups, will I be unable to use Dovecot > quota plugin? Does it need to have a user lookup to get quota info? > (haven't added quota support, need to take this one step at a time) I'm especially interested if someone can comment on this, since maybe it makes my efforts here wasted > 3) The interesting part -- I am invoking LDA from Maildrop. See: > http://thread.gmane.org/gmane.mail.imap.dovecot/65473 > So > when invoked, Maildrop has already dropped to the destination UID/GID > and the needed paths are available in the environment. However, using > as many permutations of calling LDA as I can think of (based on > http://wiki2.dovecot.org/LDA ), I always get this: > > (command line usage error. Command output: lda: Fatal: Couldn't lookup our > username (uid=2500) ) I could not find anything in the mailing list archives to help me, but I googled and found a link to a source file: http://hg.dovecot.org/dovecot-sieve-1.1/raw-rev/7d85833eff96 I read the source, it looks like it's not exactly a userdb lookup - LDA is trying to get the unix username for the given UID. In my case, UIDs are "virtual" so there isn't a unix username. The source doesn't really use the username that it looks up except in a call "open_logfile." Is it possible to avoid this problem? It looks like the answer is no, I have to use -d which also forces a userdb lookup. Maybe this limitation can be removed in the future? Now I suppose I have to go understand the problems of userdb lookup permissions, but I think there are solutions for that. Am I on the right understanding ? > The > UID is correct for the target user. If I add "-d $LOGNAME" to my LDA > callout, I get permission denied on the userdb lookup, which I guess is > another issue to work out if I want to go with lookups. But right now I > am trying not to. Why does LDA seem to try for a lookup even when I > follow the wiki instructions how to call it without a lookup? > > 3.5) > Related question, my users have separate homedir and maildir, both > paths are looked up by Maildrop. I think I need to call LDA with > "HOME=$DEFAULT dovecot-lda -f $FROM". Is this correct? >
Re: [Dovecot] still having difficulties with per-user quotas
David Mehler wrote: > My first issue is from what it is looking like I have to define all my > users in the quota database not just the ones whose values I want to > override the global quota declaration in 90-quota.conf. If I just add > the user@domain to the database the bytes and messages columns have > zero as default, this means those values override global quota in > 90-quota.conf and they effectively have unlimited access. This is expected behavior. If the userdb returns a quota rule, it overrides the global quota rule. Extend your SQL query to return a default quota_rule for rows without quota entry. > My second issue is I have entered a quota of 250 megabytes for a test > user. This works but he seems to get more space everytime he logs in, > started out at 250, on the next login it was 255, then 269 on the > third, and so forth. I've checked the quota table and yes the value in > the bytes column is increasing. Please show output of doveconf -n and any external (sql/dict) includes related to quota or quota_rules. Regards Daniel -- https://plus.google.com/103021802792276734820
Re: [Dovecot] Dovecot 2 and TCP-Keepalive
Timo Sirainen wrote: > On 20.10.2012, at 19.39, Sven Hartge wrote: >> My question is: does Dovecot2 use TCP-Keepalive on its sockets per >> default or do I need to enable it some way I have not yet discovered? > It's the default yes. Of course Linux's default keepalive interval is > something like 90 minutes, so have you changed that already?.. Yes, I did. For those systems it is set to 15 minutes right now. >> The manual and wiki only talk about "keepalive" in connection with >> the IMAP protocol and IDLE and my C-fu is too weak to understand the >> source code. > imap_idle_notify_interval (default 2 min) causes Dovecot to send data > to IDLEing connections, which pretty much makes the TCP keepalive > irrelevant. For non-IDLE connections Dovecot has a disconnect timeout > of 30 minutes. This is fine. As long as the client notices the termination of the connection, everything should be OK. Before I switched keepalive on for Perdition, the firewall/NAT would internally throw away a connection but neither the client or the server would notice this. Then if the client tried to do something with this connection, like select or save a message, the firewall/NAT would send a RST and the client would then bug the user with a meaningless message like "folder does not exist" which caused a lot of confusion for the end-user and created quite the bit of trouble tickets. This problem mostly happend with an IMAP connection to the "Sent Messages" folder which normally does not see much changes until the users writes and sends a mail. Then after the mail was sent via SMTP the client tries to save the message, gets sent an RST from the firewall/NAT and presents the user with a wrong and confusing error message. The user then thinks his mail was not sent and sends it again. This time the client opens a new connection to select the "Sent Messages" folder and everything works. But the recipient gets the mail twice. Again resulting in confusion and trouble tickets to be dealt with. By switching to TCP keepalive (and reducing the keepalive time to 15 minutes) all those problems were solved and my users (and support staff) were happy again ;) Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [Dovecot] still having difficulties with per-user quotas
Hello, Thank you for your reply. Adding mail_uid and mail_gid fixed it. I now have quotas going but I don't know if I have them right or just don't like my setup. My first issue is from what it is looking like I have to define all my users in the quota database not just the ones whose values I want to override the global quota declaration in 90-quota.conf. If I just add the user@domain to the database the bytes and messages columns have zero as default, this means those values override global quota in 90-quota.conf and they effectively have unlimited access. My second issue is I have entered a quota of 250 megabytes for a test user. This works but he seems to get more space everytime he logs in, started out at 250, on the next login it was 255, then 269 on the third, and so forth. I've checked the quota table and yes the value in the bytes column is increasing. Thanks for any help. Dave. On 10/20/12, Daniel Parthey wrote: > David Mehler wrote: >> Oct 19 15:23:52 imap(xxx): Error: user xxx: Couldn't drop privileges: User >> is missing UID (see mail_uid setting) > > Set the following options in your dovecot.conf: > > mail_uid = vmail > mail_gid = vmail > > Also see section "Mail users" at > http://wiki2.dovecot.org/UserIds > > Regards > Daniel > -- > https://plus.google.com/103021802792276734820 >
Re: [Dovecot] Dovecot 2 and TCP-Keepalive
On 20.10.2012, at 19.39, Sven Hartge wrote: > I am about to migrate a perdition-based IMAP/POP3 proxy to Dovecot. > > Unfortunately some users are behind a firewall/NAT setup which throws > away seemingly idle TCP connections sooner than the established default > of 24 hours (more likely after 30 minutes ...) resulting in all kinds of > weird client behavior. > > And unfortunately² this firewall/NAT setup is outside of my control and > I have no means of correcting this (in my opinion) flawed configuration. > > Now, with perdition I was able to use the --tcp_keepalive option which > totally solved the mentioned weird client behavior. > > My question is: does Dovecot2 use TCP-Keepalive on its sockets per > default or do I need to enable it some way I have not yet discovered? It's the default yes. Of course Linux's default keepalive interval is something like 90 minutes, so have you changed that already?.. > The manual and wiki only talk about "keepalive" in connection with the > IMAP protocol and IDLE and my C-fu is too weak to understand the source > code. imap_idle_notify_interval (default 2 min) causes Dovecot to send data to IDLEing connections, which pretty much makes the TCP keepalive irrelevant. For non-IDLE connections Dovecot has a disconnect timeout of 30 minutes.
[Dovecot] Dovecot 2 and TCP-Keepalive
Hi! I am about to migrate a perdition-based IMAP/POP3 proxy to Dovecot. Unfortunately some users are behind a firewall/NAT setup which throws away seemingly idle TCP connections sooner than the established default of 24 hours (more likely after 30 minutes ...) resulting in all kinds of weird client behavior. And unfortunately² this firewall/NAT setup is outside of my control and I have no means of correcting this (in my opinion) flawed configuration. Now, with perdition I was able to use the --tcp_keepalive option which totally solved the mentioned weird client behavior. My question is: does Dovecot2 use TCP-Keepalive on its sockets per default or do I need to enable it some way I have not yet discovered? The manual and wiki only talk about "keepalive" in connection with the IMAP protocol and IDLE and my C-fu is too weak to understand the source code. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: [Dovecot] trash plugin not doing it's job
Jan-Frode Myklebust wrote: > $ cat /etc/dovecot/dovecot-trash.conf.ext > # Spam mailbox is emptied before Trash > 1 INBOX.Spam > # Trash mailbox is emptied before Sent > 2 INBOX.Trash Are you sure the Trash Folder of the affected users is located below "INBOX"? doveadm mailbox list -u user@domain | grep -iE "trash|spam" Example at http://wiki2.dovecot.org/Plugins/Trash omits "INBOX." Have you tried INBOX/Trash as mailbox name? Regards Daniel -- https://plus.google.com/103021802792276734820
Re: [Dovecot] still having difficulties with per-user quotas
David Mehler wrote: > Oct 19 15:23:52 imap(xxx): Error: user xxx: Couldn't drop privileges: User is > missing UID (see mail_uid setting) Set the following options in your dovecot.conf: mail_uid = vmail mail_gid = vmail Also see section "Mail users" at http://wiki2.dovecot.org/UserIds Regards Daniel -- https://plus.google.com/103021802792276734820
Re: [Dovecot] Dovecot 2 quota limit and actual size (mysql)
Use LMTP instead of lda. The dovecot lmtp service automatically cares about updating quota values in mysql database when mail arrives through the lmtp socket. Regards Daniel wamp wrote: > Hello, > Can You explain to me how dovecot-lda knows actual size of virtual user > directory? I want to keep > max size of user directory in mysql - should I also use some kind of script > to upgrade actual size information in mysql ? > > I read docs from wiki but still dont know it. > > > thanks > > > > -- > View this message in context: > http://dovecot.2317879.n4.nabble.com/Dovecot-2-quota-limit-and-actual-size-mysql-tp38235.html > Sent from the Dovecot mailing list archive at Nabble.com. > -- https://plus.google.com/103021802792276734820
