Re: [Dovecot] Security Hole in 1.0.13?
ROFL... This was a good way to start the day... Correct your typo in the dovecot.conf file ;) Here's a hint ;) See base_dir... drwxr-xr-x 3 rootroot4096 2008-05-18 13:30 dotvecot dovecot.conf cat /etc/dovecot/dovecot.conf base_dir = /var/run/dotvecot -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Re: [Dovecot] Security Hole in 1.0.13?
Corrected that in the conf file. If I check the dovecot user, I see its been compromised also - a bunch of crap in their login folder. I didn't create the dovecot.conf with a /var/run/dotvecot though, so someone else did that. More updates as I check further. On May 18, 2008, at 2:54 PM, Andraž 'ruskie' Levstik wrote: ROFL... This was a good way to start the day... Correct your typo in the dovecot.conf file ;) Here's a hint ;) See base_dir... drwxr-xr-x 3 rootroot4096 2008-05-18 13:30 dotvecot dovecot.conf cat /etc/dovecot/dovecot.conf base_dir = /var/run/dotvecot -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, May 18, 2008 at 10:03 AM, Lawrence Sheed [EMAIL PROTECTED] wrote: Corrected that in the conf file. If I check the dovecot user, I see its been compromised also - a bunch of crap in their login folder. I didn't create the dovecot.conf with a /var/run/dotvecot though, so someone else did that. More updates as I check further. If you allow your system to be compromised, you cannot attribute that to a particular application, unless you can prove the fact that that application led to the security hole. For now, it's easy to just take that 0wn3d host offline and deal with it - or just format the damn thing as it'll not be easy to track down the hole(s) now existing on your system. I'd do that, but I'd have to record that as a major milestone in my sysadmin life since I've never been so luck to get v1s1t3d by aliens:-) Get the humor flowing I was having a really boring Sunday! -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Oh My God! They killed init! You Bastards! --from a /. post
Re: [Dovecot] Security Hole in 1.0.13?
Typically before I kill a system thats been compromised, I try to find out the reason, so it DOESNT happen again. In this instance I have 2 systems with exactly the same issue Both were running smoothly until about last week, then load spikes were observed. In both systems, the the attacker has changed the dovecot.conf to point at dotvecot I'm guessing around the 13th as thats when the /var/run/dovecot folder was updated. I'll do the rest offlist. Andraz, thank you. Washington, you're an asshole. Cheers, Lawrence. On May 18, 2008, at 3:03 PM, Lawrence Sheed wrote: Corrected that in the conf file. If I check the dovecot user, I see its been compromised also - a bunch of crap in their login folder. I didn't create the dovecot.conf with a /var/run/dotvecot though, so someone else did that. More updates as I check further. On May 18, 2008, at 2:54 PM, Andraž 'ruskie' Levstik wrote: ROFL... This was a good way to start the day... Correct your typo in the dovecot.conf file ;) Here's a hint ;) See base_dir... drwxr-xr-x 3 rootroot4096 2008-05-18 13:30 dotvecot dovecot.conf cat /etc/dovecot/dovecot.conf base_dir = /var/run/dotvecot -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, May 18, 2008 at 10:19 AM, Lawrence Sheed [EMAIL PROTECTED] wrote: Typically before I kill a system thats been compromised, I try to find out the reason, so it DOESNT happen again. In this instance I have 2 systems with exactly the same issue Both were running smoothly until about last week, then load spikes were observed. In both systems, the the attacker has changed the dovecot.conf to point at dotvecot I'm guessing around the 13th as thats when the /var/run/dovecot folder was updated. I'll do the rest offlist. Andraz, thank you. Washington, you're an asshole. I agree, but . It's made you come up with more details to make someone start thinking. Now you are heading towards Timo's cash offer to anyone who can discover and point out a security hole in dovecot, but you are a little far away still. We are all interested in what you find out ultimately, and I stop being an asshole now, so please share with us everything. As I told you, I run same version of dovecot as you on over 20 servers. They are all FreeBSD and configured the same in all aspects except domain names/ip addresses. Your discovery could help me and others as well. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Oh My God! They killed init! You Bastards! --from a /. post
Re: [Dovecot] Security Hole in 1.0.13?
Hello Lawrence, Sunday, May 18, 2008, 9:19:40 AM, you wrote: I'll do the rest offlist. Please don't. Finding out it wasn't your Dovecot installation that was compromised is valuable information here (as is the opposite, of course). -- Best regards, Robert Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] Security Hole in 1.0.13?
Are you perhaps running a debian host with compromised keys(see recent debian+ssl issues)? -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Re: [Dovecot] Security Hole in 1.0.13?
I am running Debian on both servers, but updated both the keys and the ssh server as I saw it on Slashdot. (A few days ago). The intrusion seems to be around the 13th. They changed the dovecot configuration (as noted). If I turned off the iptables firewalling, I see that port 6244 and 6243 had something running on them if I checked from a non-compromised server. An nmap from the compromised server (including those ports in the scan) showed nothing. rkhunter showed nothing untoward. Other relevant details. I'm running /tmp as noexec and nosu. unused ports are firewalled (which is probably what saved me from being horribly compromised). Certain files are root only (I have a daily script which does) chmod 750 /usr/bin/rcp chmod 750 /usr/bin/wget chmod 750 /usr/bin/lynx chmod 750 /usr/bin/links chmod 750 /usr/bin/scp This usually stops script kiddies. Also have fail2ban running for ssh and ftp dictionary attacks. I saw a couple of strange things in the imap logs related to ssh*-dist (can't remember the exact wording, and those logs are gone unfortunately) I run 5 servers with similar setups - although some are running 1.0.9 (which I've upgraded to 1.0.13 on all), although I'm running courier- imap on them for the moment just to be sure. 2 out of 5 had the /var/run/dotvecot folder appear around the 13th. I hadn't made any changes to dovecot other than updates as new releases come out. I'm not sure if the dict line in the dovecot.conf was there before. It's not on most of the setups, but appears in both of the affected ones. I'm going to reinstall one of the affected servers, but can leave the second running for a little while. Any other thoughts (positive ones), or things you'd like me to post? On May 18, 2008, at 4:02 PM, Andraž 'ruskie' Levstik wrote: Are you perhaps running a debian host with compromised keys(see recent debian+ssl issues)? -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Re: [Dovecot] Security Hole in 1.0.13?
On 10:18:50 2008-05-18 Lawrence Sheed [EMAIL PROTECTED] wrote: I am running Debian on both servers, but updated both the keys and the ssh server as I saw it on Slashdot. (A few days ago). The intrusion seems to be around the 13th. They changed the dovecot configuration (as noted). Could have happened then or a few days before that... Thi issue was around for a lot longer than since it was announced :) -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, 18 May 2008, Lawrence Sheed wrote: Anyone want to assist in finding out how they are getting in? How about setting up rawlog? Details in the Wiki. Definitely dovecot related. If I don't run dovecot, seems secure. As soon as I run dovecot, after a few minutes - rooted... Is your dovecot configuration writable by the dovecot user? It shouldn't. What happens if you set the +i flag (immutable) with chattr on Linux (or schg on BSD, JFTR if someone else ), to prevent changes to the dovecot.conf file? Can you obtain working and statically linked ps, top, netstat copies from an uncompromised system or a known-good live CD? -- Matthias Andree
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, 2008-05-18 at 13:52 +0800, Lawrence Sheed wrote:
It would be helpful to have some more information, such as:
If I run dovecot for a while, I see a /var/run/dotvecot folder created
with the following:
drwxr-xr-x 3 rootroot4096 2008-05-18 13:30 dotvecot
..
I've tried removing any dovecot remnants and reinstalling from the
1.0.13 tar.gz from the site.
After starting dovecot again after a few minutes the files appear.
Even if you change base_dir back to /var/run/dovecot? What if you unplug
the network, does it still come back too?
The processes are running something on 6243 and 6244
netstat -ln don't show them? That would mean the attacker gained root
access, which is very unlikely to have happened directly through Dovecot
(but getting non-root via Dovecot - root via some other exploit is
possible of course).
passdb vpopmail {
#args =
}
vpopmail would be one possibility, I have some doubts about its
security.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, 2008-05-18 at 15:03 +0800, Lawrence Sheed wrote: Corrected that in the conf file. If I check the dovecot user, I see its been compromised also - a bunch of crap in their login folder. What crap? By login folder do you mean /var/run/do[t]vecot/login? It's supposed to have some files in it. If they're clearly not created by Dovecot, could you send them to me? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, 18 May 2008, Timo Sirainen wrote:
passdb vpopmail {
#args =
}
vpopmail would be one possibility, I have some doubts about its
security.
Can you detail the spots you deem could take some more observation or
investigation? vpopmail, after all, is highly popular in qmail
environments which boast about their security (which is partially
based on proof by claim like arguments and sometimes 'substantiated'
by ad-hominem attacks of certain groups of people who can't bear
criticism).
--
Matthias Andree
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, 2008-05-18 at 12:45 +0200, Matthias Andree wrote:
On Sun, 18 May 2008, Timo Sirainen wrote:
passdb vpopmail {
#args =
}
vpopmail would be one possibility, I have some doubts about its
security.
Can you detail the spots you deem could take some more observation or
investigation?
I haven't looked at its code for several years now, but when I was
implementing support for it the code didn't look all that secure. For
example I had to add a workaround to Dovecot to make it work at all,
because parse_email() didn't correctly NUL-terminate the output string:
/* vpop_user must be zero-filled or parse_email() leaves an
extra character after the user name. we'll fill vpop_domain
as well just to be sure... */
memset(vpop_user, '\0', VPOPMAIL_LIMIT);
memset(vpop_domain, '\0', VPOPMAIL_LIMIT);
if (parse_email(request-user, vpop_user, vpop_domain,
VPOPMAIL_LIMIT-1) 0) {
Also a quick look at its sources again shows that it uses strncpy() and
strncat() wrong pretty much everywhere. Especially the strncat() calls
are no better at protecting against buffer overflows than strcat().. But
I don't know if any of these are actually exploitable. Probably not.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] problem about mbox with quota
On May 18, 2008, at 5:13 AM, Zhang Huangbin wrote:
Hi, all.
Does mbox format support quota?
dirsize backend should work pretty well.
dovecot: May 18 02:10:36 Error: POP3([EMAIL PROTECTED]): Unknown quota
backend: storage=10240
You need to select the backend.
user_query = SELECT 2000 AS uid, 2000 AS gid, /home/vmail AS home,
maildir, CONCAT('storage=',quota) AS quota FROM mailbox WHERE
username='%u' AND active='1'
CONCAT('dirsize:storage=',quota)
PGP.sig
Description: This is a digitally signed message part
Re: [Dovecot] problem about mbox with quota
Hi, Timo.
Timo Sirainen wrote:
On May 18, 2008, at 5:13 AM, Zhang Huangbin wrote:
Hi, all.
Does mbox format support quota?
dirsize backend should work pretty well.
dovecot: May 18 02:10:36 Error: POP3([EMAIL PROTECTED]): Unknown quota
backend: storage=10240
You need to select the backend.
user_query = SELECT 2000 AS uid, 2000 AS gid, /home/vmail AS home,
maildir, CONCAT('storage=',quota) AS quota FROM mailbox WHERE
username='%u' AND active='1'
CONCAT('dirsize:storage=',quota)
Thanks very much. :)
I think we should add this tip in wiki page:
http://wiki.dovecot.org/Quota
OR
http://wiki.dovecot.org/MailLocation/Mbox
--
Best Regards.
Zhang Huangbin
- OpenBSD 4.2 -release, i386.
- RHEL 5.1 Client
Re: [Dovecot] Postfix Dovecot LDA
Hi.
I know, this is a pretty old thread, but since I just ran into similar
problems while setting up my one-user-per-virtual-domain postfix +
multi-instance-dovecot/-lda, I thought I might share my fix in this
related (and most useful) thread.
My setup might not be used often - I am running two dovecot instances
(on different IP addresses on the same server, in case you're
wondering), with the first instance exporting the auth-master socket. I
am using different UID/GIDs for my virtual domains/mailboxes. I
couldn't get postfix setgid accordingly when callig deliver, and I
didn't want to use SUID on deliver.
The versions I am using are:
dovecot 1.0.13
postfix 2.3.8
My first dovecot instance is using:
auth default {
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0600
user = vmail
}
}
}
The other is using:
protocol lda {
auth_socket_path = /var/run/dovecot/auth-master
}
And my postfix's master.cf is:
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f
${sender} -d ${recipient}
dovecot-other unix -n n - - pipe
flags=DRhu user=vmail-other:vmail-other argv=/usr/lib/dovecot/deliver
-c /etc/dovecot/other/dovecot.conf -f ${sender} -d ${recipient}
My fix is: I use filesystem ACLs and just set the ACLs of the
auth-master socket after starting the first dovecot instance (which
creates the socket).
I.e. I run after starting dovecot (and waiting for a second...):
setfacl -m u:vmail-other:rw /var/run/dovecot/auth-master
This works only for filesystems with ACL support, of course. I use
setfacl with ext2/3; other filesystem ACL tools might differ.
Oh, and thanks for dovecot and this supportive mailinglist btw. (even
though this is my first post: hi everyone :) )
Greetings,
Jens
[Dovecot] compile troubles - stat.mtim - 1.1hg
having trouble compiling dovecot-1.1hg latest pull
I'm amost thinking _GNU_SOURCE needs to be defined as its built to work
Any suggestions welcome.
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory
`/home/dan/software_projects/dovecot-1.1/src/lib-storage/list'
Making all in index
make[4]: Entering directory
`/home/dan/software_projects/dovecot-1.1/src/lib-storage/index'
Making all in maildir
make[5]: Entering directory
`/home/dan/software_projects/dovecot-1.1/src/lib-storage/index/maildir'
gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/lib
-I../../../../src/lib-mail -I../../../../src/lib-imap
-I../../../../src/lib-index -I../../../../src/lib-storage
-I../../../../src/lib-storage/index -std=gnu99 -g -O2 -Wall -W
-Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts
-Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -I/usr/kerberos/include
-MT
maildir-uidlist.o -MD -MP -MF .deps/maildir-uidlist.Tpo -c -o
maildir-uidlist.o maildir-uidlist.c
maildir-uidlist.c: In function 'maildir_uidlist_update_hdr':
maildir-uidlist.c:322: error: request for member 'st_mtim' in something not a
structure or union
make[5]: *** [maildir-uidlist.o] Error 1
make[5]: Leaving directory
`/home/dan/software_projects/dovecot-1.1/src/lib-storage/index/maildir'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/home/dan/software_projects/dovecot-1.1/src/lib-storage/index'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/dan/software_projects/dovecot-1.1/src/lib-storage'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/dan/software_projects/dovecot-1.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dan/software_projects/dovecot-1.1'
fgrep HAVE_STAT config.h
/* #undef HAVE_STATFS_MNTFROMNAME */
/* #undef HAVE_STATVFS_MNTFROMNAME */
#define HAVE_STAT_XTIM
/* #undef HAVE_STAT_XTIMESPEC */
from config.log
configure:28085: checking if struct stat has st_?tim timespec fields
configure:28117:
gcc -c -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations
-Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast
-Wstrict-aliasing=2
conftest.c 5
conftest.c: In function 'main':
conftest.c:104: warning: unused variable 'x'
configure:28123: $? = 0
configure:28134: result: yes
configure:28149: checking if struct stat has st_?timespec fields
configure:28181:
gcc -c -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations
-Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast
-Wstrict-aliasing=2
conftest.c 5
conftest.c: In function 'main':
conftest.c:105: error: 'struct stat' has no member named 'st_mtimespec'
conftest.c:105: warning: unused variable 'x'
configure:28187: $? = 1
configure: failed program was:
Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.2.3, glibc-2.6.1-r0,
2.6.22-vs2.2.0.7-gentoo x86_64)
=
System uname: 2.6.22-vs2.2.0.7-gentoo x86_64 AMD Athlon(tm) 64 X2 Dual Core
Processor 4200+
Timestamp of tree: Sat, 17 May 2008 22:15:01 +
distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[enabled]
app-shells/bash: 3.2_p33
dev-java/java-config: 1.3.7, 2.1.6
dev-lang/python: 2.4.4-r9
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:1.2.18.1-r2
sys-devel/autoconf: 2.13, 2.61-r1
sys-devel/automake: 1.4_p6, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1
sys-devel/binutils: 2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool: 1.5.26
virtual/os-headers: 2.6.23-r3
features.h
#ifdef _GNU_SOURCE
# define _BSD_SOURCE1
#endif
#if defined _BSD_SOURCE || defined _SVID_SOURCE
# define __USE_MISC 1
#endif
sys/stat.h includes bits/stat.h
#include features.h
struct stat {
#ifdef __USE_MISC
/* Nanosecond resolution timestamps are stored in a format
equivalent to 'struct timespec'. This is the type used
whenever possible but the Unix namespace rules do not allow the
identifier 'timespec' to appear in the sys/stat.h header.
Therefore we have to handle the use of this header in strictly
standard-compliant sources special. */
struct timespec st_atim;/* Time of last access. */
struct timespec st_mtim;/* Time of last modification. */
struct timespec st_ctim;/* Time of last status change. */
--
Daniel Black
--
Proudly a Gentoo Linux User.
Gnu-PG/PGP signed and encrypted email preferred
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x76677097
GPG Signature D934 5397 A84A 6366 9687 9EB2 861A 4ABA 7667 7097
signature.asc
Description: This is a digitally signed message part.
Re: [Dovecot] compile troubles - stat.mtim - 1.1hg
Daniel Black wrote: having trouble compiling dovecot-1.1hg latest pull dito. ST_MTIME_NSEC is ((unsigned long)(st).st_mtim.tv_nsec) (at least on my system), but st in maildir-uidlist.c:322 is a pointer, so - has to be used. Here's a (quick'n'dirty, probably incomplete) patch: diff -r 6ab2ccae0868 src/lib-storage/index/maildir/maildir-uidlist.c --- a/src/lib-storage/index/maildir/maildir-uidlist.c Sat May 17 02:25:40 2008 +0300 +++ b/src/lib-storage/index/maildir/maildir-uidlist.c Sun May 18 16:44:30 2008 +0200 @@ -318,7 +318,7 @@ static void maildir_uidlist_update_hdr(s struct maildir_index_header *mhdr = uidlist-mbox-maildir_hdr; mhdr-uidlist_mtime = st-st_mtime; - mhdr-uidlist_mtime_nsecs = ST_MTIME_NSEC(st); + mhdr-uidlist_mtime_nsecs = ST_MTIME_NSEC_REF(st); mhdr-uidlist_size = st-st_size; } diff -r 6ab2ccae0868 src/lib/compat.h --- a/src/lib/compat.h Sat May 17 02:25:40 2008 +0300 +++ b/src/lib/compat.h Sun May 18 16:44:30 2008 +0200 @@ -67,6 +67,7 @@ typedef int socklen_t; # define HAVE_ST_NSECS # define ST_ATIME_NSEC(st) ((unsigned long)(st).st_atim.tv_nsec) # define ST_MTIME_NSEC(st) ((unsigned long)(st).st_mtim.tv_nsec) +# define ST_MTIME_NSEC_REF(st) ((unsigned long)(st)-st_mtim.tv_nsec) # define ST_CTIME_NSEC(st) ((unsigned long)(st).st_ctim.tv_nsec) #elif defined (HAVE_STAT_XTIMESPEC) # define HAVE_ST_NSECS
Re: [Dovecot] compile troubles - stat.mtim - 1.1hg
On Sun, 2008-05-18 at 16:46 +0200, Jakob Hirsch wrote: Daniel Black wrote: having trouble compiling dovecot-1.1hg latest pull dito. ST_MTIME_NSEC is ((unsigned long)(st).st_mtim.tv_nsec) (at least on my system), but st in maildir-uidlist.c:322 is a pointer, so - has to be used. Whops. I thought I had tested it, but looks like I was missing HAVE_STAT_XTIM from my config.h. Here's a (quick'n'dirty, probably incomplete) patch: There's a bit easier way: http://hg.dovecot.org/dovecot-1.1/rev/e29dafc501cc signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Looking for suggestions: How to strip attachments from mails
Patrick Nagel wrote: Hi, I know this is not 100% on-topic, but I'll try anyway... I'm looking for a way to strip attachments from incoming mails on the server. The attachments should be stored on a file server (where users have access via SAMBA) and only a link to the file (UNC path) should remain in the mail body. This is to prevent the mail storage from filling up with a large amount of big mails where at the same time the 'payload' (attached file) is not conveniently accessible by the users. The current setup is postfix / dovecot deliver / dovecot (with sieve plugin). I'm considering piping the mails through something like mimeStrip.pl (http://freshmeat.net/projects/mimestrip.pl/), but therefore I'd probably need to bring procmail/maildrop into the game, right? Or are there other (better) ways to accomplish this? if you're ready to script a little, you can use http://www.pldaniels.com/ripmime/ to extract the attachments...
[Dovecot] Domain variable in checkpassword
Hello everyone
I'm using the checkpassword method but I don't get the domain a user inputs.
I can't cross check per virtual domains if I'm not getting one, which means
it renders all my efforts useless.
I've tried sending %d as a variable to my checkpassword script, but I'm just
getting %d instead.
This is a dump of my information:
%ENV = {
'USERNAME_TRANSLATION' = '',
'SYSLOG_FACILITY' = '16',
'CACHE_SIZE' = '0',
'RESTRICT_GID_LAST' = '',
'TCPREMOTEIP' = '213.31.43.3',
'RESTRICT_GID_FIRST' = '',
'AUTH_NAME' = 'default',
'CACHE_TTL' = '3600',
'SERVICE' = 'IMAP',
'USERDB_1_DRIVER' = 'prefetch',
'USERNAME_CHARS' =
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@',
'DOVECOT_MASTER' = '1',
'RESTRICT_SETGID' = '',
'AUTH_WORKER_MAX_COUNT' = '30',
'AUTH_WORKER_PATH' = '/var/run/dovecot/auth-worker.25291',
'PASSDB_2_ARGS' = '/etc/exim/checkp %d',
'USERNAME_FORMAT' = '',
'LOCAL_IP' = '128.177.27.100',
'PASSDB_2_DRIVER' = 'checkpassword',
'PASSDB_1_DRIVER' = 'pam',
'REALMS' = '',
'PROTO' = 'TCP',
'ANONYMOUS_USERNAME' = 'anonymous',
'RESTRICT_SETEXTRAGROUPS' = '',
'TCPLOCALIP' = '128.177.27.100',
'LOG_TO_MASTER' = '1',
'MASTER_USER_SEPARATOR' = '',
'RESTRICT_SETUID' = '',
'REMOTE_IP' = '213.31.43.3',
'RESTRICT_USER' = '',
'DOVECOT_VERSION' = '1.0.rc15',
'MECHANISMS' = 'plain',
'RESTRICT_CHROOT' = '',
'DEFAULT_REALM' = ''
};
ARGS:
@ARGV = [
'%d',
'/usr/libexec/dovecot/checkpassword-reply'
];
Thanks,
Sawyer.
[Dovecot] Auto-subscribe to folders
Hi I will use autocreate plugin in a new installation, and client has asked me if the users can be auto-subscribed to certain folders. Example: the users will have an autocreated Junk folder (for SPAM) and we want the users not to be un-subscribed for this folder; so if the user wants to be unsubscribed (from outlook, webmail, etc), there are two options: a) the action is rejected or denied; b) the next time he/she logins, then the folder is autosubscribed again. Could this be done? How? Thanks in advance.
[Dovecot] RFC 3516 - IMAP4 Binary Content Extension
Is Binary Content Extension (rfc3516) support planned? -- WBR, Anton Yuzhaninov
[Dovecot] Fixed a Duplicate?
Greetings We have recently switched from mbox to Maildir so that we can implement symlinks for a large email account that is shared (partially) between some 20 or so users. The setup is dovecot-1.0.3-6.fc6, procmail-3.22-17.1, sendmail-8.13.8-2. Procmail has a single recipe in /etc/procmailrc that simply says DEFAULT=$HOME/Maildir/. The problem is that I am seeing a lot of blank emails being created. For exaample, every time I open a folder from this shared account, I get either one or two emails being created on the spot. The are /always/ created with the current date and time stamp (i.e. now) and at the same time a tail -f of maillog shows something like this: May 19 09:10:05 sydsrv56 dovecot: IMAP(plans): Fixed a duplicate: dovecot-shared:2, - 1211152205.P10039Q1.sydsrv56 The only thing that appears to change is the last modified date and time of the two files, dovecot.index.log and dovecot.index.cache. Should I be maintaining separate index files or lock files for each user in this shared account? Currently the Maildir is shared and has the g+s bit set. Any ideas where I can start looking would be appreciated. Rgds Nigel. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Dovecot] Fixed a Duplicate?
On Mon, 2008-05-19 at 09:20 +1000, Nigel Allen wrote: For exaample, every time I open a folder from this shared account, I get either one or two emails being created on the spot. The are /always/ created with the current date and time stamp (i.e. now) and at the same time a tail -f of maillog shows something like this: May 19 09:10:05 sydsrv56 dovecot: IMAP(plans): Fixed a duplicate: dovecot-shared:2, - 1211152205.P10039Q1.sydsrv56 dovecot-shared file should exist in Maildir/ directory, while mails should exist in Maildir/new/ and Maildir/cur/ directory. I don't see how dovecot-shared could be moved to cur/ or new/ directory.. Or are your new/ or cur/ directories some weird symlinks? The setup is dovecot-1.0.3-6.fc6, procmail-3.22-17.1, sendmail-8.13.8-2. I don't remember Dovecot having this exact bug, but I remember fixing something related to dovecot-shared file. So it's possible it's been fixed in newer versions. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Fixed a Duplicate?
Timo Sirainen wrote: On Mon, 2008-05-19 at 09:20 +1000, Nigel Allen wrote: For exaample, every time I open a folder from this shared account, I get either one or two emails being created on the spot. The are /always/ created with the current date and time stamp (i.e. now) and at the same time a tail -f of maillog shows something like this: May 19 09:10:05 sydsrv56 dovecot: IMAP(plans): Fixed a duplicate: dovecot-shared:2, - 1211152205.P10039Q1.sydsrv56 dovecot-shared file should exist in Maildir/ directory, while mails should exist in Maildir/new/ and Maildir/cur/ directory. I don't see how dovecot-shared could be moved to cur/ or new/ directory.. Or are your new/ or cur/ directories some weird symlinks? Hi Timo The file dovecot-shared does exist in the Maildir directory ~/Maildir/. I read that this file also has to exist in each folder under Maildir so I created them (as the folders where created outside of dovecot. I suspect that I have gone a little too far though. Here is the results of a find command plans/Maildir/. 60503/dovecot-shared plans/Maildir/. 60503/tmp/dovecot-shared plans/Maildir/. 60503/new/dovecot-shared plans/Maildir/.Lost Plans. 4938/cur/dovecot-shared plans/Maildir/.Lost Plans. 4938/dovecot-shared plans/Maildir/.Lost Plans. 4938/tmp/dovecot-shared plans/Maildir/.Lost Plans. 4938/new/dovecot-shared plans/Maildir/. 7849/dovecot-shared plans/Maildir/. 7849/tmp/dovecot-shared plans/Maildir/.Junk/cur/dovecot-shared plans/Maildir/.Junk/dovecot-shared plans/Maildir/.Junk/tmp/dovecot-shared plans/Maildir/.Junk/new/dovecot-shared plans/Maildir/. 58532.2008/cur/dovecot-shared plans/Maildir/. 58532.2008/dovecot-shared plans/Maildir/. 10075/dovecot-shared plans/Maildir/. 10075/tmp/dovecot-shared plans/Maildir/. 4743/dovecot-shared plans/Maildir/. 4743/tmp/dovecot-shared plans/Maildir/. 19128/cur/dovecot-shared plans/Maildir/. 19128/dovecot-shared plans/Maildir/. 19128/tmp/dovecot-shared plans/Maildir/. 19128/new/dovecot-shared plans/Maildir/. 52474/cur/dovecot-shared plans/Maildir/. 52474/dovecot-shared plans/Maildir/. 52474/tmp/dovecot-shared plans/Maildir/. 52474/new/dovecot-shared plans/Maildir/. 4260/dovecot-shared plans/Maildir/. 4260/tmp/dovecot-shared Should I remove the dovecot-shared files from all the cur and tmp and new? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Dovecot] Fixed a Duplicate?
On May 19, 2008, at 3:12 AM, Nigel Allen wrote: The file dovecot-shared does exist in the Maildir directory ~/ Maildir/. I read that this file also has to exist in each folder under Maildir so I created them (as the folders where created outside of dovecot. Yes, for all folders you want shared. I suspect that I have gone a little too far though. Here is the results of a find command .. Should I remove the dovecot-shared files from all the cur and tmp and new? Right, that's a bit too much. :) Anything in cur/ and new/ directories are treated as messages. In tmp/ it doesn't do anything. PGP.sig Description: This is a digitally signed message part
