Re: Dovecot Oy merger with Open-Xchange AG
I think everyone shares your concerns. But there are no rules that the outcome of this merger must get something bad, so let's see what happens. I hope that it's true what Timo said and that dovecot can evolve and get even better as it is today. Good luck guys! Regards, Adrian. On 23.03.15 15:08, Andreas Kasenides wrote: I find it extremely interesting that no one has commented on the merger of Dovecot Oy and Open-Xchange AG as announced by Timo on the 19th. Is this something that was known a long time ago and I missed? OK checked the on-line archive of the mailing list, no comments there - its not my email set-up - LOL. I am usually emotionally (at least) against of open-source projects loosing their independence to large corporations. Possibly due to bad experiences in the past when OSS were driven from Open to Obscure in the process of trying to make money out of them. I have several examples in mind but I will not give names. At least that is the impression I have which might be entirely wrong since when big companies begin to ask for large sums of money we just have to move away due to the small budget. Anyway this is not to about judging the move. Which I cannot do since I have no knowledge whatsover of the Dovecot enterprise internals and the difficulties that come with managing a leading software product. And, secondly, since I am (my employer ie) a non paying customer!! I was just struck by the fact that no one has commented on it. I wish Dovecot the best in the new environment. Andreas On 19/03/15 12:26, Timo Sirainen wrote: Hi all, Today I can finally announce that Dovecot Oy company has merged with Open-Xchange AG. This helps us to get more Dovecot developers, support people and so on. Most importantly, eventually it should allow me to get back to doing what I like the most: Designing new and interesting stuff for Dovecot and perfecting the old stuff :) OX is a great match to Dovecot going forward. They also really like open source and share our plans for the future. Nothing big will change as a result of this merger: Dovecot will stay Dovecot with its own name and release schedules. We're not going to force OX and Dovecot to be the same product, other than having a somewhat deeper integration between them. Here are the press release links about it: http://www.dovecot.fi/open-xchange-and-dovecot-announce-merger-to-create-worlds-leading-open-source-messaging-software-provider/ http://www.open-xchange.com/dovecot http://www.open-xchange.com/announcements/18
Re: [Dovecot] master password
http://wiki2.dovecot.org/Authentication/MasterUsers Regards, Adrian. Am 21.01.14 21:31 schrieb Marc Perkel: This is probably easy but how would a set a secret static master password so that if I typed it in for any login it would be happy? I can't use the * separator method in this case because it screws up squirrelmail.
Re: [Dovecot] Sizing MTA servers
Am 17.01.14 10:53 schrieb Stan Hoeppner: On 1/16/2014 6:56 PM, Murray Trainer wrote: MTA = disk. Always has always will. Disk throughput is always the critical factor for queue performance, and an MTA is little more than a queue. Which makes it surprising that so many people ignore disk when talking about mail servers, as you have done here. Exim tries to deliver every message without queueing it first. Exim writes only those messages to the queue, which can't be delivered immediately or if too many connections are coming in at a time. This doesn't invalidate what Stan said, it should just clarify that under normal operation the disks won't be stressed that much under exim. It will be much more of a challenge to design the whole infrastructure for reliability and to make the right decisions on your mail storage and those machines than your mail frontend. Regards, Adrian.
Re: [Dovecot] int/ext mailserver
Hi Mr.Pine Am 19.12.13 08:59 schrieb Mr.Pine: 1. I have a root access to ext mail server. But do not know my ext user password!. How can I use getmail to move ext mail to internal one?! You better ask this on the getmail mailing list: http://pyropus.ca/software/getmail/documentation.html#mailing-list-users 2. What is your idea about syncing users password in internal/external mail server?! I think its needed for getmail! ditto 3. How can I restrict my internal users to send mail only internally!? This probably is done best in postfix. Your setup seems very weird to me, I suppose I am not the only one - anyway you will have your reasons. Regards, Adrian.
Re: [Dovecot] SSL/TLS handshake stays forever without timeout
Hi Pascal Am 14.01.14 20:26 schrieb Pascal Volk: On 01/14/2014 04:42 PM morrison wrote: Please define 'forever' I just did `time openssl s_client -connect mail.example.com:143 -starttls imap` (and nothing else): This is not the test morrison has suggested. Doing his test with telnet and thus not complete the SSL handshake, the connection stays open much longer than 3 Minutes. I closed the connection now manually after a little more than 2 hours. This is on Dovecot 2.1.7. Regards, Adrian.
[Dovecot] imap auto create mailbox: we're not in group 8(mail)
Dear List
Somehow I don't understand the intended work flow to have new mailboxes
auto created. On login of a new user with no mailbox, I get
2014-01-09 12:53:06 imap(tester): Error: user tester: Initialization
failed: Namespace '': mkdir(/var/mail/tester) failed: Permission denied
(euid=1016(tester) egid=1016(tester) missing +w perm: /var/mail, we're
not in group 8(mail), dir owned by 0:8 mode=0771)
The imap process runs as the user the login performed and thus it has
only the privileges of that user. This is good and desired, when a
mailbox already exists. I do not want to allow all users to write to
/var/mail, only they should write to their dirs inside /var/mail.
Same story for LMTP, if no mailbox exists yet:
2014-01-09 13:01:47 lmtp(20416, tester): Error: user tester:
Initialization failed: Namespace '': mkdir(/var/mail/tester) failed:
Permission denied (euid=1016(tester) egid=1016(tester) missing +w perm:
/var/mail, we're not in group 8(mail), dir owned by 0:8 mode=0771)
How can I configure the auto create mailbox feature that it works and
let run LMTP and IMAP process as user %u and group mail and let create
the mailboxes in /var/mail as (example user tester) with the following
permissions:
/var/mail:
drwxrwx--x root mail3072 Dec 18 01:43 .
drwx-- tester tester 1024 Jan 09 12:53 tester
...or do I need a different approach?
Thank you for helping me.
Best regards, Adrian.
My setup:
* Exim delivers to LMTP socket as user %u, group mail
* maildir storage in /var/mail
doveconf -n:
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.3 ext3
auth_cache_negative_ttl = 0
auth_cache_size = 5 M
auth_cache_ttl = 4 hours
auth_failure_delay = 3 secs
auth_mechanisms = plain login digest-md5 cram-md5 apop rpa
auth_username_format = %n
auth_verbose = yes
auth_worker_max_count = 128
first_valid_gid = 1000
first_valid_uid = 1000
last_valid_gid = 6
last_valid_uid = 6
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
log_path = /var/log/dovecot/dovecot.log
log_timestamp = %Y-%m-%d %H:%M:%S
login_log_format_elements = user=%u method=%m rip=%r lip=%l mpid=%e %c %k
mail_location = maildir:/var/mail/./%u/:INDEX=MEMORY
mail_prefetch_count = 1024
maildir_stat_dirs = yes
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave vacation-seconds
namespace inbox {
inbox = yes
location =
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix =
type = private
}
passdb {
args = scheme=SHA512-CRYPT username_format=%u /etc/cram-md5.pwd
driver = passwd-file
}
plugin {
sieve = /var/mail/%u/sieve/.dovecot.sieve
sieve_before = /var/mail/%u/sieve/vacation.sieve
sieve_dir = /var/mail/%u/sieve
sieve_extensions = +vacation +vacation-seconds
sieve_max_actions = 1024
sieve_vacation_default_period = 12d
sieve_vacation_max_period = 0
sieve_vacation_min_period = 1d
}
postmaster_address = postmaster@
protocols = imap lmtp sieve pop3
service auth-worker {
user = $default_login_user
}
service auth {
group = mail-security
unix_listener auth-client {
mode = 0660
user = Debian-exim
}
unix_listener auth-userdb {
mode = 0666
}
user = $default_internal_user
}
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
process_min_avail = 5
}
service lmtp {
process_min_avail = 10
unix_listener lmtp {
mode = 0666
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
inet_listener sieve_deprecated {
port = 2000
}
service_count = 1
vsz_limit = 64 M
}
service pop3-login {
inet_listener pop3 {
port = 110
}
inet_listener pop3s {
port = 995
ssl = yes
}
}
service pop3 {
process_limit = 256
}
ssl_cert = /etc/ssl/
ssl_cipher_list =
DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:+TLSv1:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!SSLv2:!3DES:!DSS
ssl_key = /etc/ssl/
ssl_parameters_regenerate = 128 hours
userdb {
args = blocking=no
driver = passwd
override_fields = home=/var/mail/%u mail=maildir:/var/mail/%u
}
protocol lmtp {
mail_plugins = sieve
}
protocol lda {
mail_plugins = sieve
}
protocol imap {
mail_max_userip_connections = 64
}
protocol pop3 {
mail_max_userip_connections = 32
pop3_client_workarounds = oe-ns-eoh
pop3_save_uidl = yes
}
Re: [Dovecot] imap auto create mailbox: we're not in group 8(mail)
Hi Steffen Am 09.01.14 13:36 schrieb Steffen Kaiser: The errors says all. Almost ... If I understand you correctly, I can chose one of the three options you presented to me, right? If so, 3) I did until now. 2) no way. To 1): I now set mail_privileged_group = mail drwxrwx--x 94 root mail 3072 Dec 18 01:43 /var/mail But I still get the same error. The LMTP and the IMAP process do still get executed under group %u, when they try to create the mailbox. What's wrong? Thank you for your help! Best regards, Adrian. 1) See: # Group to enable temporarily for privileged operations. Currently this is # used only with INBOX when either its initial creation or dotlocking fails. # Typically this is set to mail to give access to /var/mail. #mail_privileged_group = # Grant access to these supplementary groups for mail processes. Typically # these are used to set up access to shared mailboxes. Note that it may be # dangerous to set these if users can create symlinks (e.g. if mail group is # set here, ln -s /var/mail ~/mail/var could allow a user to delete others' # mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it). #mail_access_groups = 2) chmod 1777 /var/mail 3) pre-create your user dirs
Re: [Dovecot] LMTP with virtual and system users
Am 07.01.14 13:21 schrieb Philipp Kolmann: I didn't want to have lda SUID root... Is this necessary? Exim calls the dovecot-lda as user $local_part and if you setup your mail storage to have the right permissions, this should work without SUID. But maybe I'm wrong; anyway in the wiki there is a section on how-to use LDA without setting the process SUIDed. http://wiki2.dovecot.org/LDA/Exim - towards the end of the page Cheers, Adrian.
Re: [Dovecot] How to remove Dovecot (LMTP) information from Email header
Dear Anant According to RFC 3848 you should not remove those headers. RFC 5321 (SMTP), Section 4.4. also says that trace information is mandatory to add and RFC 2033 (LMTP) makes no exception to this. If you do not like those headers, use LDA for local storage, it doesn't add any headers. Regards, Adrian. On 02/01/14 15:03, Anant wrote: Hello All, I want to remove Dovecot (LMTP) information from Email Header, Please help me. I am using Dovecot 2.0.9 with Exim. Received: from XX.XXblue.co.uk by XX.XXblue.co.uk*(Dovecot) with LMTP id* XIuTJkJFxVLKTwAAG2fxGQ for anant.saras...@techblue.co.uk; Thu, 02 Jan 2014 10:59:28 + Received: from [210.7.64.2] (helo=[192.168.100.71]) by solo.techblue.co.uk with esmtp (Exim 4.72) (envelope-from sysad...@techblue.co.uk) id 1Vyfzr-0005Oy-7H for anant.saras...@techblue.co.uk; Thu, 02 Jan 2014 10:59:28 + Thanks Regards, Anant Saraswat
Re: [Dovecot] LMTP with virtual and system users
Hi Philipp
You are completely right, the proposed solution doesn't work. It seems
exim always qualifies an address without a domain, I believe this is
because LMTP requiers to get only qualified addresses (LMTP is based on
SMTP and the RFC, if I read it correctly specifies it like this).
So, another solution would be to use LDA for your local users and LMTP
for the rest. The configuration for exim would be: a router and a
transport for your local users using LDA, and your virtual users setup
as you have it using LMTP.
local_user:
debug_print = R: local_user for $local_part@$domain
driver = accept
domains = @ : localhost : ${primary_hostname}
check_local_user
transport = dovecot_lda
cannot_route_message = Unknown user
dovecot_lda:
driver = pipe
command = /usr/lib/dovecot/dovecot-lda \
-f $sender_address \
-a $original_local_part@$original_domain
log_output
delivery_date_add
return_path_add
envelope_to_add
user = $local_part
group = mail
temp_errors = 64 : 69 : 70 : 71 : 72 : 73 : 74 : 75 : 78
Please check man dovecot-lda and the dovecot wiki
(http://wiki2.dovecot.org/LDA/Exim) for details. Also check the
permissions you need for dovecot-lda to write to your mailspool (user
and group options from the transport).
I haven't tried the above, but I think it works like this ...
Best regards, Adrian.
Am 30.12.13 09:40 schrieb Philipp Kolmann:
Hi Adrian,
Am 26.12.2013 12:20, schrieb Adrian Zaugg:
You can use exim to prepare the address as you wish: only the user name
for pam users and the full address for virtual users.
Configure a new router to strip the domain part for pam users:
local_pam_users:
debug_print = R: strip domain for local pam users
driver = redirect
check_local_user
domains = @ : localhost : ${primary_hostname}
data = ${local_part}
redirect_router = local_user
I'm not 100% sure of the domains condition; it should restrict the
router to your domain(s) where your pam users receive their email. The
redirect_router designates the router which routes your local deliveries
to your lmtp transport. Place the new router to run just before your
local_user router.
Since your config works for your virtual users, you don't need to do
anything in addition.
I had tried this once already. I have used your snipplet and attached
the debug output from exim. Sadly it didn't work, because the mtp
process got the foll email again and not just the username.
thanks
Philipp
Re: [Dovecot] LMTP with virtual and system users
Hi Philipp
You can use exim to prepare the address as you wish: only the user name
for pam users and the full address for virtual users.
Configure a new router to strip the domain part for pam users:
local_pam_users:
debug_print = R: strip domain for local pam users
driver = redirect
check_local_user
domains = @ : localhost : ${primary_hostname}
data = ${local_part}
redirect_router = local_user
I'm not 100% sure of the domains condition; it should restrict the
router to your domain(s) where your pam users receive their email. The
redirect_router designates the router which routes your local deliveries
to your lmtp transport. Place the new router to run just before your
local_user router.
Since your config works for your virtual users, you don't need to do
anything in addition.
Regards, Adrian.
Am 25.12.13 08:16 schrieb Philipp Kolmann:
Hi,
I have a mailsystem where i have some local users with shell access and
full home dirs which receive mail and also several SQL virtual users
only for mail.
With the virtual users, everything works fine. Mail is delivered via
LMTP and also sieve works :)
The SQL Lookup knows what to do with usern...@domain.com
The problem is the system user. If exim delivers the mail to the lmtp
socket, the LMTPd can't find usern...@local.host
I would be able to specify the global auth_username_format=%n but then
my SQL queries break and I like the possibility to have x...@domain1.com
and x...@domain2.com routed to two different accounts.
As I have seen in the source, I can't specify username_format=%n in the
passdb { driver = pam } backend. Do you have any suggestion how to
solve this issue?
thanks
Philipp
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
I've updated the wiki under:
http://wiki2.dovecot.org/LMTP/Exim
to document the discussed problem. Maybe someone can review this.
Regards, Adrian.
Am 19.12.13 22:59 schrieb Timo Sirainen:
auth_username_format = %u
protocol lmtp {
auth_username_format = %Lu
}
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
Am 18.12.13 11:33 schrieb Timo Sirainen:
I think this would work as well:
protocol lmtp {
auth_username_format = %Lu
}
I tried this with dovecot 2.1.7, but it did not work. It may work on a
newer dovecot?
Regards, Adrian.
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
Hi again
Thanks for helping me on this, especially to Steffen. If you do not need
case sensitivity on user names the use of a redirect router in exim to
lowercase the local part of the address to deliver works well.
If one wants for whatever reasons to have support for user names, that
just differ in its case, you could put more logic in that router to make
that work. Since I did not need that, I can't post it here...
So the solution to the problem is:
A) Either:
-
Configure dovecot auth to lower case user names, which LMTP inherits, by
setting
auth_username_format = %Lu
Co-Effect: authenticating logins with wrongly cased user names do also
succeed.
B) Or:
-
Configure your MTA to do the Job. With exim, add a new router just
before local delivery takes place, like this:
lowercase_local:
debug_print = R: lower case local_part for local delivery
driver = redirect
redirect_router = local_user
data = ${lc:${local_part}}
and proceed with the local_user router:
local_user:
debug_print = R: local_user for $local_part@$domain
driver = accept
domains = +local_domains
check_local_user
local_parts = ! root
transport = dovecot_lmtp
cannot_route_message = Unknown user
then add your LMTP transport:
dovecot_lmtp:
driver = lmtp
socket = /var/run/dovecot/lmtp
batch_max = 256
timeout = 2m
delivery_date_add
Has just the effect that login names stay case sensitive (if nothing
else is set in dovecot by auth_username_format) but not email addresses,
and in spite of being treated as case insensitive, email addresses
retain their case.
Maybe some one can add this to the wiki under
http://wiki2.dovecot.org/LMTP/Exim?highlight=%28LMTP%29#Using_LMTP_over_UNIX_Socket
The code there is anyway not very nice by using the manualroute router with:
route_data = whatmeworry # required but not useful
Thanks again to everyone for helping.
Regards, Adrian.
Am 17.12.13 09:38 schrieb Steffen Kaiser:
On Tue, 17 Dec 2013, Steffen Kaiser wrote:
However, it's maybe best to lowercase the local part in the exim
lmtp-transport and leave dovecot's LMTP in peace.
that's what I wanted to suggest :)
More or less, it is the duty of the MTA, IMHO.
Um, sorry, forgot the link:
http://www.gossamer-threads.com/lists/exim/users/4551
that looks promising.
-- Steffen Kaiser
[Dovecot] configure lmtp to deliver to email addresses case insensitively
Dear List Using dovecot 2.1.7 with LMTP and exim4 I want to accept local parts regardless of their case. Exim does all virtual alias handling and delivers the messages to dovecot LMTP addressed to the right mailbox name. This works well except for addresses which do not need to be resolved by exim and which do have the wrong case in the local part. For example: There is a mailbox and a user on the mailsystem example.org called user. Mails to u...@example.org get delivered just as they should. If an incoming message is addressed to u...@example.org with upper case local part, exim passes the message to LMTP with the case unaltered (RFC 2821 conform), but LMTP fails with: LMTP error after RCPT TO:u...@example.org: 550 5.1.1 u...@example.org User doesn't exist: u...@example.org How can I tell dovecot to deliver USER to the mailbox user aswell? Thank you for your help. Best regards, Adrian. (I have tried to use %Ln and %Lu in mail_location setting with no success.)
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
Hi Marcus The change of adding an L to auth_username_format = %Ln indeed has the side effect, that LMTP delivers wrongly cased addresses. But the main effect and disadvantage is, that authenticating logins with wrongly cased usernames do also succeed, which I actually do not like to happen. Isn't there another solution? A feature request for a new option lmtp_username_format? Regards, Adrian. Am 16.12.13 21:25 schrieb Charles Marcus: On 2013-12-16 2:36 PM, Adrian Zaugg a...@ente.limmat.ch wrote: How can I tell dovecot to deliver USER to the mailbox user aswell? Username LDAP lookups are case-insensitive. Unless you somehow normalize the username, it's possible that a user logging in as user, User and uSer are treated differently. The easiest way to handle this is to tell Dovecot to change the username to the same case as it's in the LDAP database. You can do this by returning user field in the pass_attrs, as shown in the above example. If you can't normalize the username in LDAP, you can alternatively lowercase the username in dovecot.conf: auth_username_format = %Lu See: http://wiki2.dovecot.org/AuthDatabase/LDAP/PasswordLookups This really should be the default...
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
Am 16.12.13 22:55 schrieb Charles Marcus: On 2013-12-16 4:32 PM, Adrian Zaugg a...@ente.limmat.ch wrote: But the main effect and disadvantage is, that authenticating logins with wrongly cased usernames do also succeed, which I actually do not like to happen. Trying very hard to understand why this would be a problem. On *nix hosts login names are always case sensitive. Why should this change with the same login name for eMails when it doesn't for for ssh, FTP, Webserver-Login, Database-Login ... ? It's nicer if a system acts consistent. Regards, Adrian.
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
Hi David I believe RFC822 email addresses are case-insensitive, and (in some RFC 2821, Page 13, 1st paragraph: The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user smith is different from the user Smith. However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. (http://tools.ietf.org/html/rfc2821#section-2.4) cases, especially ones where there's just a mail server) it's entirely possible that people remember their account names with some capital letters that aren't in user db. (System knows you as mrsmithy@mail.domain, while the user may remember the account as MrSmithy@mail.domain or MrsMithy@mail.domain...). Also, people with I just want login names to be case sensitive but not email addresses, and in spite of being treated as case insensitive email addresses should retain their case, just like defined and suggested in the RFC. This reduces support calls because it's con-formant and we have a clear policy: Usernames are always lower case, non-email addresses, the same simple and short name for all our services. There is nothing easier than this. We use this since 17 years and it works without confusion. If a user now spots that suddendly any capitalization of usernames is working when logging in to the webmail, how can I explain that this doesn't work with other services like FTP? smartphones may not notice that the phone helpfully uppercased the first letter of a lowercase user name. Forcing case reduces support calls, which is always a good thing. That's why email addresses should be allowed containing capitalizations. On smartphone people tend to use MUAs and there the username is saved and not entered each and every time, so for the username this is less true, I think. Back to dovecot: Using LDA as a transport for the dovecot store, it used to work perfectly (with dovecot 1.x). It's just LMTP that spits, because it looks up the local part in the userdb, which is PAM in our case. I won't change PAM to act case insensitive: I'm not in the position to change a common sense in the computing world as it always was. It's enough Microsoft did that and probably just because of that we're having this discussion here... However, it's maybe best to lowercase the local part in the exim lmtp-transport and leave dovecot's LMTP in peace. Best regards, Adrian.
