Re: Best practices for backing up small mailserver to remote location

[Kenneth Porter]

On 8/7/2018 5:08 PM, Adi Pircalabu wrote:
- Since you're on dynamic IP at home, set up a VPN tunnel using the 
mailserver as server and HTPC as client. OpenVPN is ubiquitous and 
widely supported.

- rsync your mailboxes using the tunnel connection.
This way you can back up your entire server, not only the mailboxes.


Instead of openvpn, I use openssh. Use compression in the ssh tunnel, 
not the rsync connection, as rsync compression tends to be buggy and 
interrupts the download. I run sshd on a non-standard port to keep my 
logs relatively free of script kiddy noise from people looking for an 
ssh connection to crack. Run fail2ban to lock out the remaining script 
kiddies. Use a client certificate to log in with ssh unprompted, making 
it easy to download in a cron job.


Here's an example of scripting the download. Uncomment the DRYRUN line 
for testing, then comment for production. Add more rsync commands to 
back up different partitions. The --one-file-system prevents rsync from 
trying to back up /dev, /proc, and /sys. The --delete option will remove 
local files that were deleted on the remote server. Use that set of 
options once you're happy that the backup is working right.


#!/bin/sh
#set -e
set -x
#DRYRUN=--dry-run
#RSYNC_OPTIONS="$DRYRUN --one-file-system -avH --delete"
RSYNC_OPTIONS="$DRYRUN --one-file-system -avH"
DEST=/home/rsync/Server1

# Allow one hour so we don't burn up our bandwidth allowance
# from a command error

time timeout 1h \
rsync -e 'ssh -C -p 1234' $RSYNC_OPTIONS example.com:/ ${DEST}/ \
--exclude tmp

# add more rsync commands here for other partitions

Re: folders not visible on copied mail folders

[Kenneth Porter]

--On Thursday, July 19, 2018 10:33 PM -0400 Mark Foley  
wrote:



Shortly after this post, I found a solution here:
http://forums.mozillazine.org/viewtopic.php?t=1097725

In order to see the .Dennis\ Email.Dennis\ Inbox sub-folder you have to
collapse and re-expand the folder list in Thunderbird. It's that simple
... AND that annoyingly obscure!


That sometimes works. Sometimes I have to open the Subscribe dialog and 
open/close the new hierarchy there. It's very tedious and annoying. I'd 
love to have a Thunderbird addon that automatically does this, either on 
demand or at every Thunderbird start when an account is first opened.

Re: Dovecot on CentOS 7

[Kenneth Porter]

On 7/10/2018 9:28 AM, Tracy Greggs wrote:

Did you verify the server is listening on 0.0.0.0 and that your
firewall is not blocking?


CentOS 7 uses firewalld. You'll need to enable the services you use 
(smtp, imap, and pop3) for the default zone. Something like:



firewall-cmd --zone=public --add-service=imap --permanent

firewall-cmd --zone=public --add-service=pop3 --permanent

firewall-cmd --zone=public --add-service=submission --permanent

firewall-cmd --zone=public --add-service=smtp --permanent


https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7

Re: Dovecot 2.3 on CentOS 7.

[Kenneth Porter]

--On Thursday, February 01, 2018 11:58 PM +0200 Reio Remma 
 wrote:



What would be the preferred directory for storing all virtual mail
without modification to system files?


I would guess something under /var/lib. If you plan to host multiple 
virtual servers, /srv might be a better place to locate it.

Ignored mount points forgotten on reboot

[Kenneth Porter]

The list of ignored mount points are stored in a directory (/var/run) 
that's cleared on  reboot. (On CentOS it's a RAM disk.) It seems this 
should be stored in /etc/dovecot to remain persistent across reboots.




I discovered this when I saw a dovecot error message in /var/log/maillog 
that some of my automounts (that don't contain mail directories) were 
missing.


Latest dovecot from this distro is dovecot-2.2.10-8.el7.x86_64. Does the 
new release fix this? (I haven't seen any real problems from it, just log 
noise.) 

Re: Ubuntu Auth Issues with new repository code..

[Kenneth Porter]

Another thing to check is the RPM scripts that run during an upgrade. 
Compare the output of "rpm -q --scripts dovecot" for the old and new 
package. See if the new package is doing all the necessary things 
expected by Ubuntu. Scripts are the most platform-specific part of the 
package and the hardest to make portable.

Re: Renewing certificates

[Kenneth Porter]

--On Wednesday, December 27, 2017 9:24 AM -0500 Bill Shirley 
 wrote:



 --reloadcmd "systemctl reload dovecot.service"
Notice the --reloadcmd.


Thanks. Some digging indicates that this is equivalent to doveadm reload. 
Both paths ultimately send a SIGHUP to the server which initiates a full 
reload of the configuration.


I'll be combining this with a restart of sendmail. Alas, I don't see a way 
to get it to reload its configuration.

Renewing certificates

[Kenneth Porter]

I'm setting up certbot/letsencrypt to provide a certificate for dovecot and 
sendmail. Is it necessary to restart dovecot to load the new certificate, 
as shown in most examples I find in blogs? That seems rude to established 
connections. When does dovecot read the cert and key files? Once at startup 
or each time a connection requests SSL? Is there a preferred locking 
protocol when changing the two files to keep dovecot from reading one while 
the other is being replaced and getting a mismatched pair?

Re: v2.3.0 release candidate released

[Kenneth Porter]

On 12/18/2017 10:53 AM, James wrote:

On 18/12/2017 18:15, Stephan Bosch wrote:

Op 12/18/2017 om 6:16 PM schreef James:



"smtp-server-cmd-helo.c", line 140: void function cannot return value
"smtp-server-cmd-helo.c", line 148: void function cannot return value


Just wondering: which system/compiler is giving these errors?


Sun/Oracle Studio compiler on Solaris.

$ cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31


This is valid syntax for C++14 but invalid for C11. See this answer:

https://stackoverflow.com/questions/35987493/return-void-type-in-c-and-c

Re: hosting emails at home

[Kenneth Porter]

--On Monday, December 11, 2017 1:07 PM -0500 Ruben Safir 
 wrote:



thatis not secure and you might as well use gmail

It is not so hard to just get a static IP and put a mail server up.


Why do you think this isn't secure?

Gmail wouldn't let me run my own spam and AV solution. My external server 
gives me full control, with sendmail, MIMEDefang, SpamAssassin, ClamAV, 
dovecot, and procmail. I could, in principle, keep a remote copy of all my 
mail there and dsync it to my home server. I'm using fetchmail (with SSL 
option) only because I didn't understand dsync when I set it up.


I'm still a bit unclear on how dsync decides which users to sync. All my 
users are real system users, not virtual users. I'd like to retire my 3 
older accounts on my home system to never receive email again, only provide 
it for archival reading, and direct all my mail to new accounts that could 
be dsync'd to the leased external server. So I'd want to limit dsync to 
only sync the new accounts. Which might even be virtual. 

Re: hosting emails at home

[Kenneth Porter]

--On Monday, December 11, 2017 1:06 PM + Darac Marjal 
 wrote:



That's relatively easy. I use the following:


Thanks! My recipe for sendmail is here (section Sendmail workaround, near 
the end of the page), copied from a post on the sendmail newsgroup.




Every time I look into Postfix it looks so much simpler, and your example, 
even with the complicated regex, confirms that. 

Re: hosting emails at home

[Kenneth Porter]

On 12/10/2017 12:39 PM, Stephan H wrote:

I have dovecot postfix setup on my home server as well.  I use a virtual
server in the cloud as my mx record and mail relay and have my home record
on dynamic dns.  It's really effective.


My MX points at a leased virtual server and my home server uses 
fetchmail to pull the mail into local mailboxes. I suppose dsync might 
be used instead of fetchmail.

Re: hosting emails at home

[Kenneth Porter]

--On Sunday, December 10, 2017 7:05 PM + André Rodier 
 wrote:



This is so far what I have achieved:


How about MIMEDefang, ClamAV, and SpamAssassin? I'm currently running 
MD+Clam from sendmail and SA from procmail, but I'm open to seeing the 
equivalent solution with Postfix and the Dovecot LDA.


(One thing that keeps me from switching to Postfix is the need to accept 
"plussed" addresses using both the plus sign and the dot (for websites that 
refuse "+" in an email address).)

Can Dovecot replace fetchmail?

[Kenneth Porter]

I'm using fetchmail to grab mail for multiple accounts from an external 
IMAP server and drop it into local mailboxes via SMTP. It polls the remote 
server every two minutes. Can Dovecot replace this functionality more 
elegantly, using IDLE to avoid the polling necessary with fetchmail? I'd 
like to designate that mail for specific accounts on the external server be 
moved to specific local mailboxes.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: per user procmail filtering and dovecot-lda

[Kenneth Porter]

On 5/17/2017 11:26 AM, Adam Shostack wrote:

Also, procmail is way out of date, no longer maintained, and there are
"semi" known vulnerabilities that haven't been fixed.  See
http://marc.info/?l=openbsd-ports=141634350915839=2  & the
wikipedia page.


What alternatives exist for server-side filtering into folders? Is there 
anything as powerful?



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: an e-mail client for dovecot ?

[Kenneth Porter]

On 7/16/2016 10:22 AM, Mark Foley wrote:

I concur with Charles Marcus' query: can you elaborate on how Thunderbird is 
failing for you?


I run Thunderbird and Mulberry side-by-side, as there are features in 
Mulberry I don't want to give up, even though it's old and buggy. I've 
noticed that Mulberry finds folders in my huge hierarchy (100's of 
folders) that Tbird misses. Notably my SpamAssassin folder, and it's 
consistent across several accounts I monitor. Both programs are set to 
scan all IMAP folders. It's not just because the SA folder is flagged as 
an additional Junk folder. I've got other folders that Tbird misses. 
Most receive automated server mail from Linux services (such as 
logwatch). I haven't been able to find a pattern.

Re: [Dovecot] Lots of pop3-logins

[Kenneth Porter]

--On Friday, June 26, 2009 8:48 AM +1000 Noel Butler 
noel.but...@ausics.net wrote:



What would be nice is, an anti brute force option, like xinetd, X-number
of connections from Y i.p. in Z seconds (optional setting of course) or
maybe a way to extend that to detect if the same i.p  is retrying
constantly using different usernames on every new connection within X
seconds, come to think of it, that way would be much cooler :)


Some good discussion about fighting dictionary attacks here:

http://www.codinghorror.com/blog/archives/001206.html

Re: [Dovecot] tcp_wrappers

[Kenneth Porter]

On Tuesday, June 23, 2009 8:09 PM +0200 Edgar Fuß e...@math.uni-bonn.de 
wrote:



http://dovecot.org/patches/1.1/tcp-wrappers.patch should work.

I'll attach an updated version for 1.2. Remember to run
auto{conf,header,make} after applying.


Typo here (missing p):

+   i_fatal(Tried to use TCP wrapers with 
process_per_connection=no);

Re: [Dovecot] SELinux

[Kenneth Porter]

--On Wednesday, June 10, 2009 12:50 PM +0200 henry ritzlmayr 
dove...@rc0.at wrote:



Am Montag, den 08.06.2009, 12:58 -0700 schrieb Kenneth Porter:

I've temporarily got SELinux set to permissive mode on a fresh install
on  CentOS 5. It was blocking Dovecot's access to ~/mail because the
files were  labeled file_t. What's the correct way to label these?



restorecon path


A naive run on /home/ken/mail didn't change the file types. I had to run 
restorecon /home/ken/mail/*. I'll have to see how to do that recursively 
so all files under /home get labeled. (I restored a bunch of home 
directories from a backup of a Fedora Core 2 system, which predates SELinux 
and hence has no labeling.)


The new labels on the mbox files are user_u:object_r:user_home_t. I'll have 
to see if the default CentOS 5 policy is set to be happy with that.

Re: [Dovecot] IMP reading entire mailbox

[Kenneth Porter]

--On Tuesday, June 09, 2009 2:49 PM -0700 Timo Sirainen t...@iki.fi wrote:


DUH! Please ignore the Corrupted index cache file; the mailbox in
question is a file named delivery.log (i.e. procmail log file) that is
in the user's ~/mail directory. Of course there will be problems
trying
to index this file, it is not an mbox! *sigh*


Hmm. It still seems like there's something Dovecot should do better here.
I'll see what I can do about it with my procmail log file :)


How about a configuration option that's a regex or glob of files to ignore 
in the mail directories?

Re: [Dovecot] Mailbox isn't a valid mbox file

[Kenneth Porter]

--On Monday, June 08, 2009 10:09 AM -0700 Timo Sirainen t...@iki.fi wrote:


It's always only the From line that it doesn't like. Do you really have
tss at iki.fi instead of t...@iki.fi? That's why it's not working.
It's expecting: From single-word timestamp.


That's what's in the file. It's possible I grabbed an archive from mailman 
and dropped it in the directory ages ago, as mailman obfuscates addresses 
like that. Perhaps 0.99 wasn't as fussy about the separator line and just 
looked for From  at the beginning of a line. (Not saying fussy is bad. ;))


I can probably cook up a Perl regex to fix it but it's just a couple of 
list archives at this point so I'm not too worried about them. My biggest 
problem was that the mail client (Mulberry) was stopping it's new-mail scan 
over my hiearchy when it hit the bad folders, so I had to move them out of 
the tree.

Re: [Dovecot] Mailbox isn't a valid mbox file

[Kenneth Porter]

--On Monday, June 08, 2009 11:05 AM -0400 Charles Marcus 
cmar...@media-brokers.com wrote:



rc5 is the latest... you might wanna try with that first...


Thanks. I'll do that as soon as Rawhide catches up. (If it takes too long, 
I'll patch their source RPM to use RC5.)


I'm actually running with a couple patches from Mercurial while I waited 
for Timo's next RC, and it arrived right in the middle of my migration with 
my old server down and me furiously tweaking final settings to get things 
working.

[Dovecot] SELinux

[Kenneth Porter]

I've temporarily got SELinux set to permissive mode on a fresh install on 
CentOS 5. It was blocking Dovecot's access to ~/mail because the files were 
labeled file_t. What's the correct way to label these?

[Dovecot] convert-tool skip_dotfiles is not the actual option

[Kenneth Porter]

Looking at the source for convert-tool.c, I see this:

Usage: username home dir source mail env dest mail env\n \
   [skip_broken_mailboxes] [skip_dotfiles] [alt_hierarchy_char=c]

else if (strcmp(argv[i], skip_dotdirs) != 0)
   set.skip_dotdirs = TRUE;

Looks like the usage line needs to be fixed (dovecot-1.2-0.rc2).

Re: [Dovecot] Converting mbox files with dots in names to Maildir

[Kenneth Porter]

Looks like I need to use the optional convert-tool argument 
alt_hierarchy_char=- to get the desired effect. Looking at the source, 
this is used when the folder name is converted from source format to 
destination format and the name contains the hierarchy separator from the 
destination format.


Alas, if you don't provide this argument, convert-tool (and presumably the 
convert plugin, which shares this code) will just crash with a double-free 
when it encounters such a name.

Re: [Dovecot] Converting mbox files with dots in names to Maildir

[Kenneth Porter]

The option parsing in convert-tool.c won't work, as the strcmp compares are 
wrong. The result should be compared equal to zero, not not-equal. Here's 
corrected code:


   for (i = 5; i  argc; i++) {
   if (strcmp(argv[i], skip_broken_mailboxes) == 0)
   set.skip_broken_mailboxes = TRUE;
   else if (strcmp(argv[i], skip_dotdirs) == 0)
   set.skip_dotdirs = TRUE;
   else if (strncmp(argv[i], alt_hierarchy_char=, 19) == 0)
   set.alt_hierarchy_char = argv[i][19];
   }

Even with this fix, and report of a successful conversion, glibc is 
reporting a double-free:


Info: Successfully converted
*** glibc detected *** /tmp/convert-tool: double free or corruption 
(fasttop): 0x08ae9cc8 ***

Re: [Dovecot] Converting mbox files with dots in names to Maildir

[Kenneth Porter]

Attached is valgrind run.==6804== Memcheck, a memory error detector.
==6804== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==6804== Using LibVEX rev 1658, a library for dynamic binary translation.
==6804== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==6804== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==6804== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==6804== For more details, rerun with: -v
==6804== 
Info: Successfully converted
==6804== Invalid read of size 4
==6804==at 0x80889F2: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x808D4E4: mail_user_deinit_base (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A195: main (in /usr/libexec/dovecot/convert-tool)
==6804==  Address 0x401AFF8 is 48 bytes inside a block of size 52 free'd
==6804==at 0x4004FDA: free (vg_replace_malloc.c:233)
==6804==by 0x808896C: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A836: convert_storage (in /usr/libexec/dovecot/convert-tool)
==6804==by 0x804A177: main (in /usr/libexec/dovecot/convert-tool)
==6804== 
==6804== Invalid read of size 4
==6804==at 0x80889F5: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x808D4E4: mail_user_deinit_base (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A195: main (in /usr/libexec/dovecot/convert-tool)
==6804==  Address 0x401AFC8 is 0 bytes inside a block of size 52 free'd
==6804==at 0x4004FDA: free (vg_replace_malloc.c:233)
==6804==by 0x808896C: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A836: convert_storage (in /usr/libexec/dovecot/convert-tool)
==6804==by 0x804A177: main (in /usr/libexec/dovecot/convert-tool)
==6804== 
==6804== Invalid read of size 4
==6804==at 0x8088929: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x808D4E4: mail_user_deinit_base (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A195: main (in /usr/libexec/dovecot/convert-tool)
==6804==  Address 0x401AFF0 is 40 bytes inside a block of size 52 free'd
==6804==at 0x4004FDA: free (vg_replace_malloc.c:233)
==6804==by 0x808896C: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A836: convert_storage (in /usr/libexec/dovecot/convert-tool)
==6804==by 0x804A177: main (in /usr/libexec/dovecot/convert-tool)
==6804== 
==6804== Invalid read of size 4
==6804==at 0x808892C: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x808D4E4: mail_user_deinit_base (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A195: main (in /usr/libexec/dovecot/convert-tool)
==6804==  Address 0x401AFEC is 36 bytes inside a block of size 52 free'd
==6804==at 0x4004FDA: free (vg_replace_malloc.c:233)
==6804==by 0x808896C: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A836: convert_storage (in /usr/libexec/dovecot/convert-tool)
==6804==by 0x804A177: main (in /usr/libexec/dovecot/convert-tool)
==6804== 
==6804== Invalid read of size 4
==6804==at 0x8088946: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x808D4E4: mail_user_deinit_base (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A195: main (in /usr/libexec/dovecot/convert-tool)
==6804==  Address 0x401AFDC is 20 bytes inside a block of size 52 free'd
==6804==at 0x4004FDA: free (vg_replace_malloc.c:233)
==6804==by 0x808896C: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A836: convert_storage (in /usr/libexec/dovecot/convert-tool)
==6804==by 0x804A177: main (in /usr/libexec/dovecot/convert-tool)
==6804== 
==6804== Invalid write of size 4
==6804==at 0x808895A: mail_namespace_free (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x8088A0C: mail_namespaces_deinit (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x808D4E4: mail_user_deinit_base (in 
/usr/libexec/dovecot/convert-tool)
==6804==by 0x804A195: main (in /usr/libexec/dovecot/convert-tool)
==6804==  Address 0x401AFDC is 20 bytes inside a block of size 52 free'd
==6804==at 0x4004FDA: free (vg_replace_malloc.c:233)

[Dovecot] Converting mbox files with dots in names to Maildir

[Kenneth Porter]

I tried to run convert-tool from dovecot-1.2-0.rc2 on a tree of mbox files 
with some containing dots in the filenames and got this failure:


# /usr/libexec/dovecot/convert-tool ken /home/ken mbox:/home/ken/mail 
maildir:/home/ken/Maildir
Error: Mailbox conversion: Couldn't create mailbox Lists.WINE.patches: 
Mailbox already exists

Error: Internal failure
*** glibc detected *** /usr/libexec/dovecot/convert-tool: double free or 
corruption (fasttop): 0x08ce6cc8 ***



The directory in question contains these files:

# ls Lists/WINE/
announce  bugs  cvs  devel  patches  patches.20050130

Will I need to go through the (large) file tree and rename all files with 
dots in the names? If so, anyone have a script that will do that? (Changing 
the dot to dash would be fine with me.)

[Dovecot] Slashdot mention: Dovecot swap usage

[Kenneth Porter]

http://ask.slashdot.org/comments.pl?sid=982541cid=25230889

Re: [Dovecot] How Can I Tell How Dovecot Was Installed?

[Kenneth Porter]

--On Wednesday, August 20, 2008 11:23 AM -0400 Charles Marcus 
[EMAIL PROTECTED] wrote:



Why anyone would knowingly run ancient versions of critical apps is
beyond me.


Stability. It's not uncommon for apps to be interdependent. Upgrading one 
can have unexpected consequences in another app.


For this reason, RHEL back-ports fixes for critical apps rather that 
automatically upgrading to the latest version. For it to do so, it needs to 
have patches for specific issues registered in Bugzilla.


For those of us willing to take the risk of wholesale upgrade to the 
bleeding edge, we can grab an RPM from Red Hat's Rawhide distro. My 
practice is usually to grab the source RPM and rebuild it to match the 
libraries I have on my distro (CentOS 5).


In some cases, 3rd party distros like atrpms.net and RPMForge carry the 
latest version pre-built for many distros. If I need a package that 
RPMForge supports, I'll grab the binary from there.

Re: [Dovecot] How Can I Tell How Dovecot Was Installed?

[Kenneth Porter]

--On Wednesday, August 20, 2008 7:35 AM -0400 Blake Carver 
[EMAIL PROTECTED] wrote:



I guess I'm not quite sure how to interpret this to help me figure out
my problem, there are changes rpm reports, does this mean that an RPM
was installed but so was a source package?

rpm -V -v dovecot
 c /etc/dovecot.conf


This is a config file, as denoted by the c. The row of dots means the 
file is pristine (hasn't been modified since it was installed).



S.5T c /etc/rc.d/init.d/dovecot


This config file is different from the package. I don't recall what all the 
flags mean but the 5 means an MD5 checksum mismatch. As a rule, 
initscripts shouldn't be modified unless you're doing something tricky, so 
this was likely replaced from a tarball install.



prelink: /usr/libexec/dovecot/dict: at least one of file's
dependencies has changed since prelinking
S.?.   /usr/libexec/dovecot/dict
prelink: /usr/libexec/dovecot/dovecot-auth: at least one of file's
dependencies has changed since prelinking
S.?.   /usr/libexec/dovecot/dovecot-auth


All of these prelink errors suggest that your binaries were overwritten 
from a tarball installation. The easy fix is to erase (rpm -e) the 
package and re-install it, likely upgrading to a newer package at the same 
time.



 d /usr/share/doc/dovecot-1.0/REDHAT-FAQ.txt


d files are documentation, and if you're tight on disk space, you can 
suppress installation of documentation when the package is installed.

Re: [Dovecot] SpamAssassin and Maildir with Dovecot

[Kenneth Porter]

--On Tuesday, August 19, 2008 6:08 AM +0300 Timo Sirainen [EMAIL PROTECTED] 
wrote:



Does it modify any messages? If not, there shouldn't be any problems.


No, it just identifies which files are messages and reads them to train 
SA's Bayes database. The patch just does better identification.


I typically run sa-learn from a cron job a few times a day. I have 
Uncaught and FalsePositives folders and run it against those to correct 
the automatic training that happens on delivery.

Re: [Dovecot] Migrating mbox to maildir

[Kenneth Porter]

On Thursday, August 14, 2008 3:46 PM -0400 Mike Hobbs [EMAIL PROTECTED] 
wrote:



I'd like to use maildir with all my new users, but I'd like to be able to
continue using mbox for my old users and slowly convert them as I get
time.


I did this a week ago for about a dozen users and the system seems more 
responsive.


Timo covered the Dovecot side. You didn't say what delivery agent you're 
using. I use procmail and put this .procmailrc in the home directories of 
the converted users:


# deliver to Maildir
MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/

The file should be owned by the user. (I forgot to chown the file for one 
user and mail was delivered to the old /var/spool/mail/user mbox file. 
After I figured it out, I did another conversion with convert-tool to a 
temporary Maildir-new and moved the converted inbox into a new folder under 
his previously-converted ~/Maildir.)


If a user is using procmail for filtering, he'll need to change the 
destination folder lines in his filters. This list could be filtered with a 
rule like this:


:0 :
* ^Sender:.*dovecot
$HOME/Maildir/.Lists.Mail.Dovecot/

Note the trailing slash on delivery lines to indicate that the destination 
is in Maildir format.


To avoid reconfiguring the folder separator on clients, you can add this 
namespace directive to dovecot.conf:


namespace private {
  separator = /
  inbox = yes
}

[Dovecot] SpamAssassin and Maildir with Dovecot

[Kenneth Porter]

A patch has been proposed for SpamAssassin to process Maildir folders of 
spam:


https://issues.apache.org/SpamAssassin/show_bug.cgi?id=3003

Is this patch compatible with Dovecot's implementation of Maildir? For 
example, is anything needed to avoid stepping on Dovecot's metadata?

[Dovecot] POP3 dictionary attacks

[Kenneth Porter]

I'm seeing strings of failed POP3 login attempts with obvious bogus 
usernames coming from different IP addresses. Today's originated from 
216.31.146.19 (which resolves to neovisionlabs.com). This looks like a 
botnet attack. I got a similar probe a couple days ago. Is anyone else 
seeing these?


The attack involves trying about 20 different names, about 3-4 seconds 
apart. Here's a few sample log lines:


dovecot: Aug 15 04:15:45 Error: auth-worker(default): 
pam(mike,216.31.146.19): pam_authenticate() failed: User not known to the 
underlying authentication module
dovecot: Aug 15 04:15:49 Error: auth-worker(default): 
pam(alan,216.31.146.19): pam_authenticate() failed: User not known to the 
underlying authentication module
dovecot: Aug 15 04:15:53 Error: auth-worker(default): 
pam(info,216.31.146.19): pam_authenticate() failed: User not known to the 
underlying authentication module
dovecot: Aug 15 04:15:57 Error: auth-worker(default): 
pam(shop,216.31.146.19): pam_authenticate() failed: User not known to the 
underlying authentication module


Timo, can you add the port used in the attempt to the error log entry? (It 
does show up in the info log entry, but that means I need to correlate 
lines in the two log files.)

Re: [Dovecot] POP3 dictionary attacks

[Kenneth Porter]

On Friday, August 15, 2008 5:39 PM -0400 Charles Marcus 
[EMAIL PROTECTED] wrote:



Just install some kind of blocking on your firewall (fail2ban is a good
one), and let it take care of the worst of it...


Thanks, researching it now

Looks like an RPM might be available for CentOS 5. There's a HOWTO here for 
configuring it with iptables:


http://www.the-art-of-web.com/system/fail2ban/

Re: [Dovecot] POP3 dictionary attacks

[Kenneth Porter]

--On Friday, August 15, 2008 5:51 PM -0400 Bruce Bodger 
[EMAIL PROTECTED] wrote:



fail2ban will not work for this as the incoming ip addresses are
spoofed.  fail2ban would end up blocking legitimate servers.


How do you spoof a source address on a TCP connection? I was unaware that 
was possible. How would replies know how to get back to the spoofing host? 
At best, you can spoof another host on your own routed segment. Unless you 
have control of the routing tables on the connecting routers, of course.

[Dovecot] Migrating mbox to maildir

[Kenneth Porter]

On Wednesday, August 06, 2008 10:18 PM -0400 Timo Sirainen [EMAIL PROTECTED] 
wrote:



So I guess you're using mbox? There it's safe to delete everything. If
you're using maildir you should keep dovecot-uidlist and dovecot-keywords.


I'm in the process of getting my head around the least painful path to 
convert everything to maildir, given the headaches mbox is giving me here.


It looks like I can leave mail_location unset, and use a basic namespace to 
force the separator to be the same as for mbox:


namespace private {
  separator = /
  inbox = yes
}

procmail is used as the LDA on CentOS so I then need to change procmailrc 
to direct incoming mail to Maildir, presumably by adding:


MAILDIR=$HOME/Maildir
DEFAULT=$MAILDIR/

It looks like I can do this on a per-user basis by putting that in a user's 
.procmailrc until I migrate everybody.

Re: [Dovecot] Fwd: [MORG] IMAP5 List

[Kenneth Porter]

--On Tuesday, August 12, 2008 3:17 AM -0400 Timo Sirainen [EMAIL PROTECTED] 
wrote:



If anyone's interested, especially client developers. It's been a bit
quiet there after the initial rush.


Very interesting. Thanks for the forward. I'll send this on to the Mulberry 
developer list.


One thing I'd like to see is the ability of the server to notify the client 
of updates on any folder, not just subscribed or open ones. From what I 
understand, the client must poll all unsubscribed folders, which can be 
expensive. If one has a lot of folders (mine count well over 100, due to 
the large number of mailing lists to which I subscribe, and that I filter 
to them on the server side), the time to find new mail can be large and 
costly on the server.

[Dovecot] Disabling access for one user

[Kenneth Porter]

I'm converting my system from mbox to Maildir one user at a time, and I'd 
like to disable access for the user I'm working on. Is there a way to tell 
Dovecot to lock out a specific user? Perhaps with a control file in the 
home directory?


At the same time, how can I get sendmail+procmail to tempfail incoming 
messages for one user until I'm done?

[Dovecot] Procmail versus Dovecot LDA

[Kenneth Porter]

--On Thursday, August 07, 2008 3:37 PM -0400 Timo Sirainen [EMAIL PROTECTED] 
wrote:



If you used Dovecot's deliver, the deny passwd should have worked, but
I've no idea about procmail.


I'll note that I'm using procmail because of the ability to filter and run 
SpamAssassin from it. Does the Dovecot LDA provide the equivalent? (I know 
there's Sieve, though haven't looked into how one uses it.) If so, how hard 
is it to migrate my procmailrc files?

[Dovecot] Purpose of files under .imap

[Kenneth Porter]

I've got a user with an unusable account. Tbird just sits in a loop 
endlessly logging in over and over when a particular folder is selected.


What files under .imap associated with that folder can be safely deleted? 
What's stored in all of them?


I see all of these:

.customflags
dovecot.index
dovecot.index.cache
dovecot.index.log
.imap.index
.imap.index.data
.imap.index.log
.imap.index.tree

[Dovecot] Next message unexpectedly lost

[Kenneth Porter]

Using 1.1.2. I'm getting the above message over and over in the error log. 
Dovecot drops the connection and the client (Tbird) just keeps retrying in 
an endless loop.


Using Wireshark to sniff the exchange, it looks like the command that fails 
looks like this:


5 UID fetch 1:9749,9751:9763,9765:9930,9932,9934:9942 (UID RFC822.SIZE 
FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority 
X-Priority References Newsgroups In-Reply-To Content-Type)])


Dovecot seems to be shutting down after receiving this.

Mulberry doesn't seem to have the problem, presumably because it's sending 
a different command sequence that doesn't stroke this.


Here's the failing code, in i_stream_raw_mbox_read :

   if (stream-istream.v_offset -
   rstream-hdr_offset + new_pos  rstream-mail_size) {
   /* istream_raw_mbox_set_next_offset() used invalid
  cached next_offset? */
   i_error(Next message unexpectedly lost from %PRIuUOFF_T,
   rstream-hdr_offset + rstream-mail_size);
   rstream-eof = TRUE;
   rstream-corrupted = TRUE;
   return -1;
   }

I've tried deleting the associated .imap/folder contents but it must 
regenerate the same bad data as it happens again.

[Dovecot] RFE: Disallow DELETE of non-empty MBOX

[Kenneth Porter]

It looks like this is already the rule for maildir, where one can't remove 
the folder if any files or subdirectories are present. I'd like to get this 
option for mbox folders, as I'd like to prevent accidents where users 
accidentally delete large folders by clicking the wrong thing and then 
too-quickly approving the confirmation dialog that pops up. (Impatient 
upper level management tends to do this. ;))


BTW, I'm using Mulberry for my client, and it unfortunately puts Mark 
contents seen right next to Delete folder on the context menu. I'm aware 
of the issue so I tend to be extra careful when I finish with the folder 
associated with a busy mailing list and mark all the uninteresting messages 
seen.

Re: [Dovecot] RFE: Disallow DELETE of non-empty MBOX

[Kenneth Porter]

On Monday, August 04, 2008 2:41 PM -0400 Timo Sirainen [EMAIL PROTECTED] 
wrote:


On Aug 4, 2008, at 2:23 PM, Kenneth Porter wrote:


It looks like this is already the rule for maildir, where one can't
remove the folder if any files or subdirectories are present.


Oh? I don't remember this kind of a feature..


Just went looking at the 1.1.1 code again and mis-remembered what I saw. I 
was looking at mbox_list_delete_mailbox and it was the mbox folder that 
contains folders behavior I was remembering. It will only unlink a folder 
if it contains no subfolders. ISTM that it should either recursively delete 
for consistency, or not delete non-empty folder that contains messages 
folders. Or does the standard require different behavior here?



The problem is that I think this should be more of a per-client setting
rather than a global setting. For example with Thunderbird (well, and
non-mboxes) deleting the mailbox just renames it under Trash. Disallowing
that would be annoying. And I suppose this issue really should be handled
by the client UI instead of the server..


Note that renaming under Trash won't work if Trash is mbox, because mbox 
can't have subfolders. (Or did this change in Dovecot in 1.1.2?)


I'd be happy to get this functionality as a plugin, but I haven't been able 
to get my head around how to write a plugin. It looks like some variation 
of the ACL plugin might do the job, since it also establishes restrictions 
on whether a delete can go through.

Re: [Dovecot] RFE: Disallow DELETE of non-empty MBOX

[Kenneth Porter]

It occurs to me that another possibility is to make only the Trash folder 
maildir, but I think Tbird only allows setting the folders can contain 
both messages and folders option account-wide, not per-folder.

Re: [Dovecot] FETCH for mailbox got too little data

[Kenneth Porter]

I've now enabled error logging to a separate log file and see this on 
today's occurrence:


dovecot: Jul 08 09:42:39 Error: IMAP(mortal): Next message unexpectedly 
lost from 41838245
dovecot: Jul 08 09:42:39 Error: IMAP(mortal): Next message unexpectedly 
lost from 41838245
dovecot: Jul 08 09:42:39 Panic: IMAP(mortal): file message-parser.c: line 
770 (message_parser_parse_next_block):
assertion failed: (ctx-input-eof || ctx-input-closed || 
ctx-input-stream_errno != 0 || ctx-broken)

dovecot: Jul 08 09:42:39 Error: IMAP(mortal): Raw backtrace:
imap [0x80cfc80] -
imap [0x80cfcda] -
imap [0x80cf57c] -
imap(message_parser_parse_body+0) [0x80c8e00] -
imap(index_mail_cache_parse_continue+0x22) [0x8094102] -
imap [0x807cd81] -
imap(mbox_save_continue+0x38) [0x807ce28] -
imap(mail_storage_copy+0xe4) [0x809e5e4] -
imap(cmd_copy+0x1d2) [0x805b252] -
imap(cmd_uid+0x59) [0x805f4e9] -
imap [0x805fe8c] -
imap [0x805ff35] -
imap [0x80606f5] -
imap(client_input+0x5e) [0x806090e] -
imap(io_loop_handler_run+0x100) [0x80d75d0] -
imap(io_loop_run+0x28) [0x80d6748] -
imap(main+0x4ac) [0x806845c] -
/lib/libc.so.6(__libc_start_main+0xdc) [0xc2edec] -
imap [0x805a271]
dovecot: Jul 08 09:42:39 Error: child 31406 (imap) killed with signal 6

Re: [Dovecot] OT - Legal disclaimers

[Kenneth Porter]

--On Wednesday, July 02, 2008 2:25 PM +0200 Joseba Torre 
[EMAIL PROTECTED] wrote:



- in english:
http://www.goldmark.org/jeff/stupid-disclaimers/


That's a good one. Be sure to follow the link to his funny examples.

http://www.goldmark.org/jeff/stupid-disclaimers/fun.html

Some other discussion of silly ones here (look for sillier disclaimers).

http://lists.roaringpenguin.com/pipermail/mimedefang/2005-December/thread.html

[Dovecot] FETCH for mailbox got too little data

[Kenneth Porter]

Using 1.1.1. Got this error message in a tight loop, using both Tbird and 
Mulberry 3 as client:


FETCH for mailbox INBOX UID 32994 got too little data: 1616 vs 1649

I get this repeatedly alternating with a login line. What does this mean?

I stopped the server, zipped ~/mail/.imap/INBOX to hide it and let dovecot 
recreate it, and things seem to be working again. Is there a less 
destructive way to fix this in the future?


Delivery is by procmail.

Re: [Dovecot] FETCH for mailbox got too little data

[Kenneth Porter]

--On Tuesday, July 01, 2008 10:51 PM +0300 Timo Sirainen [EMAIL PROTECTED] 
wrote:


Delete dovecot.index.cache file. Although I thought v1.1 did this
automatically.


Is this file obsolete? Should I remove it for all folders, or just ones 
that exhibit a problem? (I see many of them in the folder hierarchy.)

Re: [Dovecot] FETCH for mailbox got too little data

[Kenneth Porter]

--On Tuesday, July 01, 2008 11:36 PM +0300 Timo Sirainen [EMAIL PROTECTED] 
wrote:


It contains cached data which speeds up Dovecot's replies to clients. So
delete them only if you see problems for a specific mailbox. They're
recreated the next time user opens the mailbox.


After the error message is logged, the code in imap_fetch_send() invokes 
this:


mail_set_cache_corrupted(ctx-mail, ctx-cur_size_field);

What uses that? Is that supposed to ultimately prevent the retry from using 
the cache file? It seems like that mechanism isn't working, as the client 
was getting into a loop.

[Dovecot] Wiki: Fedora links

[Kenneth Porter]

Convenience link to add to the Fedora section at 
http://wiki.dovecot.org/PrebuiltBinaries:


http://mirrors.fedoraproject.org/publiclist/

[Dovecot] 1.1.1-1 gotcha with Fedora Rawhide package

[Kenneth Porter]

I just installed the Rawhide package on my CentOS 5 system. The one item 
that bit me is that the config file defaults to using interface [::] so 
it only listens on IPv6. (This is from a patch in the package that changes 
the upstream default of *, so it only affects those using the Fedora 
package.)


For those wanting to track the issue, here's the Bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=453054

I rebuilt the package from the source RPM, to make sure it was tuned to 
the C5 distro.


I got the source RPM here, from the Portland State mirror:

http://mirrors.cat.pdx.edu/fedora/linux/development/source/SRPMS/dovecot-1.1.1-1.fc10.src.rpm

Here's a full list of Rawhide mirrors:

http://mirrors.fedoraproject.org/publiclist/Fedora/development/

If you'd like to see all Red Hat bugs associated with dovecot, here's a 
suitable query:


https://bugzilla.redhat.com/buglist.cgi?component=dovecot

Re: [Dovecot] typo in failures.c

[Kenneth Porter]

--On Saturday, June 07, 2008 5:11 AM +0300 Timo Sirainen [EMAIL PROTECTED] 
wrote:


I wish gcc warned about bad enum usages, it would have caught this.


Wow, that surprised me that it lacked that, as I'm so used to it on 
Windows. But I mostly code in C++ there, so perhaps the conversion in C is 
legal?


http://gcc.gnu.org/ml/gcc/2004-07/msg00375.html

Except that conversion from one enum type to another looks like it should 
be illegal based on that message.

Re: [Dovecot] v1.0.14 released

[Kenneth Porter]

--On Tuesday, June 03, 2008 5:56 PM +1000 Curtis Maloney 
[EMAIL PROTECTED] wrote:



So include the work-around (that doesn't break anything) in Dovecot, and
notify the maintainers of the broken clients to Get a clue(tm) :P


Which clients/versions? Can we name names?

Re: [Dovecot] How to set MDNSent flag on a large amount of mails?

[Kenneth Porter]

--On Wednesday, June 04, 2008 1:17 AM +0800 Patrick Nagel 
[EMAIL PROTECTED] wrote:



I'll give it a try tomorrow... netcat would be the bridge between my shell
and dovecot then, I guess?


Another possibility would be to use the c-client library, part of the 
uw-imap package:


http://www.washington.edu/imap/

Re: [Dovecot] v1.1.rc8 released

[Kenneth Porter]

--On Tuesday, June 03, 2008 3:49 PM +0300 Timo Sirainen [EMAIL PROTECTED] 
wrote:


dbox is half-designed to support this. It supports arbitrary metadata
(unlike maildir) and I've already written 3 lines of code to get this
implemented ;)

/* Pointer to external message data. Format is:
   1*(start offset byte count ref) */
DBOX_METADATA_EXT_REF   = 'X',

There's no code to actually read/write such metadata though. Also I'm
not exactly sure what the ref is. Maybe just a filename used to store
the data.


LOL, so I'm not the only one who designs like that. I think of it like 
sculpting: Throw some clay on the table and then scrape away anything 
that's not part of my objective. It's the right-brain side of programming. 
(And the hardest part.)

Re: [Dovecot] v1.0.14 released

[Kenneth Porter]

--On Tuesday, June 03, 2008 8:58 PM +0300 Timo Sirainen [EMAIL PROTECTED] 
wrote:


Which clients/versions? Can we name names?


http://dovecot.org/list/dovecot/2008-April/030245.html


Ah, a mobile phone. Which means a firmware upgrade, and a niche market, 
which means a client fix is less likely.

Re: [Dovecot] Upgrade To New Version

[Kenneth Porter]

On Thursday, May 29, 2008 11:51 AM +1000 Curtis Maloney 
[EMAIL PROTECTED] wrote:



I read the WIKI link previously suggested and it was very dry and left
me with a lot of questions...


Such as...?


I run an all-IMAP shop, and the one thing that confused me was the UID 
setting in the POP3 section. I didn't want my users who synchronize against 
a local copy of their mail (eg. to read on the airplane) to have to 
re-download it again. I think the one user for which this was a concern 
ended up re-downloading anyway.


Apart from that one issue, the upgrade was painless.

Re: [Dovecot] Disallow folder delete

[Kenneth Porter]

On Friday, May 23, 2008 10:38 AM -0700 Daniel L. Miller 
[EMAIL PROTECTED] wrote:



This actually may have a real benefit to some specialty folders - such as
junk/nojunk folders that are looked for by a scanning re-classifier.  Can
you give an example of how to make...Inbox/Junk non-deletable (or even
better, update the wiki)?


INBOX is special-cased in cmd-delete.c.

I don't yet see where plugins get invoked so I haven't yet found where the 
ACL plugin can veto the delete command.

Re: [Dovecot] Disallow folder delete

[Kenneth Porter]

On Wednesday, May 21, 2008 7:00 AM -0400 Charles Marcus 
[EMAIL PROTECTED] wrote:



On 5/20/2008 9:53 PM, Kenneth Porter wrote:

It might be nice to have a mode that disallows deletion of *non-empty*
folders. In order for a user to delete the folder, the folder must first
be emptied and purged.

Alas, deleting messages can be undone, but folders can't be, and the UI
of a client doesn't necessarily make this obvious.


Actually, a properly configured client will simply move the folder to the
Trash - where the user can recover it if it was a mistake, unless/until
the trash is empty.


This depends on the storage type. mbox can't hold a folder in a folder, so 
where do you put a deleted folder if Trash is an mbox?


I looked at the 1.0.13 source and found that deleting a non-empty mbox 
folder-to-hold-folders will fail (see mbox_mailbox_delete() in 
mbox-storage.c), but a non-empty folder-to-hold-messages will succeed.


I think adding this to cmd-delete.c after the client workaround part should 
prevent this. The message is taken from mbox_mailbox_delete but without the 
folder name.


struct mailbox_status status;
if (mailbox_get_status(mailbox, 0, status)  0) {
   return FALSE;
}
if (status.messages  0)
{
   client_send_tagline(cmd, NO Folder isn't empty, can't delete it.);
   return TRUE;
}

Re: [Dovecot] Searching the Archives (was: Re: dovecot developer documentation)

[Kenneth Porter]

On Wednesday, May 21, 2008 11:49 PM -0400 John Simpson [EMAIL PROTECTED] 
wrote:



how would somebody who has an existing mailing list (managed by
ezmlm-idx) set up IMAP access to their list archives like this?


That would make a nice HOWTO for the wiki. I'd also like to see the answer 
for a mailman system.

Re: [Dovecot] Disallow folder delete

[Kenneth Porter]

On Tuesday, May 20, 2008 8:39 AM -0700 Scott Silva [EMAIL PROTECTED] 
wrote:



I usually make users wait a while before restoring their mistakes. A few
hours of thinking about it might make them think about it


Assuming it was a mistake. How long do you then wait in turn before he 
gives you your paycheck? ;)

[Dovecot] Disallow folder delete

[Kenneth Porter]

Is there a straightforward way to disallow the deletion of all IMAP 
mailboxes?


I have a user who's deleted an important IMAP mailbox and I'm now 
recovering a recent copy from the backup. But I'd rather just blanket 
disallow all folder deletions.


The user is using Thunderbird and this has happened more than once so I 
suspect Tbird is willing to let a folder get deleted too easily. Perhaps 
there was a delay in the confirmation dialog and the user clicked ahead and 
confirmed something he shouldn't have.


I'm looking at http://wiki.dovecot.org/ACL and it looks like I should be 
able to use a group override to disallow x (mailbox delete) but the page 
says that groups aren't implemented, so I don't know how one says that 
nobody can do this for any mailbox.


I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent).

Re: [Dovecot] Disallow folder delete

[Kenneth Porter]

On Monday, May 19, 2008 4:07 PM -0700 Kenneth Porter 
[EMAIL PROTECTED] wrote:



I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent).


I think I'm misinterpreting the CentOS package's version number. The 
package is listed as:


dovecot-1.0-1.2.rc15.el5.src.rpm

I think that means 1.0 rc15 and RPM packaging version 1.2.


From the package changelog:


* Fri Dec 22 2006 Tomas Janousek [EMAIL PROTECTED] - 1.0-1.2.rc15
- reenabled GSSAPI (#220582)

* Tue Nov 21 2006 Petr Rockai [EMAIL PROTECTED] - 1.0-1.rc15
- update to latest upstream, fixes a few bugs, plus a security
 vulnerability (#216510, CVE-2006-5973)

Re: [Dovecot] Disallow folder delete

[Kenneth Porter]

On Monday, May 19, 2008 9:43 PM -0400 Charles Marcus 
[EMAIL PROTECTED] wrote:



Thats pretty drastic - I'd have a rebellion on my hands if I tried that
here.


The userbase is small, and I'd even be willing to set this up for one user 
were that to happen. Most users aren't that sophisticated and aren't 
creating folders in the first place. (Their inboxes tend to be horribly 
huge because of it.)



I'm using 1.2.rc15 from CentOS 5 (RHEL5 equivalent).


Actually, that would be 1.0rc15 - and it is way old, time to upgrade...
atrpms.net has current versions...


How hard is the upgrade? Just install the new RPM, or is there any 
configuration to update? (I'm currently using a pretty stock installation 
that uses mbox in /var/spool/mail (for inbox) and /home/user/mail.


I did see 1.0.13 in Rawhide, so I figure I'd just grab the SRPM and 
build/package against the RHEL libraries.

Re: [Dovecot] Using Dovecot as Asterisk PBX voicemail server

[Kenneth Porter]

--On Monday, November 12, 2007 6:49 PM -0500 Andrew Girling 
[EMAIL PROTECTED] wrote:



One possible solution is that you grant Asterisk access to the  mailboxes
with as a master user with a  (strong) master password.  See  the wiki
for more information:

http://wiki.dovecot.org/Authentication/MasterUsers


Excellent, that looks like a perfect solution to the problem.

[Dovecot] Using Dovecot as Asterisk PBX voicemail server

[Kenneth Porter]

I'm reading the Asterisk book, 2nd edition, and it describes how one can 
set up voicemail to be delivered by IMAP to a voicemail folder. Asterisk 
can monitor flags on the folder so that the message available light on 
one's phone tracks the state of the read flag in the folder. One can 
either dial in for one's voicemail or listen to it from one's favorite IMAP 
client. (Dovecot is mentioned in the book.)


I'm wondering how one would set up auth for this? Asterisk needs to log in 
to the account to deliver the voicemail and to check its state, but I 
wouldn't want to put everyone's mail password in plaintext in Asterisk's 
voicemail.conf file.


Would I set up a separate IMAP account for each user to hold their 
voicemail, and use simple passwords (such as the PIN they use for phone 
access to voicemail) in the Asterisk config? Or is there a way to set up 
Dovecot to allow a second user to login to a specific IMAP folder in all 
accounts, in the same way the local delivery agent has write access to all 
users' mailbox?


Google's page for the book:

http://books.google.com/books?id=vtQxJ3oSm64Cdq=asterisk+book

Dovecot mentions:

http://books.google.com/books?id=vtQxJ3oSm64Cdq=asterisk+bookq=dovecot#search

[Dovecot] UIDL and IMAP

[Kenneth Porter]

I finally got my aging FC2 box retired and moved all email to my new CentOS 
5 box. My site is all-IMAP, no POP3.


I have one user who downloads all email to Thunderbird on his laptop so 
that he can work offline while away from a network connection (eg. on an 
airplane). I forgot to change the pop3_uidl_format setting as described 
here:


http://wiki.dovecot.org/Upgrading/1.0

So he was seeing repeated downloads of all his mail (about 300 MBytes) 
every time he connected. (I'm not sure why it didn't happen only the first 
time.) I changed the setting and haven't heard back whether if fixed things 
for him.


Does this setting in fact get used by IMAP? It's in the POP3 section, so 
I'm wondering if it takes effect when one is using IMAP from the client.


CentOS 5 is currently shipping with:

dovecot-1.0-1.2.rc15.el5

I may look for a newer release. CentOS, based on RHEL, is intended to be a 
conservative distro, so I'll probably need to look at RPMForge (an addon 
repository of more exotic and bleeding edge software) to see if it offers a 
newer release.

[Dovecot] OT Project idea: IMAP plugin for Google Desktop

[Kenneth Porter]

Posting here, as Dovecot seems to be the premier IMAP server available.

In case anyone is looking for something to work on, I found today that 
Google Desktop only understands email clients that keep mail on the client, 
and it would be nice if there was a plugin that understood IMAP. Here's a 
site that seems to explain how to write such plugins:


http://www.plugindevelopment.com/

Re: [Dovecot] Migrate 0.99 MBox into 1.0rc15-2

[Kenneth Porter]

--On Saturday, August 25, 2007 7:07 PM -0400 Charles Marcus 
[EMAIL PROTECTED] wrote:



Also - why rc15? Thats really old now. If your're doing a migration, why
not migrate to the newest version?


Perhaps the latest his distro offers?

Perhaps we need a wiki page showing alternate repos that offer a more 
up-to-date Dovecot for the more conservative distros (like RHEL and 
CentoOS).

Re: [Dovecot] (SPAM? 05.7) Dovecot, Postfix and SMTP AUTH....

[Kenneth Porter]

You may not get a reply because your home domain is in the SURBL list, so 
your message will likely end up in everyone's spam folder. I've pasted the 
SpamAssassin report below.



Content analysis details:   (5.7 points, 5.0 required)

 pts rule name  description
 --
-- -0.0 SPF_HELO_PASS
SPF: HELO matches SPF record
-0.0 SPF_PASS   SPF: sender matches SPF record
-2.6 BAYES_00   BODY: Bayesian spam probability is 0 to 1%
[score: 0.]
 4.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL
blocklist [URIs: interia.pl]
 3.8 URIBL_AB_SURBL Contains an URL listed in the AB SURBL
blocklist [URIs: interia.pl]

Re: [Dovecot] (SPAM? 05.7) Dovecot, Postfix and SMTP AUTH....

[Kenneth Porter]

On Wednesday, April 25, 2007 9:29 PM +0200 Stephan Bosch 
[EMAIL PROTECTED] wrote:



You might wanna remove/obfuscate the offending URI then eh? :) Your reply
is flagged as spam this way as well..


Hehe, I thought about that but couldn't see how to cc him, unless I bcc'd 
him.

Re: [Dovecot] v1.0.0 released (in Red Hat Rawhide)

[Kenneth Porter]

--On Friday, April 13, 2007 2:22 PM -0700 Troy Engel [EMAIL PROTECTED] 
wrote:



Hi Tomas, if you want to feed this back upstream based on the work I've
done with Axel:

dovecot-1.0.beta2-pam-tty.patch: no longer needed, applied upstream in
rc22 (slightly different but same result)

dovecot-1.0.rc15-default-settings.patch: needs reworked, these files it's
patching have changed a lot. The latest rework I did was for rc29, which
applies cleanly to 1.0.0 as well (just verified today). Additionally we
added a default (commented out) /var/log/dovecot.log setting for the
logfile in the default conf file.

There's also an added dovecot logrotate.d script (using SIGUSR1) to
support the above log; alas, right now I can't connect to the atrpms.net
servers to post a link. Feel free to ping me off list and I'll
file-attach the patches to save the Fedora folk some work. :)


I recommend opening a bugzilla bug against component dovecot. Here's the 
current list for that component:


https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=dovecot

When a new version comes out for some program, I just open an RFE bug and 
paste the release announcement. That provides the downstream packagers a 
place to track the progress of the update, as well as a place to attach any 
special patches (such as the ones you mention).


Since 1.0.0 is now in Rawhide, no request for that is needed, so you'll 
want to open a new bug to request modifications to patches in that package. 
Open the bug against Fedora Core, devel version, etc.


For those wanting to check out the Rawhide package, here's one mirror:

ftp://mirror.stanford.edu/pub/mirrors/fedora/linux/core/development/source/SRPMS/dovecot-1.0.0-11.fc7.src.rpm

You'll find others here:

http://rhold.fedoraproject.org/Download/mirrors.html

Re: [Dovecot] 1.0.rc29 released

[Kenneth Porter]

--On Saturday, March 31, 2007 9:32 AM +0200 John and Catherine Allen 
[EMAIL PROTECTED] wrote:



- mind share in the boardroom is not the only possible goal for a
project


I was thinking of installed base, not commercial users per se.

Re: [Dovecot] 1.0.rc29 released

[Kenneth Porter]

--On Friday, March 30, 2007 4:41 PM -0700 Frank Cusack 
[EMAIL PROTECTED] wrote:



You are going to have to do the exact same testing from 0.99-1.0 as
you would from 0.99-1.0rc29.  Caveat emptor with open source software;
the responsibility is upon YOU to do your own testing.


Actually, no. A few people keep up with the latest rc's. A lot of people 
will install 1.0. I try never to be the first lemming over the cliff. I 
wait to hear the sounds of the others splash, to see where the rocks are. 
With a proper 1.0 release, I can have high confidence in knowing what bugs 
to expect before I install it. I don't have that confidence with an rc 
tried by only a handful and then rapidly replaced with its successor.


Windows Server 2003 Service Pack 2 came out a week ago. I'm leaving it in 
the unapproved queue for a couple weeks, maybe a month, to hear what 
happens to the early adopters. I'm quite sure it will have its share of 
problems, and I can live with that, as long as I have some idea of what 
they are.


Note that I'm a small shop. I don't have the luxury of a parallel testing 
environment like some corporation with hundreds or thousands of employees 
and the IT budget to match. I rely on the experiences of other admins with 
the deep pockets to do that sort of thing.



It sounds to me like the reason you are running 0.99 is not because of
any rc naming and/or lack of stability, it is because Fedora ships
with 0.99.  So you should just wait until Fedora updates it and not
worry about the fact that the rc releases are misnamed.


It's because lots of people are running this version, and it's a known 
entity.



Why do you care anyway?  (Not attacking you.)  If 0.99 works for you,
great!


Because there are features in 1.0 I'd like to start using. But I don't want 
to have to wait for tomorrow's feature's testing before I can use 
yesterday's features.


Lock down 1.0 and ship it. Most people realize that a dot-oh release is 
going to have bugs. Let the wider community start getting experience with 
it. Don't do any more coding on this branch except bug fixes.

Re: [Dovecot] 1.0.rc29 released

[Kenneth Porter]

--On Friday, March 30, 2007 4:52 PM -0700 Frank Cusack 
[EMAIL PROTECTED] wrote:



It's very easy.  In the dovecot world, rc means development version.
Or are you too stupid and ignorant to learn how the versioning works
for dovecot.  (Sorry, that's directed to another dovecot thread; I'm
not calling you stupid and ignorant.)


That's fine for isolated users supporting only themselves. But it won't win 
any mind share in the boardroom. If you want widespread deployment to get 
proper testing (and hence a larger user base) you need a version number 
that gives business people the confidence to install it. Otherwise you'll 
be limited to avant garde hobbyists who have nothing to risk.


Once 1.0 locks down, you should see a huge expansion of users. Bug fixes 
(not features!) in 1.0.1 will see further expansion. Any new features (like 
the recent addition of the wiki to the tarball) should be in the scary and 
experimental 1.1, not 1.0.

Re: [Dovecot] 1.0.rc29 released

[Kenneth Porter]

--On Friday, March 30, 2007 5:22 PM -0700 Frank Cusack 
[EMAIL PROTECTED] wrote:



Please don't mistake my email for any involvement with dovecot
development. AFAIK, Timo is the one and only developer.  That's sure to
win over your board and boards worldwide.


If you mean a single developer might scare away users, I don't think that's 
the case. Plenty of popular software is developed by a single person or a 
very small developer group. And with open source, the loss of the developer 
doesn't mean that the application gets orphaned.



FWIW, in my experience, all 1.0 software is utter shit and should be
avoided like the plague if stability is a requirement.  So 0.99, 1.0, etc
is all meaningless to me.


My concern is not quality but predictability. There's a reason 0.99 and 1.0 
software is poor quality: Few people are willing to risk using it, so it 
doesn't receive widespread testing. More will use 1.0 than 0.99, and more 
yet 1.0.1. The rc on the end of the current dovecot is little better than 
0.99 to those who insist on a 1.0. (It's psychologically better, but only 
just marginally better.)


I also don't seek more users out of some kind of popularity vote. I'm 
looking for the many eyes effect. With more people using it, more issues 
get identified. It's like sending an army of bots over a minefield, so I 
don't have to be the one losing a leg.