- dovecot - dovecot.org

[Dovecot] Sieve problem with managesieve
by Simone Caruso 11 Nov '10

11 Nov '10

I have a problem with a sieve script.. my config is dovecot 1.2.15 with managesieve, and roundcube. Now i have this script WORKING: -- require ["fileinto"]; # rule:[TracSvil] if anyof (header :contains "From" "xxx(a)example.com") { fileinto "INBOX.Trac Svil"; stop; } -- And this script NOT working: require ["fileinto"]; # rule:[TracSvil] if anyof (header :is "From" "trac(a)ardeek.com") { fileinto "INBOX.Trac Svil"; stop; } Can someone explain me the difference between these script? there is any error in the second script? Greetings! -- Simone Caruso IT Consultant p.iva: 03045250838

3 3

[Dovecot] dovecot dictionary attacks
by Paul Amaral 11 Nov '10

11 Nov '10

Hi, I been using dovecot for awhile and its been solid, however I been having some issues with dictionary attacks. I installed fail2ban and for the most part is working fine. However today I got another spammer relaying through my server. Looking at the logs I see the following dictonary attack from 94.242.206.37 Nov 10 03:04:38 pop dovecot: pop3-login: Disconnected: rip=94.242.206.37, lip=209.213.66.10 Nov 10 03:04:38 pop dovecot: auth(default): client in: AUTH 1 PLAIN service=POP3 lip=209.213.66.10 rip=94.242.206.37 resp=<hidden> Nov 10 03:04:38 pop dovecot: auth(default): shadow(aarhus,94.242.206.37): lookup Nov 10 03:04:38 pop dovecot: auth(default): client in: AUTH 1 PLAIN service=POP3 lip=209.213.66.10 rip=94.242.206.37 resp=<hidden> Nov 10 03:04:38 pop dovecot: auth(default): shadow(abaft,94.242.206.37): lookup Nov 10 03:04:38 pop dovecot: auth(default): shadow(abaft,94.242.206.37): unknown user Nov 10 03:04:38 pop dovecot: auth(default): client in: AUTH 1 PLAIN service=POP3 lip=209.213.66.10 rip=94.242.206.37 resp=<hidden> Nov 10 03:04:38 pop dovecot: auth(default): shadow(aarhus,94.242.206.37): unknown user Nov 10 03:04:38 pop dovecot: auth(default): client in: AUTH 1 PLAIN service=POP3 lip=209.213.66.10 rip=94.242.206.37 resp=<hidden> Nov 10 03:04:38 pop dovecot: auth(default): shadow(aaron,94.242.206.37): lookup Nov 10 03:04:38 pop dovecot: auth(default): shadow(aaron,94.242.206.37): unknown user Nov 10 03:04:38 pop dovecot: auth(default): client in: AUTH 1 PLAIN service=POP3 lip=209.213.66.10 rip=94.242.206.37 resp=<hidden> Nov 10 03:04:38 pop dovecot: auth(default): shadow(ababa,94.242.206.37): lookup ..... And so on.. Then that ip gets banned by fail2ban [root@pop ~]# grep 94.242.206.37 /var/log/fail2ban.log 2010-11-10 03:04:42,416 fail2ban.actions: WARNING [dovecot] Ban 94.242.206.37 However on my smtp mail server that ip is already sending out all sorts of spam with the sasl username of Paramus. This username Paramus never shows up on the dovevot dictionary attack, as a matter of fact the user Paramus is nowhere to be found on the dovecot log at all and I have logs going back months. Does anyone have any idea what could of happened here. I mean if the user/passwd was already harvested by 94.242.206.37 why would they bother to start another dict. attack. I'm just not sure how they guess the username/password as its not on any logs that goes back months and I don't have a dovecot record for that user. /var/log/maillog:Nov 10 02:46:16 mrelay3 postfix/smtpd[27776]: 3B64928015: client=unknown[94.242.206.37], sasl_method=LOGIN, sasl_username=paramus /var/log/maillog:Nov 10 02:47:54 mrelay3 postfix/smtpd[27776]: 247AB28016: client=unknown[94.242.206.37], sasl_method=LOGIN, sasl_username=paramus /var/log/maillog:Nov 10 02:48:00 mrelay3 postfix/smtpd[27785]: 87DE128016: client=unknown[94.242.206.37], sasl_method=LOGIN, sasl_username=paramus /var/log/maillog:Nov 10 02:56:00 mrelay3 postfix/smtpd[27792]: 9728628015: client=unknown[94.242.206.37], sasl_method=LOGIN, sasl_username=paramus /var/log/maillog:Nov 10 03:05:38 mrelay3 postfix/smtpd[27808]: D529F28015: client=unknown[94.242.206.37], sasl_method=LOGIN, sasl_username=paramus /var/log/maillog:Nov 10 03:06:00 mrelay3 postfix/smtpd[27808]: DDF7C2801B: client=unknown[94.242.206.37], sasl_method=LOGIN, sasl_username=Paramus Any help would be appreciated. paul

1 0

[Dovecot] Getting the Sender from a Email
by Alex Baule 10 Nov '10

10 Nov '10

Hi Timo.... I need to get the Sender from a Email. Using this mail_get_first_header(mail, "From", &header) , i get the email in this format "Name <user@dom>" , in dovecot there is a way to get only the user@dom ? Tks !

2 1

[Dovecot] dovecot2.0+ldap auth problems
by Antonio Perez-Aranda 10 Nov '10

10 Nov '10

I'm using a config from dovecot 1.2 adapted to 2.0 After update config, and restart dovecot service: If I do a doveadm user user1 then it is found correctly. If I do a doveadm auth user1 then it is ask for the password user, and it's running correctly. But if I tray to login by telnet using IMAP then I get: . login user1 pass1 Connection closed by foreign host. I can see at logs a Info line with: Internal login failre with auth failed It's very odd that with doveadm runs ok and but not with IMAP.

1 1

[Dovecot] Help! LDAP/AD Problem with dovecot
by Christian Fischer 10 Nov '10

10 Nov '10

Hey Folks, i am trying to get Dovecot LDA to work with Active Directory dovecot --version 1.2.9 While using Postfix to deliver mail, dovecot does only imap-Services, passdb is auth bind and userdb is static. NOW i want to use Sieve Scripts. So LDA of dovecot is required. So userdb lookup is required. With use of virtual Mailboxes i have a working postfix setup, which needs to be transferred to dovecot. dovecot-ldap-userdb.conf uris = ldap://192.168.0.42 auth_bind = yes dn = myldapuser@mydomain dnpass = mypass #ldap_version = 3 base = DC=base,DC=com deref = never scope = subtree user_attrs = sAMAccountName=mail=maildir:/home/vmail/%$/.EMAIL, =uidNumer=5000, =gidNumber=5000 user_filter = (&(objectClass=user)(|(sAMAccountName=%u)(mail=%u)(othermailbox=%u))) pass_attrs = sAMAaccountName=user,userPassword=password pass_filter = (&(objectClass=person)(sAMAaccountName=%u)) My errors are: - While logging in with IMAP 2010-11-10 00:32:30 imap-login: Error: Timeout waiting for handshake from auth server. my pid=16293, input bytes=0 - manual execution of deliver -d myuser(a)domain.tld: 010-11-10 00:34:16 deliver(myuser(a)domain.tld): Error: userdb lookup(...): Connecting timed out As i said - postfix works! Thankx for any help!

2 1

[Dovecot] Problem with dovecot delivery (version 2.0.7)
by Maxime Longuepee 10 Nov '10

10 Nov '10

Hi! I've been having an issue with dovecot since yesterday and can't figure it out. All my users can send mail without any problem but all incomming mail are deffered. Here is the log from postfix complaining the mail has been deferred: Nov 9 23:35:51 www postfix/pipe[50019]: A20EB145FC2C: to=, relay=dovecot, delay=819, delays=819/0.01/0/0.01, dsn=4.3.0, status=deferred (temporary failure) And here is the log from dovecot complaining it can't complete the operation /var/log/dovecot-deliver.log: Nov 09 23:35:51 lda(EMAIL REMOVED FOR PRIVACY): Fatal: setresgid(6(mail),6(mail),6(mail)) failed with euid=143(dovecot): Operation not permitted If anyone could help me, it would be much appreciated! Thanks!

4 10

[Dovecot] need to block user by IP address (tried denyhosts, xinetd, iptables etc)
by Tom 10 Nov '10

10 Nov '10

Hi, I am kind of restricted to using packaged versions of software due to company policy, and we have f12 on our mail server with dovecot-1.2.15-2.fc12.i686 package. we have recently had some brute force attacks on the pop3 and imapd and this results in many processes being used for login attempts. Our dovecot is hosted on a Virtual Private Server which restricts access to IPTABLEs and also make a limit on the number of processes that can be running So I can't restrict the attackers IP addresses via IPTABLES, as we don't have access to that. I can't really patch dovecot as we are reliant on the distro packages. I spent some time trying to get dovecot to run under xinetd but had no luck, and I read some reports that it was not possible using recent versions. I was hoping some advice on what avenue I should proceed with to automatically block brute force attacks on the dovecot server, (that dont use iptables) Thanks, Tom

5 5

[Dovecot] emails getting mangled when dragging from Exchange account to IMAP shared folders
by Scott Goodwin 10 Nov '10

10 Nov '10

I'm having the most frustrating issue, and I'm at a loss for what is happening. I'm not even sure it is with Dovecot, but that's why I'm posting this here... if it isn't a dovecot issue, maybe someone can get me headed in the right direction? I've posted relevant dovecot and config info at the bottom of this post. Here's the scenario: We recently migrated our email from Postfix+Dovecot+Amavis+SA to Exchange (not my choice, unfortunately). Now, users have to use Outlook (as opposed to before, when they could choose between Outlook and Thunderbird), and have the new Exchange account set up, as well as their old IMAP account, which they still use for shared project folders. So, emails come in to Exchange, then they drag the emails from the Exchange mailbox to the shared branch under their IMAP account, and into the appropriate job folder. Emails to one specific user in my organization (let's call him Roy(a)Ocean.org) is having his emails mangled when dragging certain items from his Exchange mailbox to the IMAP account. I can't reproduce the issue with any other user. Also, this only seems to happens with emails from one other specific domain (let's call them tornado.org) So, in summary, user1(a)Tornado.orgsend an email to Roy(a)Ocean.organd Sue(a)Ocean.org. Both drag the email from their Exchange box into any folder (shared or otherwise) in the IMAP tree. Sue's copy makes it in just fine, while Roy's copy gets mangled. Here's the headers of the resultant email after Roy has dragged it into the shared folder: ======================================== From: "User1" <User1(a)tornado.org> To: "Roy", "Sue" References: <B3457C1920D7A2438CCC19EF2A527293372B11(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A527293372D9A(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933A2C3D(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933A310E(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933A3683(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933A3B97(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933D103B(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933D192F(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933D1B12(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933FD341(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933FD8F8(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933FD9A0(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272933FDFDD(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272934C8927(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272934C8B46(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272934C8D76(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272934C8D7A(a)abc027.abc.local> <B3457C1920 ======================================== And here's the email body: ======================================== D7A2438CCC19EF2A5272934C8D95(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272934C8DB6(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272934C8F0D(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935008B5(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A527293500C27(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935011BC(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A527293525B1D(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A527293525D81(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A527293526139(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A527293526416(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935524A6(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935524C9(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A527293589E1C(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935BF6A9(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935E7414(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935E75E2(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935E75E8(a)abc027.abc.local> <B3457C1920 D7A2438CCC19EF2A5272935E75F4(a)abc027.abc.local> <B3457C1920D7A2438CCC19EF2A5272935E800E(a)abc027.abc.local> Subject: RE: Some Subject Date: Tue, 26 Oct 2010 15:11:01 -0700 Message-ID: <B3457C1920D7A2438CCC19EF2A52729364D0A0(a)abc027.abc.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01CB7755.52354760" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrhmOPG84jptRwERxazrnj4Ne2YAQAACMtAAAAjcPAAAAu+gAAAE1hAAAAZWCAAABMaEAAADGzwACO3fdAACN0HsAEpVUrgAPt2jvAAAcrbcABrFxCQAAAXwjAAABGv8AAAI35QAYbDMHAAAPjDYAADNREgAA5XR4AAHoOFcAFtPWTAAIubCCAALwf/MAADBptQACzN6nAAAC61kAAAEN+AAACfkjAAO7MG4AAHLrMQALmKX6AAAUlCcAAAq9SgAAuoo+AAABqqMABXq+FwAD5jAAABYqZYoAOISoLgAAAd//AAAKVPYAApG8DwAAt6dsAAKxpd8AEy9g6gAADrZVAAAE4WgAAlXdkQAPY4tNAAAWY+kAFsS/RgAFtG7qAAAGJT8AAAPLUwAAA2xsAAACamEAAC4ufAADaZyfAAKizZ0AAAZ9EAAAWRHAAAAOgkgAAAUUOgAAQWBBAAij+IkAAE2k1wAAPgAgAANGrwsAACt+wgAC0EW9AAAEDpoAA12EJgAAAyAtAAAyATYAAgyfBQAKS/7/AAAEPWEAABNsTAAAAZujAALLkhkAAwwG5AAAMVt8AAAE3iwAEhzNqgAA8qbEAAIqDaMAA0UTmgAEE0hxAAlsz9IAABAdrAAFIwRcAAZxd5oAAOziPQAJEu45AAOaFlIAAeeCygADwtnbAD9zXHwAApeNOAACk/pfAAABxl0AAAWgGAAAB7d4AACGbyQACNOVmwABF68KAAKuKysAAsiR5gADDcY1AAOMAK8ACO561QABCk+7AAI5IqsAAJGVEgAFjaIkAANWSCQAACuaAwAAAKUQAABugScAAAbmTQAADspwAAzNO+MAAiFH8wAAEA4mAAMv6E0AEtz2wQADWsQHAAO4pvkACIRgpAAAApFcAAABO4UABmP4/QAAEJ/lABNOByMAAF28awAACwfDA= Content-Language: en-us X-OlkEid: C664F3259FA9393D4124CD409B5CAE330696EE82 content-class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_0118_01CB7755.52354760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit <SNIP> =========================================================================== Obviously, it's breaking the message in the References header, and I've tracked down the following byte sequence at the breaking point: 0D:09:0A:09 ...which is CR,TAB,CR,LF. What puzzles me is why Roy's gets broken here, when the others' do not; they're the exact same email, so you'd think they would all get broken. I can't figure out A) where that byte sequence is coming from (our Exchange server, Tornado.net's exchange server, or one of the two of our external spam filtering service... they use BigFish.com, and we use MxLogic), or B) if that's even the issue. I've rebuilt Roy's entire machine, reconfigured Outlook from scratch, still happening. When he logs onto another machine and sets up his Exchange account on another outlook, it still happens. Our Exchange administrator (I don't have access to Exchange) says there is nothing wrong with his Exchange account, for what it's worth. I don't expect anyone to have the solution here, since there are many variables, and there is other info that would probably be needed. What I DO want is to be pointed in the right direction on how I might track this down. For example, what is the path that this mangled email would take in this case? Even with full logging in Dovecot and postfix, I can't see any info on the path that this email follows in our system, and where it might be getting mangled. Does it actually go through the same path as an email that was actually sent to the IMAP account, or is it different when it is dragged in from another account in the same mail client? Is this more likely a problem with Postfix, or Sieve, or....? (I've disabled Amavis and SA to get them out of the picture, and same problem). Here's the dovecot config info; please let me know if you want any other config info, and thanks ahead of time! # dovecot --version 1.1.19 # dovecot -n # 1.1.19: /etc/dovecot/dovecot.conf # OS: Linux 2.6.28-hardened-r9 x86_64 Gentoo Base System release 1.12.13 protocols: imaps imap managesieve listen(default): 127.0.0.1:143 listen(imap): 127.0.0.1:143 listen(managesieve): 127.0.0.1:2000 ssl_listen(default): *:993 ssl_listen(imap): *:993 ssl_listen(managesieve): ssl_cert_file: /etc/ssl/dovecot/imapd.crt ssl_key_file: /etc/ssl/dovecot/imapd.key login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(managesieve): /usr/libexec/dovecot/managesieve-login login_greeting_capability(default): yes login_greeting_capability(imap): yes login_greeting_capability(managesieve): no valid_chroot_dirs: /var/mail first_valid_uid: 206 last_valid_uid: 206 first_valid_gid: 206 last_valid_gid: 206 maildir_copy_preserve_filename: yes mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(managesieve): /usr/libexec/dovecot/managesieve mail_plugins(default): acl mail_plugins(imap): acl mail_plugins(managesieve): mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(managesieve): /usr/lib64/dovecot/managesieve imap_client_workarounds(default): outlook-idle delay-newmail imap_client_workarounds(imap): outlook-idle delay-newmail imap_client_workarounds(managesieve): sieve_storage(default): sieve_storage(imap): sieve_storage(managesieve): ~ sieve(default): sieve(imap): sieve(managesieve): ~/.dovecot.sieve namespace: type: private separator: . location: maildir:~/Maildir inbox: yes list: yes subscriptions: yes namespace: type: public separator: . prefix: shared. location: maildir:/var/mail/shared list: yes lda: postmaster_address: postmaster(a)jensenmaritime.com hostname: mail.jensenmaritime.com mail_plugins: cmusieve mail_plugin_dir: /usr/lib/dovecot/lda sieve_global_path: /var/mail/.dovecot.sieve sieve: ~/.dovecot.sieve sendmail_path: /usr/lib/sendmail auth_socket_path: /var/run/dovecot/deliver-auth auth lda: default_realm: jensenmaritime.com user: postmaster passdb: driver: ldap args: /etc/dovecot/lda-ldap.conf userdb: driver: static args: allow_all_users=yes user=%Lu uid=206 gid=206 home=/var/mail/%Lu socket: type: listen master: path: /var/run/dovecot/deliver-auth mode: 384 user: vmail group: vmail auth default: mechanisms: PLAIN LOGIN default_realm: jensenmaritime.com user: postmaster passdb: driver: ldap args: /etc/dovecot/default-ldap.conf userdb: driver: static args: user=%Lu uid=206 gid=206 home=/var/mail/%Lu socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix plugin: acl: vfile # grep -v '^ *$#.*$\?$' /etc/dovecot/dovecot-ldap.conf uris = ldap://127.0.0.1:389/ ldap_version = 3 base = ou=users,ou=accounts,dc=jensenmaritime,dc=com scope = onelevel auth_bind = yes pass_filter = (&(objectClass=CourierMailAccount)(!(disableimap=*))(mail=%Lu)) pass_attrs = auth_username_format=%Lu # uname -a Linux milne 2.6.28-hardened-r9 #4 SMP Mon Jun 7 10:50:28 PDT 2010 x86_64 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux (Using Gentoo 64-bit Linux)

3 9

Re: [Dovecot] Todays Performance Data for 2.0.x
by Timo Sirainen 09 Nov '10

09 Nov '10

Dividing the imap processes's system CPU usage by number of imap processes: imap : 0.478872 of 975 imap : 0.460797 of 1242 imap : 0.409641 of 2482 imap : 0.424035 of 4711 imap : 0.488494 of 6148 imap : 0.56809 of 7031 imap : 0.734864 of 6965 So it's about 0.5 seconds of system CPU per imap login. I also get something like 0.3 seconds of system CPU per imap login on my system. Also setting: service imap { service_count = 0 } (i.e. reuse imap processes) reduced the system CPU usage to almost nothing. But if you use different UIDs for different users you can't do that. So, yeah, looks like the process initialization is wasting time somewhere. I'll look further into it.

2 3

[Dovecot] Can't expand ~ for mail root dir
by Leo Baltus 09 Nov '10

09 Nov '10

Hi, I am not an this list, I hope it gets through: We just moved from dovecot-1.2.12 to dovecot-2.0.6. One of our users wants his mail directly in his homedir which worked fine so far but with 2.0.6: Nov 09 15:19:25 imap(foo.bar(a)example.com): Error: user foo.bar(a)example.com: Initialization failed: Initializing mail storage from mail_location setting failed: No home directory for system user. Can't expand ~ for mail root dir in: ~:INBOX=/e/ml/tech1/home/foo from dovecot.conf: userdb { args = /some/path/to/passwd driver = passwd-file } passwd: foo.bar@example.com::1019:1019:Foo Bar:/e/ml/tech1/home/foo::userdb_mail=maildir:~:INBOX=/e/ml/tech1/home/foo We've changed that for now: foo.bar@example.com::1019:1019:Foo Bar:/e/ml/tech1/home/foo::userdb_mail=maildir:/e/ml/tech1/home/foo:INBOX=/e/ml/tech1/home/foo ~/mail did work but was not desired by the user: foo.bar@example.com::1019:1019:Foo Bar:/e/ml/tech1/home/foo::userdb_mail=maildir:~/mail:INBOX=/e/ml/tech1/home/foo ~/ didn't work either: foo.bar@example.com::1019:1019:Foo Bar:/e/ml/tech1/home/foo::userdb_mail=maildir:~/:INBOX=/e/ml/tech1/home/foo -- Leo Baltus, internetbeheerder /\ NPO ICT Internet Services /NPO/\ Sumatralaan 45, 1217 GP Hilversum, Filmcentrum, west \ /\/ beheer(a)omroep.nl, 035-6773555 \/

2 1