Re: [Dovecot] dovecot stats
Am 08.05.2013 11:25, schrieb Jan-Frode Myklebust: Thanks, nice graphs. I've attached a graph over LMTP delays per minute as seen from the postfix side on one of our servers. This includes delays caused by both delivery to dovecot LMTP, and also LMTP communication internally on the mailservers between postfix and amavis. Unfortunately it says nothing about the delivery time to each individual dovecot backend, since these are hiding behind dovecot director, and therefor we have no way of knowing which of our backends are slow (if any). -jf i am not sure, i ll have to read more doku perhaps it makes sense to use delay stuff in log for analyse i.e after all i am not using directors, i have real loadbalancers private/dovecot-lmtp], delay=1.4, delays=1.2/0/0/0.17, dsn=2.0.0, status=sent Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
[Dovecot] SSL problems on dovecot 2.1.7
When I upgraded my debian-based imap server from squeeze to wheezy yesterday, SSL stopped working. I am using a http://cacert.org signed server sertificate, and I am reusing the certificates that were used on the 1.x dovecot of debian squeeze. My three MUAs that worked against the previous 1.x dovecot with the same certificate, now fails in various ways. Any hints and guesses as to how to debug this further will be highly appreciated. Even more appreciated will be a pin point of the issue. :-) Here are the error messages from the MUAs: - Opera 12.15 on Windows 7 just reports: The connection with the IMAP server was unexpectedly interrupted. - Emacs24(w/linked-in gnutls)/Ma Gnus 0.8 (Gnus git HEAD) on Windows 7 says imap.mydomain.com certificate could not be verified. - Emacs23/Ma Gnus 0.8 (also Gnus git HEAD) on debian testing (with Emacs23 gnutls-cli is run in a subprocess), says: Opening connection to imap.mydomain.com via tls... Opening TLS connection to `imap.mydomain.com'... Opening TLS connection with `gnutls-cli --insecure -p 993 imap.mydomain.com'...done Opening TLS connection to `imap.mydomain.com'...done Unable to open server nnimap+privat due to: Process *nnimap* not running When I try running gnutls-cli from the command line of the debian testing machine (the same gnutls-cli that is used by the emacs23/gnus combo), it seems to connect ok (the transcript of that session is below). The config for the SSL, from /etc/dovecot/conf.d/10-ssl.conf, is: # SSL/TLS support: yes, no, required. doc/wiki/SSL.txt ssl = yes # PEM encoded X.509 SSL/TLS certificate and private key. They're opened before # dropping root privileges, so keep the key file unreadable by anyone but # root. Included doc/mkcert.sh can be used to easily generate self-signed # certificate, just make sure to update the domains in dovecot-openssl.cnf ssl_cert = /etc/ssl/certs/imap_mydomain_com.pem ssl_key = /etc/ssl/private/imap_mydomain_com.key The access privileges of the files, are: -rw-r--r-- 1 root root 2077 Mar 27 12:45 /etc/ssl/certs/imap_mydomain_com.pem -rw--- 1 root root 3243 Jul 12 2011 /etc/ssl/private/imap_mydomain_com.key What follows, is the transcript from the gnutls-cli session from a debian testing machine to the server (which seems to be working as far as I can tell...): sb@edwards:~$ gnutls-cli -p 993 rainey.mydomain.com WARNING: gnome-keyring:: couldn't connect to: /home/sb/.cache/keyring-yeEdM3/pkcs11: No such file or directory Resolving 'rainey.mydomain.com'... Connecting to '212.110.185.190:993'... - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1023 bits - Peer's public key: 1023 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=imap.mydomain.com', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=supp...@cacert.org', RSA key 4096 bits, signed using RSA-SHA1, activated `2013-03-27 12:43:30 UTC', expires `2013-09-23 12:43:30 UTC', SHA-1 fingerprint `86f8a501bca1e2b0eadc677bf05b103d298ce247' - The hostname in the certificate does NOT match 'rainey.mydomain.com' sb@edwards:~$ gnutls-cli -p 993 imap.mydomain.com WARNING: gnome-keyring:: couldn't connect to: /home/sb/.cache/keyring-yeEdM3/pkcs11: No such file or directory Resolving 'imap.mydomain.com'... Connecting to '212.110.185.190:993'... - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1022 bits - Peer's public key: 1021 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=imap.mydomain.com', issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=supp...@cacert.org', RSA key 4096 bits, signed using RSA-SHA1, activated `2013-03-27 12:43:30 UTC', expires `2013-09-23 12:43:30 UTC', SHA-1 fingerprint `86f8a501bca1e2b0eadc677bf05b103d298ce247' - The hostname in the certificate matches 'imap.mydomain.com'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.2 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: * OK Waiting for authentication process to respond.. - Peer has closed the GnuTLS connection
Re: [Dovecot] Permission problem with LDA and dovecot 2.2.1
Am 09.05.2013 02:30, schrieb Ben Morrow:
At 9PM +0200 on 8/05/13 you (Tobi) wrote:
Am 08.05.2013 19:21, schrieb Ben Morrow:
At 6PM +0200 on 7/05/13 you (Tobi) wrote:
I tried with removing the base_dir definition from my config, restartet
dovecot and checked with the commands you provided below:
root@nordkap:~# doveconf -d base_dir
base_dir = /usr/local/var/run/dovecot
root@nordkap:~# doveconf base_dir
base_dir = /usr/local/var/run/dovecot
root@nordkap:~# su vmail -s /bin/sh -c doveconf base_dir
base_dir = /usr/local/var/run/dovecot
for me it seems that all is build with /usr/local
OK, that's odd. I was wondering if you had some permission problem which
was stopping the lda from reading the config file, but apparently not.
Sorry my subject is a bit misleading ;-)
I wasn't confused by the subject: IIRC if LDA can't read a config file,
it will simply ignore it (on the grounds that it is often running as an
ordinary user and so might not be supposed to), meaning that if the
permissions on the config file were too restrictive the LDA running as
vmail might not have seen the base_dir setting. Apparently that's not
the case...
As I updated today to wheezy anyway I built dovecot again with the
following options:
./configure --prefix=/usr/local --localstatedir=/usr/local/var
--with-mysql --with-sql
make make install
but as well with those after starting dovecot and postfix the errors of
the lda looking in /var/run occured again.
OK... interesting choice, now you understand why /usr/local/var is not
usually used, but anyway...
this localstatedir option was just a test to see if lda looks in the
localstatedir specified with configure. At least in my case it is not.
After that test I built again with localstatedir=/var (as suggested by
Christian) and like that it works fine without the symlink
But after removing the symlink and restarting dovecot I get the errors again
May 7 17:47:57 nordkap dovecot: lda: Error: userdb lookup:
connect(/var/run/dovecot/auth-userdb) failed: No such file or directory
May 7 17:47:57 nordkap dovecot: lda: Fatal: Internal error occurred.
Refer to server log for more information.
Are you sure you're running the right copy of dovecot-lda? I think you
mentioned xthread that you have a Debian-provided version installed as
well?
Yes I had the version from apt as well, but removed it today after
upgrading to wheezy. The lda is called from postfix by these lines in
master.cf
dovecot unix- n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f
${sender} -d ${user}@${nexthop}
so according to the path prefix it should be the correct copy of
deliver. Is there a switch to get the version from deliver? I tried the
usual -v and --version but no success. But even without the version I'm
99.99873% sure that the correct binary is used :-)
OK. So the next step is to try running deliver by hand, as vmail,
feeding it a mail from stdin, to see if that fails the same way. If it
does then I would next run it under strace, to see exactly what it's
trying to do and what files it's looking at.
You could also run ldd on deliver, just to make sure it's picking up the
right versions of the dovecot libraries. The hardcoded base_dir path
appears to be baked into libdovecot.so.0, so if you run
strings /path/to/libdovecot.so.0 | grep /var
As I actually built with localstatedir=/var all the paths are correct
ldd /usr/local/libexec/dovecot/deliver
...
libdovecot.so.0 = /usr/local/lib/dovecot/libdovecot.so.0
(0x7fc41bcd9000)
...
and
root@nordkap:~# strings /usr/local/lib/dovecot/libdovecot.so.0 | grep /var
/var/lib/dovecot/instances
/var/run/dovecot/config
/var/run/dovecot
/var/lib/dovecot
/var/run
/var/tmp
I will built dovecot again with localstatedir=/usr/local/var and
re-check the paths with the commands above.
Thanks for all the help here, really a great list
tobi
[Dovecot] dovecot not logging after upgrade to 2.1.7 on debian
After upgrading my IMAP server to the new debian stable, and upgrading
dovecot from 1.x to 2.1.7 in the process, dovecot no longer logs
anything to /var/log/mail.*. The last entries there are from before the
upgrade, and no starts or error messages or failed login attempts, since
then, have been logged.
Does anyone know what might cause this?
doveconf -n doesn't mention any of the log settings. Maybe the log
settings aren't picked up? What could be done to make sure they are
picked up?
Here's the content of the /etc/dovecot/conf.d/10-logging.conf file:
##
## Log destination.
##
# Log file to use for error messages. syslog logs to syslog,
# /dev/stderr logs to stderr.
log_path = syslog
# Log file to use for informational messages. Defaults to log_path.
#info_log_path =
# Log file to use for debug messages. Defaults to info_log_path.
#debug_log_path =
# Syslog facility to use if you're logging to syslog. Usually if you don't
# want to use mail, you'll use local0..local7. Also other standard
# facilities are supported.
syslog_facility = mail
##
## Logging verbosity and debugging.
##
# Log unsuccessful authentication attempts and the reasons why they failed.
#auth_verbose = no
# In case of password mismatches, log the attempted password. Valid values are
# no, plain and sha1. sha1 can be useful for detecting brute force password
# attempts vs. user simply trying the same password over and over again.
#auth_verbose_passwords = no
# Even more verbose logging for debugging purposes. Shows for example SQL
# queries.
#auth_debug = no
# In case of password mismatches, log the passwords and used scheme so the
# problem can be debugged. Enabling this also enables auth_debug.
#auth_debug_passwords = no
# Enable mail process debugging. This can help you figure out why Dovecot
# isn't finding your mails.
#mail_debug = no
# Show protocol level SSL errors.
#verbose_ssl = no
# mail_log plugin provides more event logging for mail processes.
plugin {
# Events to log. Also available: flag_change append
#mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
# Available fields: uid, box, msgid, from, subject, size, vsize, flags
# size and vsize are available only for expunge and copy events.
#mail_log_fields = uid box msgid size
}
##
## Log formatting.
##
# Prefix for each line written to log file. % codes are in strftime(3)
# format.
#log_timestamp = %b %d %H:%M:%S
# Space-separated list of elements we want to log. The elements which have
# a non-empty variable value are joined together to form a comma-separated
# string.
#login_log_format_elements = user=%u method=%m rip=%r lip=%l mpid=%e %c
# Login log format. %$ contains login_log_format_elements string, %s contains
# the data we want to log.
#login_log_format = %$: %s
# Log prefix for mail processes. See doc/wiki/Variables.txt for list of
# possible variables you can use.
#mail_log_prefix = %s(%u):
# Format to use for logging mail deliveries. You can use variables:
# %$ - Delivery status message (e.g. saved to INBOX)
# %m - Message-ID
# %s - Subject
# %f - From address
# %p - Physical size
# %w - Virtual size
#deliver_log_format = msgid=%m: %$
Re: [Dovecot] IMAP SSL proxy (questions)
On 05/08/2013 01:57 PM, Ben Morrow wrote: At 10AM -0600 on 8/05/13 you (Trever L. Adams) wrote: Hello everyone, I have seen: http://wiki.dovecot.org/HowTo/ImapProxy. It doesn't seem to fit what I need. That page is for Dovecot 1.x, which is obsolete. You should be reading http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/Proxy . Unfortunately, I cannot use TLS. I have to use SSL. Also, I would rather not duplicate the certificates for the IMAP servers. Hence nginx doesn't seem to be a good choice either. I am hoping that since SSL has Client Hello which specifies the site requested the the following could be done: Client - Proxy [SYN] Proxy - Client [SYN, ACK] Client - Proxy [ACK] Client - Proxy [SSL With Client Hello, having server_name in Extension: server_name and sub-fields] Do you have any evidence that common IMAP clients support sending SNI? I've just checked, and mutt (for example) appears not to. Proxy sees intended host Proxy - Intended Server [SYN/SYN+ACK/ACK sequence] Proxy - Intended Server [Replay SSL/Client Hello] Client - Proxy - Intended Server (Proxy is non decrypting Man-in-the-Middle, just acting as a pseudo-invisible relay) I know that something somewhat like this works because this is how Apache can do virtual hosts with SSL. Of course, it acts as the end point intended server, not a proxy. I believe it is also somewhat how Squid does SSL proxying, although I could be entirely wrong. More importantly, it only works with clients (browsers) which are new enough to send SNI. If you use, for instance, any version of IE on Windows XP, it will not work. Is this possible? Can this be implemented in dovecot? I don't believe so. If not, does anyone know of such a project. Proxy needs to not have any exploitable holes and really only needs to understand enough SSL to get the server_name, pass through the connection, replaying Client Hello, and then knowing when to shut the connection. Just as a breif example, the use I have for this now is that I have several imap servers which all have IPv6 addresses, but have to share an IPv4 address. for SMTP side of things, this works well for all incoming email. (As an aside, does anyone know of a similar setup for SSL traffic on port 465 SSL for SMTP?) Similarly, I doubt this is possible for SMTP either, since the clients probably won't send SNI. Ben Thank you Ben and Noel for your responses! I know Thunderbird on Linux sends it. Right now my targets would be Thunderbird, K9 Mail and Android Mail on Android, and Apple Mail and whatever the equivalent is on iOS. I will investigate K9 and Android later (as I have access to those). I do not have access to the Apple ones at the moment. K-9 on my Droid X2 does not support SNI. Trever
Re: [Dovecot] dovecot not logging after upgrade to 2.1.7 on debian
On 05/09/2013 02:02 PM Steinar Bang wrote:
After upgrading my IMAP server to the new debian stable, and upgrading
dovecot from 1.x to 2.1.7 in the process, dovecot no longer logs
anything to /var/log/mail.*. The last entries there are from before the
upgrade, and no starts or error messages or failed login attempts, since
then, have been logged.
Did you read /usr/share/doc/dovecot-core/{NEWS,README}.Debian.gz?
Does anyone know what might cause this?
doveconf -n doesn't mention any of the log settings. Maybe the log
settings aren't picked up? What could be done to make sure they are
picked up?
,--[ doveconf(1) ]--
| OPTIONS
| -n Show only settings with non-default values.
`--
Here's the content of the /etc/dovecot/conf.d/10-logging.conf file:
…
Please don't copy and paste stuff from files in Dovecot's configuration
directory. Always provide the output generated by `doveconf -n`.
,--[ doveadm-log(1) ]--
| COMMANDS
|log find
|doveadm log find [directory]
|
|The log find command is used to show the location of the log files,
to which dovecot(1) sends its log messages. If dovecot(1) logs its messages
through syslogd(8) and doveadm(1) could not find any
|log files, you can specify the directory where your syslogd writes its
log files.
`--
Regards,
Pascal
--
The trapper recommends today: c01dcofe.1312...@localdomain.org
Re: [Dovecot] dovecot not logging after upgrade to 2.1.7 on debian
Steinar Bang s...@dod.no: Could the culprit be the syslogd? Could the syslogd have gone AWOL during the debian upgrade? That's a point of investigation, at least... Indeed... rainey:~# dpkg -S /etc/syslog.conf sysklogd: /etc/syslog.conf rainey:~# dpkg -l sysklogd Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersionArchitecture Description +++-===-==-==- rc sysklogd1.5-6 i386 System Logging Daemon http://packages.debian.org/squeeze/sysklogd Exists for squeeze and sid, but not for wheezy. The preferred syslogd for debian is now rsyslog: http://wiki.debian.org/Rsyslog apt-get install rsyslog pulled the new syslogd in, and now doveadm log find reports meaningful values: rainey:~# doveadm log find Looking for log files from /var/log Debug: /var/log/mail.log Debug: /var/log/syslog Info: /var/log/mail.log Info: /var/log/syslog Info: /var/log/mail.info Warning: /var/log/mail.log Warning: /var/log/mail.warn Warning: /var/log/syslog Warning: /var/log/mail.info Error: /var/log/mail.log Error: /var/log/mail.warn Error: /var/log/mail.err Error: /var/log/syslog Error: /var/log/mail.info Fatal: /var/log/mail.log Fatal: /var/log/mail.warn Fatal: /var/log/mail.err Fatal: /var/log/syslog Fatal: /var/log/mail.info
[Dovecot] Released Pigeonhole v0.3.5 for Dovecot v2.1.16
Hello Dovecot users, Before I release the first version of Pigeonhole v0.4, I quickly release a few small but important fixes for Pigeonhole v0.3. Changelog v0.3.5: - Sieve editheader extension: fixed interaction with the Sieve body extension. If used together, the deleteheader action could fail after a body test was performed. - Test suite: fixed a time zone dependency in the Sieve date extension tests. The release is available as follows: http://www.rename-it.nl/dovecot/2.1/dovecot-2.1-pigeonhole-0.3.5.tar.gz http://www.rename-it.nl/dovecot/2.1/dovecot-2.1-pigeonhole-0.3.5.tar.gz.sig Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this new release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch step...@rename-it.nl
Re: [Dovecot] change inbox dotlock name
Axel Luttgens axelluttg...@swing.be wrote: But I fear I don't understand your problem description. Could you elaborate? Hi Axel, The issue is that the procmail port on FreeBSD doesn't acquire a dotlock when it's the default lock file (/var/mail/username.lock). It prints that it's bypassing the dotlock and just does a lockf() lock after. Looking in the code for procmail, it seems that it's being too clever with a bunch of checks and so it doesn't try to get the lock -- it's decided it doesn't want to before doing it. The permissions and runtime environment permit the lock, and the same lock is acquired correctly by dovecot when writing to the inbox. I'm doing dotlock and then lockf() locking in all the mail software. procmail's checks only seem to apply to the default lock file for the inbox. If I specify an alternate name in the .procmailrc for the $ORGMAIL delivery of the message, then it will acquire any other lock I ask, including an alternate name in the /var/mail directory. I'll dig into the procmail sources as needed to resolve it, but I had hoped that I could get dovecot to lock with a different filename, because that would resolve the issue with minimal hackery... Cheers, Chris -- Chris Saldanha Parliant Corporation
Re: [Dovecot] dovecot not logging after upgrade to 2.1.7 on debian
Am 09.05.2013 16:11, schrieb Steinar Bang: Could the culprit be the syslogd? Could the syslogd have gone AWOL during the debian upgrade? That's a point of investigation, at least... Indeed... http://packages.debian.org/squeeze/sysklogd Exists for squeeze and sid, but not for wheezy. The preferred syslogd for debian is now rsyslog: http://wiki.debian.org/Rsyslog apt-get install rsyslog pulled the new syslogd in, and now doveadm log find reports meaningful values and deb-packages does not support Obsoletes/Provides like RPM or only the packager too stupid not break upgrades? signature.asc Description: OpenPGP digital signature
[Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
Hello Dovecot users, I finally release the first version of Pigeonhole v0.4 for Dovecot v2.2. The main reason for the delay was that some unexpected (design) problems occurred with the new doveadm-sieve plugin, which allows synchronizing sieve scripts using doveadm sync. One important change is that I incorporated the extprograms plugin into the main Pigeonhole release. With this plugin it is possible to execute administrator-controlled external programs (shell scripts) from the Sieve interpreter, e.g. for special message delivery, filtering and string manipulation. The list of new features is not that impressive. I've been working on IMAP URLAUTH, IMAP CATENATE and HTTP support for Dovecot. Currently, I'm building an SMTP submission proxy server. After all that I plan to spend more time on Sieve development. One of the most important issues on my list is implementing support for using alternative types of storage (e.g. a database) for Sieve scripts, rather than only a filesystem directory as it is now. Changelog v0.4.0: + Added doveadm-sieve plugin that provides the possibility to sync Sieve scripts using doveadm sync along with the user's mailboxes. + Added the Sieve extprograms plugin to the main Pigeonhole package. It is still a plugin, but it is now included so that a separate compile is no longer necessary and distributors are likely to include it. The extprograms plugin provides Sieve language extensions that allows executing (administrator-controlled) external programs for message delivery, message filtering and string manipulation. Refer to doc/plugins/sieve_extprograms.txt for more information. + Added debug message showing Pigeonhole version at initialization. Makes it very clear that the plugin is properly loaded. + Finished implementation of the Sieve include extension. It should now fully conform to RFC 6609. The main addition is the new :optional tag which makes the include command ignore missing included scripts without an error. + Finished implementation of the Sieve environment extension as much as possible. Environment items location, phase and domain now also return a usable value. The release is available as follows: http://www.rename-it.nl/dovecot/2.2/dovecot-2.2-pigeonhole-0.4.0.tar.gz http://www.rename-it.nl/dovecot/2.2/dovecot-2.2-pigeonhole-0.4.0.tar.gz.sig Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this new release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch step...@rename-it.nl
Re: [Dovecot] dovecot not logging after upgrade to 2.1.7 on debian
Reindl Harald h.rei...@thelounge.net: and deb-packages does not support Obsoletes/Provides like RPM or only the packager too stupid not break upgrades? There isn't an obsolete-concept, AFAIK. But there is a way to handle upgrades that switch implementations, through a mechanism called virtual packages. Why that wasn't done here, I don't know. Perhaps it was overlooked.
Re: [Dovecot] dovecot not logging after upgrade to 2.1.7 on debian
On 5/9/2013 9:11 AM, Steinar Bang wrote: The preferred syslogd for debian is now rsyslog: http://wiki.debian.org/Rsyslog Did you happen to notice that rsyslog became the default syslog daemon with the release of Lenny? That was Feb 14, 2009, over 4 years ago. Your system went through 3 distribution upgrades before you noticed. There was no syslog virtual or metapackage. The Lenny upgrade release notes had instructions for manually replacing syslogd with rsyslog. It could not be done automatically. I guess you missed this with Lenny, and Debian assumed everyone did it, omitting this from subsequent release notes. -- Stan
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 2013-05-09 10:35 AM, Stephan Bosch step...@rename-it.nl wrote: Hello Dovecot users, I finally release the first version of Pigeonhole v0.4 for Dovecot v2.2. Yay! Thanks so much Stephan. One question though... Currently, I'm building an SMTP submission proxy server. Can you elaborate on this? Does this mean for example, that we could use dovecot as our submission server and auto-save-to-sent, avoiding the overhead of the 'Copy to Sent' behavior we are currently forced to use where a message is first uploaded when it is sent, then again when it is saved to the sent folder? This would be awesome, as we deal with a lot of large attachments, and when people are working from home, it can take many many seconds (even a minute or so for very large attachments depending on their internet connection speed) to send, and then it has to do it all over again to save to sent. Thanks again! -- Best regards, Charles
[Dovecot] Crossrealm Kerberos problems
I am running dovecot 2.1.7 on Debian Squeeze 64 bit, config information
at the end of the email.
I am working on a Kerberos/GSSAPI based setup that requires cross-realm
authentication. I have regular GSSAPI working, I can log in using
pam_krb5 with password based logins or with the GSSAPI support when
using a kerberos ticket in the default realm.
However when I attempt to authenticate using cross realm authentication
the login fails (logs below).
After perusing the source code I beleive that the problem is as such:
All taking place in mech-gssapi.c
1. mech_gssapi_userok(...) calls mech_gssapi_krb5_userok
2. mech_gssapi_krb5_userok(...) calls krb5_kuserok(...) to verify that
the given Kerberos prinicpal can log in as the requested user.
3. The authentication process is running as the Dovecot user so:
3a. krb5_kuserok(...) looks for ~dovecot/.k5login to authorize cross
realm logins
3b. There is no ~dovecot/.k5login, thus no cross realm access is allowed
3c. It should be looking at the users .k5login ~poptest/.k5login
3d. This never happens and the login attempt fails
I have the server set up to use system users specifically so that I can
do cross-realm authentication.
Do I have some basic configuration error? How do I change the
authentication process to run as the user requesting to login? Should
that be allowed?
Another thought is to backport some of the patches proposed for 2.2 that
remove krb5_kuserok from the loop.
Thank you for any insight. This server is not in production use so I
can experiment.
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
gssapi(jonathan.hanks@SOME.REALM,198.129.xxx.xxx,qYAkv0zc9wDGgdAT):
Negotiated security layer
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
gssapi(jonathan.hanks@SOME.REALM,198.129.xxx.xxx,qYAkv0zc9wDGgdAT):
Negotiated security layer
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client out: CONT#0111#011BQQF/wAMCpxNKQH///+YdY3lGMDBq6TWTfc=
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client out: CONT#0111#011BQQF/wAMCpxNKQH///+YdY3lGMDBq6TWTfc=
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client in: CONThidden
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth: Debug:
client in: CONThidden
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth:
gssapi(jonathan.hanks@SOME.REALM,198.129.xxx.xxx,qYAkv0zc9wDGgdAT):
User not authorized to log in as poptest
May 9 10:54:49 lakeview.ligo-wa.caltech.edu dovecot: auth:
gssapi(jonathan.hanks@SOME.REALM,198.129.xxx.xxx,qYAkv0zc9wDGgdAT):
User not authorized to log in as poptest
My config is as follows:
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.7
auth_debug = yes
auth_gssapi_hostname = $ALL
auth_krb5_keytab = /etc/mail.keytab
auth_mechanisms = plain login gssapi
auth_username_format = %u
auth_verbose = yes
listen = *
mail_location = mbox:~/mail:INBOX=/var/spool/mail/inbox/%u
mail_privileged_group = mail
passdb {
args = dovecot
driver = pam
}
protocols = imap pop3
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
unix_listener auth-userdb {
mode = 0666
}
}
service imap-login {
inet_listener imap {
port = 0
}
inet_listener imaps {
port = 993
ssl = yes
}
}
service pop3-login {
inet_listener pop3 {
port = 0
}
inet_listener pop3s {
port = 995
ssl = yes
}
}
ssl_cert = /etc/ssl/certs/mail-server.pem
ssl_cipher_list = !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL
ssl_key = /etc/ssl/private/mail-server.pem
userdb {
driver = passwd
}
protocol imap {
imap_client_workarounds = tb-extra-mailbox-sep tb-lsub-flags
}
protocol pop3 {
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
pop3_uidl_format = %08Xu%08Xv
}
--
Jonathan Hanks
General Computing Sys Admin
LIGO Hanford Observatory
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/9/2013 6:05 PM, Charles Marcus wrote: On 2013-05-09 10:35 AM, Stephan Bosch step...@rename-it.nl wrote: Currently, I'm building an SMTP submission proxy server. Can you elaborate on this? It basically acts as a front-end to your normal MTA. First of all, it provides a convenient way to add SMTP AUTH support to any MTA. But the main goal for this project is to implement an SMTP submission server with full support for the LEMONADE profile (https://tools.ietf.org/html/rfc4550). It acts as a proxy server, so it doesn't queue anything; once the client sees a success reply for the message submission, it is already accepted in the actual MTA queue. For authentication it uses the normal Dovecot login strategy. This means that after authentication, it can run with the user's privileges and access the user's mail storage directly. However, I also plan to provide support for running it as a completely unprivileged service. Does this mean for example, that we could use dovecot as our submission server ... Yes. ... and auto-save-to-sent, avoiding the overhead of the 'Copy to Sent' behavior we are currently forced to use where a message is first uploaded when it is sent, then again when it is saved to the sent folder? Depends a bit on what you have in mind. The LEMONADE profile has a forward-without-download scheme for this, using the SMTP BURL extension (https://tools.ietf.org/html/rfc4468) and IMAP CATENATE (https://tools.ietf.org/html/rfc4469) and URLAUTH (https://tools.ietf.org/html/rfc4467). Using CATENATE, the client can combine existing message parts with new text to compose a new message. Using SMTP BURL and IMAP URLAUTH, the SMTP server can access that message directly from the IMAP server without the need for the client to download it first. Some more direct approach is also possible, e.g. let the submission server store the message in the Sent folder implicitly (as Google apparently does). This has a few problems though, mainly that the mail client will have to be configured correctly not to store an additional copy of its own. Unfortunately, there is no standardized method of signalling this from server to client. Google probably filters out the duplicates, we don't really know. Also, which folder does the user use as Sent folder? We could use the IMAP SPECIAL-USE (https://www.ietf.org/rfc/rfc6154.txt) extension to find out. Anyway, adding support for implicitly storing sent messages in the \Sent folder should be easy enough, but it is not a fool-proof solution. Timo was discussing this a while back on the SMTP mailinglist, but people there weren't too enthusiastic about standardizing a feature like this so far. This would be awesome, as we deal with a lot of large attachments, and when people are working from home, it can take many many seconds (even a minute or so for very large attachments depending on their internet connection speed) to send, and then it has to do it all over again to save to sent. The LEMONADE profile is rather elaborate and not many clients or servers support it yet. I'm hoping that by providing a chicken, more eggs will follow soon. To provide some sort of solution for the short term, I guess I'll just add an optional auto-save-to-sent feature. When the submission service has direct access to the user's mail storage, that is trivial to implement. However, if the submission service is unprivileged, that will be a little more difficult. Probably, in that case I'll make it use a special support service to perform the actual delivery to the sent folder. Any suggestions are welcome. Regards, Stephan.
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 10.5.2013, at 0.23, Stephan Bosch step...@rename-it.nl wrote: Anyway, adding support for implicitly storing sent messages in the \Sent folder should be easy enough, but it is not a fool-proof solution. Timo was discussing this a while back on the SMTP mailinglist, but people there weren't too enthusiastic about standardizing a feature like this so far. I was thinking about continuing that after we have implemented something. It seems that the best idea really was the one I had in the beginning and Alexey also suggested: 250 2.0.0 [localcopy] Message accepted Very IMAP-like instead of SMTP-like, but .. well, it's a very IMAP-specific feature in any case (until IMAP replacement protocol comes some day).
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/9/2013 11:35 PM, Timo Sirainen wrote: On 10.5.2013, at 0.23, Stephan Bosch step...@rename-it.nl wrote: Anyway, adding support for implicitly storing sent messages in the \Sent folder should be easy enough, but it is not a fool-proof solution. Timo was discussing this a while back on the SMTP mailinglist, but people there weren't too enthusiastic about standardizing a feature like this so far. I was thinking about continuing that after we have implemented something. Yeah, good idea. My patch queue (hg mq) is here: http://hg.rename-it.nl/dovecot-2.2-patches/ The toplevel submission.patch also updates the Dovecot TODO file, so you can look there for what remains to be done. The auto-save-to-sent feature is not mentioned there yet. It seems that the best idea really was the one I had in the beginning and Alexey also suggested: 250 2.0.0 [localcopy] Message accepted Very IMAP-like instead of SMTP-like, but .. well, it's a very IMAP-specific feature in any case (until IMAP replacement protocol comes some day). ManageSieve uses this textual response-code style as well. :) Some SMTP replies already have a somewhat structured text part, e.g. a domain name as the first word, or an optional mailbox specification enclosed in '' and ''. So, I don't think it would be completely strange to put it there. Regards, Stephan.
