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
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
On 12/17/2013 8:02 AM, Reindl Harald wrote: there are enough writing their address uppercase while the server was never configured that way, there are enough writing firstnamelastn...@domain.tld and you can hardly find a normal person who accepts that writing a message to "y...@domain.tld" goes to a different person than "y...@domain.tld" or bounce in one of the cases There are also listservs and other things out there which case fold email addresses--some fold to lowercase, some to uppercase. Current best practice is treat the entire email address as case insensitive.
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
On 2013-12-17 11:02 AM, Reindl Harald wrote: there are enough writingfirstnamelastn...@domain.tld and you can hardly find a normal person who accepts that writing a message to"y...@domain.tld" goes to a different person than"y...@domain.tld" or bounce in one of the cases I agree, but as I said - his system/server, his rules...
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
Am 17.12.2013 16:55, schrieb Charles Marcus: > On 2013-12-17 2:39 AM, Andreas Schulze wrote: >> Am 16.12.2013 15:25 schrieb Charles Marcus: >>> >auth_username_format = %Lu" >>> >This really should be the default... >> I disagree. That solve a symptom, not the problem. >> >> As of rfc3522 a localpart*may* be used case sensitive or not. >> I suggest a switch "my_local_parts_are_casesensitive = yes/no" >> or "my_local_parts_are_caseINsensitive = no/yes" >> The name and default must be well selected and not break existing behaviour. >> >> I think that's more transparent then changing an mostly unvisible setting. > > Your system, your rules, however... > > Just because you *can* do something doesn't mean you *should* do it - and > just because something is RFC compliant > doesn't mean you should always implement it that way. > > There are very few compelling arguments for supporting identical usernames > differing only by case. One is some kind > of legacy (unix) environment where you already have a lot of these... but I > can't readily think of another (good > one)... in fact it does always harm because users there are enough writing their address uppercase while the server was never configured that way, there are enough writing firstnamelastn...@domain.tld and you can hardly find a normal person who accepts that writing a message to "y...@domain.tld" goes to a different person than "y...@domain.tld" or bounce in one of the cases signature.asc Description: OpenPGP digital signature
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
On 2013-12-17 2:39 AM, Andreas Schulze wrote: Am 16.12.2013 15:25 schrieb Charles Marcus: >auth_username_format = %Lu" >This really should be the default... I disagree. That solve a symptom, not the problem. As of rfc3522 a localpart*may* be used case sensitive or not. I suggest a switch "my_local_parts_are_casesensitive = yes/no" or "my_local_parts_are_caseINsensitive = no/yes" The name and default must be well selected and not break existing behaviour. I think that's more transparent then changing an mostly unvisible setting. Your system, your rules, however... Just because you *can* do something doesn't mean you *should* do it - and just because something is RFC compliant doesn't mean you should always implement it that way. There are very few compelling arguments for supporting identical usernames differing only by case. One is some kind of legacy (unix) environment where you already have a lot of these... but I can't readily think of another (good one)... -- Best regards, */Charles/*
Re: [Dovecot] Accessing plain text password from memory
Hi Timo,
thanks for the answer. I'm working on a plug in with an similar
architecture.
Is there also a way to pass that plain password to a mail filter script?
Obviously, the %w option as mail filter script argument does not work.
Kind regards,
Philipp
On 13/12/13 15:47, Timo Sirainen wrote:
On 13.12.2013, at 16.37, Stanislas SABATIER wrote:
Is there a way to retrieve the client's password in plain text from memory ?
I don't store the password in plain text in my postgreSQL but I need it
when the client is connected to make crypto computation.
If I write a plugin to do the job, how could I retrieve the plain text
password from master ?
Assuming you you're using passdb sql and userdb prefetch and you want to access
the password in imap/pop3/etc process, you can do:
password_query = '%w' as userdb_password, ...
Then the password will be available the same way as plugin { password } would
be available (mail_user_plugin_getenv()).
You could also write a passdb plugin you could access the password directly from
auth_request->mech_password.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Dovecot] Dovecot proxy and Postfix SASL
To be fair on this: The main driver behind this is security and having front end systems in a DMZ with only minimal (if any) access to the back end servers. Of course saslauthd will need SOME access to the remote (back-end) IMAP (one IP port?). But this can also be accomplished by having the front end Postfix authenticate on the Dovecot back-end by setting it up to talk to the auth process via an ip-listener ALSO on just one IP port. Does this make sense? AM I missing something? Andreas On 17-12-2013 14:48, Andreas Kasenides wrote: Can somebody please verify that currently (v 2.2.9) SMTP AUTH using SASL from Postfix with Dovecot proxy is still not supported as discussed in these threads (especially the first one)? http://www.dovecot.org/list/dovecot/2012-August/067977.html http://www.dovecot.org/list/dovecot/2011-May/059107.html As I understand it is possible to use saslauthd to do this by using the remote imap option (rimap). Such a facility is important since I am attempting to separate the outward facing servers (dovecot proxy, postfix relay) that have no knowledge of user databases from the backends. thanx Andreas
[Dovecot] Dovecot proxy and Postfix SASL
Can somebody please verify that currently (v 2.2.9) SMTP AUTH using SASL from Postfix with Dovecot proxy is still not supported as discussed in these threads (especially the first one)? http://www.dovecot.org/list/dovecot/2012-August/067977.html http://www.dovecot.org/list/dovecot/2011-May/059107.html As I understand it is possible to use saslauthd to do this by using the remote imap option (rimap). Such a facility is important since I am attempting to separate the outward facing servers (dovecot proxy, postfix relay) that have no knowledge of user databases from the backends. thanx Andreas
[Dovecot] reproducible dsync backup panic (dovecot 2.2.7)
Hi all,
I'm receiving a reproducible dsync backup panic for some of my users. The error
message is as follows:
dsync-remote(user@): Panic: file dsync-brain-mailbox-tree-sync.c: line
111 (dsync_brain_mailbox_tree_sync_change): assertion failed:
(brain->no_backup_overwrite)
dsync-remote(user@): Error: Raw backtrace:
/usr/lib/dovecot/libdovecot.so.0(+0x69b70) [0x7f922dad9b70] ->
/usr/lib/dovecot/libdovecot.so.0(default_fatal_handler+0x2a) [0x7f922dad9c4a]
-> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f922da94725] ->
/usr/bin/dsync(dsync_brain_mailbox_tree_sync_change+0x382) [0x42f912] ->
/usr/bin/dsync(dsync_brain_recv_mailbox_tree_deletes+0x10b) [0x42f4db] ->
/usr/bin/dsync(dsync_brain_run+0x305) [0x42c6f5] -> /usr/bin/dsync() [0x42cbe8]
-> /usr/bin/dsync() [0x43e040] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x36) [0x7f922daea066] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0xd7) [0x7f922daeaf07] ->
/usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f922dae9b78] ->
/usr/bin/dsync() [0x4297f9] -> /usr/bin/dsync() [0x4133cd] ->
/usr/bin/dsync(doveadm_mail_try_run+0x251) [0x414091] ->
/usr/bin/dsync(main+0x3c8) [0x412f78] ->
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f922d704ead] ->
/usr/bin
/dsync()
[0x413191]
dsync-local(user@): Error: read() failed: EOF
dsync-local(user@): Error: Remote command returned error 134
The command I'm using to back up individual user's mail is something like:
sudo -u vmail dsync -v -u u...@server.com -R backup ssh -i sshid-file
lo...@server.com sudo -u vmail dsync -v -u u...@server.com
I use the above command at the backup server. The error started to appear a few
weeks after we started using the new mail system. First it appeared for a
single user, now it appears for some more users as well. It is deterministic
and reproducible.
Any ideas?
I included the relevant part of my config below.
Best regards,
Peter
---
# 2.2.7 (5c876ed0c3e0): /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.2
auth_master_user_separator = *
auth_mechanisms = plain login
hostname =
listen = *
login_greeting = $hostname IMAP server
mail_attachment_dir = /mail/mailboxes/%d/_attachments_
mail_attachment_fs = sis-queue $mail_attachment_dir/queue:posix
mail_attachment_min_size = 16 k
mail_location = mdbox:~
mail_plugins = " zlib acl"
mdbox_rotate_interval = 5 days
mdbox_rotate_size = 5 M
namespace {
inbox = yes
location =
prefix =
separator = /
type = private
}
namespace {
list = children
location = mdbox:/mail/mailboxes/%%d/%%n:INDEX=/mail/mailboxes/%%d/%%n
prefix = Accounts/%%n/
separator = /
subscriptions = no
type = shared
}
passdb {
args = /mail/config/dovecot/passwd
driver = passwd-file
}
passdb {
args = /mail/config/dovecot/passwd-master
driver = passwd-file
master = yes
pass = yes
}
plugin {
acl = vfile
acl_defaults_from_inbox = yes
acl_shared_dict = file:/mail/mailboxes/%d/shared-mailboxes.db
zlib_save = gz
zlib_save_level = 6
}
postmaster_address = postmaster@
protocols = imap
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
service imap-login {
inet_listener imap {
port = 0
}
inet_listener imaps {
port = 993
ssl = yes
}
}
syslog_facility = local6
userdb {
args = uid=vmail gid=vmail master_user=%u home=/mail/mailboxes/%d/%n
driver = static
}
protocol imap {
mail_plugins = " zlib acl imap_acl"
}
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUrANcV3r2wJMiz2NAQI1rQf/Q4Uo1qehJBOEJ3eMkzdyzbAFw2dEOgA0 UYnVLBihEU6Ubta5X/4JiNR6dBWwf+D7w8IKkUfoUUw2HxqpXrrls8Mzl4DJC9DO ID2IABClDAqe+mK75+mjAUb9duaXHwqr3nFKV6iQ1jIqQzEVw+yMXOm2CwTa1+uu JNyy0CoSu7rw+AmsqDMdpN7F+IjgwLHF8qKBGIm0FTfjmlYc3chePjIaD0GjSj9m +aztbs1jnB0PizfCd1jxfsxLIfDRbE1CbrQOhTIWaHLzZnv8YFPIc+d/LD7jtnSl 1k2Beg0LRFXwa2f0p9LwmB52s8yTxOrvwNjNS5wepjRYvArN7ra1HA== =dapR -END PGP SIGNATURE-
Re: [Dovecot] configure lmtp to deliver to email addresses case insensitively
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 17 Dec 2013, Adrian Zaugg wrote: RFC 2821, Page 13, 1st paragraph: "The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations 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. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUrAM2V3r2wJMiz2NAQLscQf9FC88YCmpCib9J2THqZlSUs8ctuf6pD08 VvS4GqU5fujt0rwJkGTvcxk/bSSGhX6onQouL6KJrW7Dp6JDaZaheOYPufLEyK3R oLRR9E+2twGmmJ45lDiqxO9REjwaNrtaINcHk6x+OREf+1Z0xk3juUNtz63TzdoG e2JYxhWaYbotky+Tzj7yQScqXYEfq8isTYTIW9+2rZalPjgUK6JaknOwqVpGrhgG XkE5WlEJJePbUqalhVzKJ+MrRkNUplPtbkEkgOxfraOd6h7H0dyprohQokkFPgbB 5pZ6vdqCDS0epS/hzCedZ5s/onmgpAQlMdyu6Zgz+R/v+jhyn8KZvQ== =/1EB -END PGP SIGNATURE-
