Enterprise Edition: Any known access issues with the repo? Have existing accounts been expired?
Hi, I'm getting errors when attempting to run apt-get update on an Ubuntu 14.04 box where I've had an existing EE installation for some time: > W: Failed to fetch https://apt.dovecot.fi/stable-2.2/ubuntu/trusty/dists/trusty/main/binary-amd64/Packages HttpError401 > > W: Failed to fetch https://apt.dovecot.fi/stable-2.2/ubuntu/trusty/dists/trusty/main/binary-i386/Packages HttpError401 > > E: Some index files failed to download. They have been ignored, or old ones used instead. I'm running 2.2.25.5 now and when I looked at the announcement forum[1] I see a posting[2] for 2.2.26.1, but nothing about repo changes. For what it is worth, I use the EE credentials on only a single node so I am hopefully not triggering any abuse thresholds. I tried accessing the URL used in the /etc/apt/sources.list.d/FILENAME.list file via a web browser and it isn't accepting the provided username/password. Have existing credentials been expired? If so, what is the next step to restore access? Thanks. References: [1] https://forum.open-xchange.com/forumdisplay.php?35-Dovecot-Announcements [2] http://software.open-xchange.com/products/dovecot/doc/Release_Notes_for_Dovecot_Pro_2.2.26.1_2016-10-31.pdf
Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?
On 5/5/2016 12:40 PM, Gedalya wrote: > On 05/05/2016 01:33 PM, Gedalya wrote: >> you just might be able to set that up to test for the right conditions >> *when* to do this, and then proceed to remove the header > > Maybe using PCRE negative lookaheads > > /^Subject: (?!google-calendar-notification)/DUNNO > /^From: (?!google)/DUNNO > /^Auto-Submitted:/IGNORE > > maybe something vaguely like this?? didn't test this anywhere outside of my > message compose window > Thanks. I tried it, but it appeared to strip the header from emails that the "/From: " line didn't match. I'm going to try going the route of a check_sender_access table entry that uses a 'FILTER transport:' action to send matched mail through a custom transport. That transport/service entry in master.cf will then apply a single header check to strip out the header. I've been fighting with the appropriate settings for the entry and haven't made much progress, so I will probably drop into the Postfix mailing list soon and ask for some help there pointing out my obvious mistake. Thanks for your feedback.
Re: Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?
On 5/5/2016 10:42 AM, Gedalya wrote: On 05/05/2016 01:00 AM, deoren wrote: Goal: 1) Setup a Google Calendar entry for a biweekly task 2) Configure the email notification schedule 3) When the email notification from Google arrives have Sieve send a notification to an alias I have setup for my cell provider's email to text messaging gateway 4) Receive text message ... If you can't do it with dovecot / pigeonhole then consider doing something in the MTA like removing the Auto-Submitted header before delivery Thank you for taking the time to read my email and offer suggestions! I was starting to think the same thing. I've been thinking about using a local alias to pipe to a script to handle generating my own notifications for Google Calendar emails. I also thought about creating some sort of filter/milter to just strip out the header for those emails before letting the Sieve filter handle the rest, but I've not yet had a chance to research just how to go about that. or of course you can just send your notification out of there. Like I mentioned above or is there a better way to go about it? Which MTA are you using? I'm using Postfix 2.11.x + Dovecot 2.2.x to handle our mail. Thanks again for your help!
Is there a way to override Sieve's "not sending notification for auto-submitted message" behavior?
Goal: 1) Setup a Google Calendar entry for a biweekly task 2) Configure the email notification schedule 3) When the email notification from Google arrives have Sieve send a notification to an alias I have setup for my cell provider's email to text messaging gateway 4) Receive text message I know there are other products which likely handle this better, but I'm specifically attempting to replicate old behavior by getting text message reminders when a specific Google Calendar event occurs. The problem I'm having is that Sieve is attempting to help by NOT sending a notification for emails that it finds are automatically generated. I didn't found a lot of information when I searched for additional details, but I didn't find an earlier message thread on this list that led me to believe that the default behavior is likely chosen as some sort of safety net to prevent common issues from occurring. What I would like to do is override this behavior at some level (per rule, per user, system-wide, whatever) to allow for Sieve notifications when emails matching a specific pattern are detected regardless of whether they are auto-generated or not. I already found mention in the documentation[1] that the editheader extension refuses to remove the Auto-Submitted header, so setting up a per user or global rule to do just that wouldn't help. I also haven't come upon a way to simply modify the value for the Auto-Submitted header, so that doesn't look to work in this situation either. Does anyone know of a way to accomplish this? Thanks in advance for your help! [1] http://wiki2.dovecot.org/Pigeonhole/Sieve/Extensions/Editheader
Re: Have the Dovecot Enterprise Edition packages been discontinued?
On 12/10/2015 1:56 AM, Timo Sirainen wrote: On 10 Dec 2015, at 06:53, deoren <dovecot-mailing-l...@whyaskwhy.org> wrote: Hi, I've been using the Dovecot EE packages for Ubuntu for some time now and just recently started getting 404 errors. Have those packages been discontinued or is this just a temporary issue? They have moved, see the new installation manual: https://forum.open-xchange.com/showthread.php?9650-Dovecot-releases-Dovecot-Pro-v2-2-19-1 Thanks! Once I updated the package repo URL that fixed the issue for me.
Have the Dovecot Enterprise Edition packages been discontinued?
Hi, I've been using the Dovecot EE packages for Ubuntu for some time now and just recently started getting 404 errors. Have those packages been discontinued or is this just a temporary issue? Thanks.
Are the Dovecot Enterprise Edition Ubuntu 14.04 packages stable?
I recently begun to migrate mail services to a new box so I could retrofit an existing box. I took this opportunity to check back on the official Dovecot Enterprise Edition (EE) pages to see if support has been added for Ubuntu 14.04 LTS. I never could find the information on the dovecot.fi website, but taking my existing credentials for Dovecot EE repo access and looking at the root path I see that 14.04 packages are available from the APT repo. Are those stable or experimental? I have an Ubuntu 12.04 box I've kept around just for Dovecot EE that I'd like to move to 14.04 if the packages are stable. p.s. Thank you for continuing to provide access for existing users of the repo, but what would new users need to do to obtain access? Thanks for your time.
Re: userdb lookup not possible with only userdb prefetch
On 12/7/2014 5:04 AM, Yves Goergen wrote:
Am 07.12.2014 um 00:56 schrieb Alexander Dalloz:
You did fulfill the requzirements for prefetch to work documented in the
wiki?
http://wiki2.dovecot.org/UserDatabase/Prefetch
Ehm, this is my SQL configuration 'dovecot-sql.conf.ext':
driver = mysql
connect = host= user= password= dbname=
default_pass_scheme = PLAIN
password_query = \
SELECT \
local AS username, domain, clearpass AS password, \
concat(maildir, '/home') AS home, maildir AS mail \
FROM mailusers \
WHERE local = '%n' AND domain = '%d' AND forward = '' AND NOT locked
Now that I've found the page you gave me (didn't see it before, but I
must say that wiki is not easily readable, pretty confusing) I think the
column names must be different.
Instead of: username, domain, password, home, mail
Should I return: username, domain, password, userdb_home, userdb_mail?
I too made a similar mistake and struggled for a while to understand why
my attempts were failing. If using the prefetch userdb driver you have
to return values from your database using appropriate aliases to match
the expected names.
Here is what I'm using for the 'password_query':
password_query = \
SELECT email AS user, password, \
'vmail' AS userdb_uid, \
'vmail' AS userdb_gid, \
'/var/vmail/%d/%n' as userdb_home \
FROM virtual_users \
WHERE email = '%u' \
AND enabled = '1';
Depending on your db layout you'll have different source values, but as
long as you end up returning the values under the right column names (or
aliases) it should work. My current db design needs improvement (as the
static placeholder values in the above query shows), but it works as-is
for now.
And what does that comment in the example mean? # The userdb below is
used only by lda. Should I use only userdb:driver=prefetch, or should I
include a separate userdb section as if I wouldn't use prefetch? Again,
confusing. Why does it have to be two separate queries at all? Just use
one and take what you get. If some required column is missing and the
value isn't set in the configuration, you can still throw an error.
I can't speak to the design, but from what I've read the userdb sections
have a fall through approach. If one doesn't provide the sought after
information the next userdb section is used.
From the http://wiki2.dovecot.org/UserDatabase/Prefetch wiki page:
Prefetch userdb can be used to combine passdb and userdb lookups into
a single lookup. It's usually used with SQL, LDAP and checkpassword passdbs.
Prefetch basically works by requiring that the passdb returns the
userdb information in extra fields with userdb_ prefixes. For example if
a userdb typically returns uid, gid and home fields, the passdb would
have to return userdb_uid, userdb_gid and userdb_home fields.
If you're using LDA, you still need a valid userdb which can be used
to locate the users. You can do this by adding a normal SQL/LDAP userdb
after the userdb prefetch. The order of definitions is significant. See
below for examples.
LDAP: auth_bind=yes with auth_bind_userdn-template is incompatible
with prefetch, because no passdb lookup is done then. If you want zero
LDAP lookups, you might want to use static userdb instead of prefetch.
Here are my values for the auth-sql.conf.ext file (comments removed):
passdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
driver = prefetch
}
userdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf.ext
}
Here are my comments for the last userdb entry as a reminder to myself:
Based on my readings this is used for doveadm queries which returns a
list of all users, LDA (which we don't use) and LMTP (which we do). I
believe the prefetch entry above will be used before this one, which
would leave this entry to be used only for for doveadm queries that
request a list of all users
To circle back, here are the remaining two queries from my copy of
dovecot-sql.conf.ext:
# NEEDED for LDA/LMTP if we don't include a static userdb entry
user_query = SELECT email as user, \
'/var/vmail/%d/%n' as home \
FROM virtual_users \
WHERE email = '%u' \
AND enabled = '1';
iterate_query = SELECT email AS user \
FROM virtual_users \
WHERE enabled='1';
My comments for the last query:
Query to get a list of all usernames. Requires a 'userdb' entry in
# auth-sql.conf.ext that refers back to this file. Normally it matches
the 'passdb' stanza aside from the name.
P.S.
The substitution used ('%u' vs '%n') will depend on how you have your
user information stored. The comments in dovecot-sql.conf.ext provide
some sample queries to illustrate that.
As my queries suggest, my db setup uses the 'usern...@example.org'
format for user names. Had I thought about it a little more I might have
opted to instead store the user and domain values in separate fields,
but then again maybe not. Something to be aware of anyway.
Re: Migrate system users to virtual users
On 2014-11-13 12:29, Ron Leach wrote: List, good afternoon, We are at the planning stage of wanting to migrate from an existing installation onto a new machine, and also to change from system users to virtual users. May I check that our ideas for user id are correct? I am not sure whether we will encounter a 'permissions' and 'user id' problem when moving from a system-user scheme to a virtual scheme. We use Maildir, and the maildirs at the moment are in their users' linux /home directories. After reading the wiki, we think that the 'single system user for vmail' arrangement, ie just one system user to manage all the mail for all virtual users, will work for us. I think that means that the permissions on all our existing 'system-user-oriented' maildirs will have to be changed (in the new machine) so that they are owned by the 'single-system-user', such as 'vmail'. One thought was to first copy the existing maildirs into the new virtual user file system tree, and then, second, change the owners and permissions on the maildirs and directories and messages to permit control by 'vmail'. From the point of view of transferring all the mail files, is that all we would have to do? (Of course, we would also have to create the virtual users and their passwords, and arrange the appropriate password lookups etc, but that's not the direct topic of this post. And that arrangement has to be compatible with the MTA, as well.) That is what I did with a system account that I migrated a few months back and it worked out well. If we do copy the maildirs and change the permissions, does all the metadata that the clients, or Dovecot, use to detect new, existing, or downloaded mail remain valid? Or should we use a different approach? Hopefully someone with more experience will chime in and answer the particulars re metadata, but I did just what you're talking about and didn't have any problems; granted I was working with a test account with minimal data. I went from a setup like you described where I had /home/user/Maildir and migrated that content to /var/vmail/domain/user/Maildir and set the new system account as the user:group recursively. That setup has been working fine since. I initially made the mistake of leaving out the 'Maildir' subdirectory for the content, but after receiving some advice here on the list I corrected that mistake.
Re: Example records for SQL AUTH
On 11/3/2014 4:29 PM, Jorge Bastos wrote:
Hi,
Where can I get examples for the records for the users table?
If I understand your question properly and you're looking for examples
of creating new virtual users, then this guide covers that:
https://www.linode.com/docs/email/email-with-postfix-dovecot-and-mysql
You would have to adjust to fit your chosen schema of course as theirs
is a much simpler setup that excludes the uid, gid, and home values.
For SHA512-CRYPT, I tried:
replace into users values ('a...@a.com','a.com',ENCRYPT('b', CONCAT('$6$',
SUBSTRING(SHA(RAND()), -16))),'',0,0,'true');
schema is:
CREATE TABLE `users` (
`username` varchar(255) NOT NULL,
`domain` varchar(255) NOT NULL,
`password` varchar(255) NOT NULL,
`home` varchar(255) NOT NULL,
`uid` int(11) NOT NULL,
`gid` int(11) NOT NULL,
`active` enum('true','false') NOT NULL DEFAULT 'true',
PRIMARY KEY (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Password_query:
password_query = select username, domain,password from users where
username='%u' and domain='%d' and active='true'
What does your auth-sql-conf.ext file look like? With as much
information as you already have in your database schema you may want to
look at using the Prefetch userdb.
http://wiki2.dovecot.org/UserDatabase/Prefetch
P.S.
Apologies for the duplication. I forgot to reply to the list with my
last response.
Re: Where can I find change logs/release notes for Dovecot EE releases?
On 10/23/2014 2:36 AM, Teemu Huovila wrote: On 10/23/2014 10:34 AM, Teemu Huovila wrote: On 10/23/2014 12:35 AM, deoren wrote: I searched for them and haven't come across them yet. Could any point me in the right direction? Specifically the Ubuntu 12.04 package notes if they're split out. On a Debian based system you should find them in /usr/share/doc/dovecot-ee-core/chagnelog.gz /usr/share/doc/dovecot-ee-core/changelog.gz Thanks Teemu. I was hoping that there was an online copy somewhere that I could review, but it doesn't appear too troublesome to pull off by unpacking the dovecot-ee-core deb file prior to installing the updates. First, I note what version I'm currently running. Prior to the latest updates, it was v2.2.13.25. Once I have that I can proceed to follow these steps to extract the recent changes. #1) apt-get clean #2) apt-get dist-upgrade -d #3) cp /var/cache/apt/archives/dovecot-ee-core*.deb /tmp/ #4) cd /tmp #5) mkdir dovecot-ee-core #6) ar p dovecot-ee-core_*.deb data.tar.gz | tar zx -C dovecot-ee-core #7) zcat dovecot-ee-core/usr/share/doc/dovecot-ee-core/changelog.gz | grep 2.2.13.25 -B 100 It's a few steps, but that gives me the changelog I was looking for prior to installing the updates.
Re: What is the correct way to configure the mail_location option for Mailidr format?
On 10/22/2014 2:29 AM, Steffen Kaiser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 21 Oct 2014, deoren wrote:
What is the correct way to configure the mail_location option for
Mailidr format?
mail_location = maildir:path
I've long had it setup this way:
mail_location = maildir:/var/vmail/%d/%n
Is that correct?
any path is OK, as long:
1) it identifies the mail storage uniquely for the user,
2) does not store any other information in it.
Here is an example error message I ran into:
stat(/var/vmail/example.com/username/.dovecot.lda-dupes/tmp)
failed: Not a directory
That's because you use $HOME == Maildir root.
Looking at some other guides/tutorials shows something more like:
mail_location = maildir:/var/vmail/%d/%n/Maildir
Maildir is the default name for Maildir-type mail storeage root. No
more, no less. If Dovecot is automatically detecting the type of
storage, it probes for this directory name in $HOME.
I assume the latter is how it's supposed to be done? If so, that would
No, you are not supposed to do so.
I did review the official docs here:
http://wiki2.dovecot.org/MailLocation/Maildir
but I didn't find where it explicitly warns against setting home ==
maildir root. It should probably be apparent, but it wasn't to me when
I first
it applies to all mail storages.
- -- Steffen Kaiser
Thanks for the reply and for answering my questions.
Just to make sure I understand properly, I have a few additional
questions that I am hoping will cement really drive the point home so to
speak. Regarding the guide that I followed, it suggests the following
userdb and mail_location configuration:
userdb {
driver = static
args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}
mail_location = maildir:/var/mail/vhosts/%d/%n
This results in the $HOME == Maildir root situation which you mentioned
shouldn't be done, correct? Instead mail_location should point to some
other directory, perhaps one of:
* mail_location = /var/mail/vhosts/%d/%n/Maildir
* mail_location = ~/Maildir
If I understand properly the mail_location doesn't have to be a
subdirectory within the home directory, it just typically is in common
examples? If so, that guide should probably be updated to use one of the
above mail_location settings. If you will confirm that is the case I'll
submit a GitHub pull request as previously mentioned so it can be
corrected.
Apologies if this is rehashing what you've already said, I'm just
looking to make sure I understand this 100%.
So for cases where I have made the mistake like I mentioned above, how
would I (properly) fix the problem?
After stopping Dovecot, I ended up doing this:
#1) service dovecot stop
#2) cd /var/vmail/example.com/username/
#3) mkdir Maildir
#4) mv -i * Maildir/
#5) mv -i .* Maildir/
#6) chown -R vmail:vmail /var/vmail/example.com/username/
#7) service dovecot start
which moved the content into the Maildir subfolder and fixed permissions
back to what is specified in the conf files. I also adjusted
mail_location like so:
mail_location = maildir:~/Maildir
and I made sure that the home setting is configured as /var/vmail/%d/%n
That seems to work fine, but I still got error messages like this when
using doveadm search
Error: Syncing mailbox dovecot.lda-dupes failed: Internal error
occurred.
In my testing I found that I could move the file from this location:
/var/vmail/example.com/username/Maildir/.dovecot.ldap-dupes
to this one:
/var/vmail/example.com/username/.dovecot.ldap-dupes
choosing to overwrite the file if it should be there and the error
message would not be generated anymore. This suggests that I shouldn't
have moved it in the first place.
Looking through the mailing list archives I found a message thread
titled Lifetime of redirect info stored by Sieve in .dovecot.lda-dupes
which indicates that the Message-ID and recipient of forwarded messages
are stored in .dovecot.ldap-dupes files. I do forward mail daily from
the two accounts where doveadm search generates the errors, so it sounds
like I would probably be OK to just nuke the file in this location:
/var/vmail/example.com/username/Maildir/.dovecot.ldap-dupes
and let it be auto-generated in the proper location the next time mail
is forwarded. Can you confirm whether that is the case?
I appreciate your help.
Where can I find change logs/release notes for Dovecot EE releases?
I searched for them and haven't come across them yet. Could any point me in the right direction? Specifically the Ubuntu 12.04 package notes if they're split out. Thanks!
Re: 90-sieve.conf syntax - moving from v2.0.x to v2.2.x
On 2014-10-20 11:59, deoren wrote: Hi, I'm currently running version v2.0.x in production (using Maildir storage) and it's been working well. I'm interested in moving to version 2.2.x and am preparing a test server to do so. As I have been merging the conf file changes between the two versions I noticed syntax changes for the 90-sieve.conf file. There are now 'locations' and presumably to keep referring to local content I'll need to use the 'file:' location type. On my production box (v2.0.x) I have 90-sieve.conf configured like so: sieve = /var/vmail/sieve/%d/%n/.dovecot.sieve sieve_default = /var/vmail/sieve/global.sieve sieve_dir = /var/vmail/sieve/%d/%n/sieve_dir Inside of the /var/vmail/sieve/%d/%n/ directory (i.e., /var/vmail/sieve/example.com/testuser/) I find: drwxr-xr-x 3 vmail vmail 64 Oct 19 12:07 . drwxr-xr-x 9 vmail vmail 101 Jun 21 10:47 .. lrwxrwxrwx 1 vmail vmail 25 Jun 21 11:10 .dovecot.sieve - sieve_dir/roundcube.sieve -rw--- 1 vmail vmail 3694 Oct 19 12:07 .dovecot.svbin drwx-- 3 vmail vmail 38 Oct 19 11:58 sieve_dir and that works well. I never did work out the new syntax, so I kept the older and so far it is working fine with v2.2.13. I did have to remove the old compiled versions of the Sieve scripts to get things working. I had at least one case (one specific account) where the script was recompiled automatically, but for the other accounts I did have to nuke the *.svbin file to force a recompilation of the Sieve scripts. Only in one case was a message logged (with debug mode enabled) re a version mismatch and the script recompiled automatically. It may not be the best way to do it, but this is what I did: rm -i $(find . -type f /var/vmail/sieve/example.com/ | grep svbin) After that the scripts began working as expected (using the older syntax which I mentioned in the last email). If anyone has any suggestions for updating the syntax for those configuration options I'd appreciate it. I couldn't make heads or tails of it. Everything I thought should work didn't.
Re: SMTP authentication setup
On 2014-10-21 07:40, Brian wrote: At my company we've had a longstanding problem of not being able to send email from devices outside of our internal network and any specific IP address that we open the relay to. As it turns out, SASL has never been set up. I need to set up SASL ASAP but none of the guides I've found seem to work. I recommend reading over these guides and doing outside research to fill in any blanks: * https://www.linode.com/docs/email/postfix/email-with-postfix-dovecot-and-mysql * https://workaround.org/ispmail * http://wiki2.dovecot.org/Authentication/PasswordSchemes They walk you through setting up SASL for Postfix which uses Dovecot for auth. Dovecot in turn uses a MySQL database that you put together, but Dovecot supports many other auth sources such as LDAP that might be more relevant to your setup. It's worth mentioning (although you probably already know this) to double-check any recommendations you find in guides against official docs when it comes to security practices. For example, one guide recommends using the MD5 hashing algorithm (without a salt) to store passwords. I'm (very) far from being a security expert, but I recommend you research an alternative hashing scheme if you're setting up an auth source from scratch.
What is the correct way to configure the mail_location option for Mailidr format?
Short version: What is the correct way to configure the mail_location option for Mailidr format? I've long had it setup this way: mail_location = maildir:/var/vmail/%d/%n based on this guide: https://www.linode.com/docs/email/postfix/email-with-postfix-dovecot-and-mysql Is that correct? Longer version: After upgrading from Dovecot v2.0.x to v2.2.x yesterday I'm coming to the conclusion that I've got it configured wrong. This is probably compounded by my bright idea of explicitly setting the path separator prior to the upgrade like so: separator = . Because we're using Maildir I thought it would be useful to explicitly set the separator value to what the default is for Maildir. I figured this would be a good way to remind myself what the separator is by default. I also figured while I was merging the conf changes between v2.0 and v2.2 I could roll that additional change in also. Looks like that was a bad idea to include unnecessary changes until things had stabilized. I should know better; I was too optimistic for my own good. Here is an example error message I ran into: stat(/var/vmail/example.com/username/.dovecot.lda-dupes/tmp) failed: Not a directory which is nearly identical (other than leading path) to what is shown here: http://www.dovecot.org/list/dovecot/2010-April/048227.html Steffen Kaiser responded with, You should not (must not) have home == maildir root. That is when I double-checked the guide that I mentioned above and found that I had followed their directions exactly for that conf setting. Looking at some other guides/tutorials shows something more like: mail_location = maildir:/var/vmail/%d/%n/Maildir I assume the latter is how it's supposed to be done? If so, that would explain the problems I've had with Sieve scripts in the past until I explicitly set 'sieve_dir' like so: sieve_dir = /var/vmail/sieve/%d/%n/sieve_dir I did review the official docs here: http://wiki2.dovecot.org/MailLocation/Maildir but I didn't find where it explicitly warns against setting home == maildir root. It should probably be apparent, but it wasn't to me when I first configured that setting. Thanks in advance for your help. If it turns out that the linode.com guide is wrong I'll create a Pull request to have that guide updated.
Re: What is the correct way to configure the mail_location option for Mailidr format?
On 10/21/2014 11:44 AM, Benny Pedersen wrote: On October 21, 2014 6:18:07 PM deoren dovecot-mailing-l...@whyaskwhy.org wrote: mail_location = maildir:/var/vmail/%d/%n/Maildir sieve_dir = /var/vmail/sieve/%d/%n/sieve_dir mail_location = maildir:/var/vmail/%d/%n/.maildir sieve_dir = /var/vmail/%d/%n/.sieve More simple, and more easy to tarball backup Thank you for the advice. Can you comment re these two approaches for configuring the 'mail_location' option? I assume the first is simply wrong? mail_location = maildir:/var/vmail/%d/%n mail_location = maildir:/var/vmail/%d/%n/.maildir Also, why do you use the '.maildir' folder name instead of 'Maildir'? Is that so it doesn't appear in the ls output by default? Some other reason perhaps? I agree that having the sieve scripts in a different location than the mail content is less than ideal. When the sieve scripts were originally stored in the /var/vmail/%d/%n directory they showed up within Thunderbird as folders, so to get things working again quickly I made sure to move the sieve scripts completely outside of where the mail content was stored. The cause was likely the 'mail_location' option being misconfigured (assuming that it really is, I'm still trying to nail that down), so once that is resolved I'm planning on moving them back. Thanks for the reply. I'm hoping rearranging the mail content will be just as easy to do.
90-sieve.conf syntax - moving from v2.0.x to v2.2.x
Hi, I'm currently running version v2.0.x in production (using Maildir storage) and it's been working well. I'm interested in moving to version 2.2.x and am preparing a test server to do so. As I have been merging the conf file changes between the two versions I noticed syntax changes for the 90-sieve.conf file. There are now 'locations' and presumably to keep referring to local content I'll need to use the 'file:' location type. On my production box (v2.0.x) I have 90-sieve.conf configured like so: sieve = /var/vmail/sieve/%d/%n/.dovecot.sieve sieve_default = /var/vmail/sieve/global.sieve sieve_dir = /var/vmail/sieve/%d/%n/sieve_dir Inside of the /var/vmail/sieve/%d/%n/ directory (i.e., /var/vmail/sieve/example.com/testuser/) I find: drwxr-xr-x 3 vmail vmail 64 Oct 19 12:07 . drwxr-xr-x 9 vmail vmail 101 Jun 21 10:47 .. lrwxrwxrwx 1 vmail vmail 25 Jun 21 11:10 .dovecot.sieve - sieve_dir/roundcube.sieve -rw--- 1 vmail vmail 3694 Oct 19 12:07 .dovecot.svbin drwx-- 3 vmail vmail 38 Oct 19 11:58 sieve_dir and that works well. I look at the current wiki documentation: http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration and I find that the 'seive_dir' conf option is still listed, but the comments for it appear very similar to the comments that precede the 'sieve' conf option in the stock 90-sieve.conf file: # The location of the user's main Sieve script or script storage. The LDA # Sieve plugin uses this to find the active script for Sieve filtering at # delivery. The include extension uses this location for retrieving # :personal scripts. This is also where the ManageSieve service will store # the user's scripts, if supported. Assuming that the 'sieve' and 'sieve_dir' conf settings have not been merged into just 'sieve' (and that I need to use the 'file:' location specifier), is this how I would configure the two settings for Dovecot 2.2.x? sieve = file:/var/vmail/sieve/%d/%n;active=~/.dovecot.sieve sieve_dir = file:/var/vmail/sieve/%d/%n/sieve_dir If the two have been merged, how would I go about configuring the 90-sieve.conf file to get the same results? Thanks for your help.
Re: Mailboxes are in Maildir format. Any good backup tips? Had success with version control?
On 6/30/2014 5:28 PM, deoren wrote: I'm still pretty new to running a mail server, but one thing I've come to appreciate over the years is a good backup strategy. Since I have always run my own servers for practice and for personal use I don't have access to Enterprise backup solutions. Because of that I usually just fall back to scripts and tarballs and offload the content on a regular basis. Right now I'm using LVM snapshots + tarballs for daily backups, but I'd like to get better coverage for incremental changes that occur throughout the day. The size of existing content is low, but (small) changes are frequent. I went with Maildir format because based on my reading it is referred to as time tested and corruption resistant. Because individual emails are stored as separate files this also leads me to believe that a version control system (Git, SVN) would allow for easy point in time restores. I'm also going to research the GNU tar utility's support for incremental archives as that sounds promising. Suggestions and warnings are most welcome. Thanks! Sorry for the late reply, and thanks to everyone who replied with suggestions. I appreciate you taking the time to do that and you've given me a lot of good ideas to look over. Options are good!
Mailboxes are in Maildir format. Any good backup tips? Had success with version control?
I'm still pretty new to running a mail server, but one thing I've come to appreciate over the years is a good backup strategy. Since I have always run my own servers for practice and for personal use I don't have access to Enterprise backup solutions. Because of that I usually just fall back to scripts and tarballs and offload the content on a regular basis. Right now I'm using LVM snapshots + tarballs for daily backups, but I'd like to get better coverage for incremental changes that occur throughout the day. The size of existing content is low, but (small) changes are frequent. I went with Maildir format because based on my reading it is referred to as time tested and corruption resistant. Because individual emails are stored as separate files this also leads me to believe that a version control system (Git, SVN) would allow for easy point in time restores. I'm also going to research the GNU tar utility's support for incremental archives as that sounds promising. Suggestions and warnings are most welcome. Thanks!
