Re: Missing processes
Hi, On Fri, Dec 04, 2015 at 01:14:46AM +0100, Ervin Hegedüs wrote: > > but there isn't any imap nor pop3 process: > > # ps ax | grep dovecot > 23723 ?Ss 0:00 /usr/sbin/dovecot -F > 23732 ?S 0:00 dovecot/anvil > 23733 ?S 0:00 dovecot/log > 23735 ?S 0:00 dovecot/config so, I'm so sorry, that was my mistake - possible I was wrong in something, and Dovecot didn't listened on 110 and 443, so I couldn't connect to 110/443 ports. I've looked up the imap processes, as runs on one of my other server. Now I've cleaned up my config, and everything is fine. Sorry again, regards, a. -- I � UTF-8
Missing processes
Hi list, I'm new on dovecot mailing list, this is my second dovecot installation. I'm using Debian 8, dovecot packages cames from repository. I'm using it with Postfix - postfix uses dovecot as virtual transport. Looks like everything is fine: dovecot starts, and I see this line in syslog: Dec 4 00:57:04 myserver dovecot: master: Dovecot v2.2.13 starting up for imap, lmtp, pop3 (core dumps disabled) but there isn't any imap nor pop3 process: # ps ax | grep dovecot 23723 ?Ss 0:00 /usr/sbin/dovecot -F 23732 ?S 0:00 dovecot/anvil 23733 ?S 0:00 dovecot/log 23735 ?S 0:00 dovecot/config In logs, there isn't any relevant info. If I send a mail to Postfix, it uses dovecot/auth, ant it starts _only_when_ postfix used it: # ps ax | grep dovecot 23723 ?Ss 0:00 /usr/sbin/dovecot -F 23732 ?S 0:00 dovecot/anvil 23733 ?S 0:00 dovecot/log 23735 ?S 0:00 dovecot/config 25049 ?S 0:00 dovecot/lmtp 25050 ?S 0:00 dovecot/auth 25052 ?S 0:00 dovecot/auth -w But there still isn't the dovecot/imap... Why? Thanks, a. -- I � UTF-8
Re: Interpreting keywords
2015. 12. 2, szerda keltezéssel 13.39-kor Mark Foley ezt írta: > I assume these "$label" values are macros that possibly refer to "Important", > "Work", etc., but > where are these $label's defined? Are they defined in the dovecot configs > somewhere or does the > mail client just "know" what these correspond to? This is because of pre 2.0 Thunderbird versions used labes. Thunderbird kept this for compatibility reasons. I think they are stored in the user's prefs.js. Dovecot stores the sring received from the client. -- Üdvözlettel Stefán Tamás - domain > email > web >>> siker Numex Informatika Kft. Mobil: +36 20 956 0233, Tel: +36 1 205 3915, Fax: +36 1 203 6037 http://numex.hu
Re: How do we disable LOGIN-REFERRALS? (part 2)
Please amend the first paragraphs of PasswordDatabase.ExtraFields.Host.txt as follows. ---cut here--- Login referrals are a server-side IMAP4 extension specified by RFC 2221. Their purpose is to redirect clients to an different IMAP4 server in case of hardware failures or organizational changes. No client action is needed to invoke the LOGIN-REFERRALS capability: the redirection is triggered by the server and occurs transparently. A security consideration is in order. As also stated by RFC 2221, a man in the middle attack may use a rogue 'password catching' server to collect login data and redirect your clients to their own rogue IMAP4 server. Login referrals are not supported by many clients, so you probably don't want to use them anyway. Dovecot does not use login referrals by default. [It would be useful at this point if you could add one sentence explaining the purpose of the LOGIN-REFERRALS in the default capabilities banner.] If you need them, please follow the instructions below. ---cut here--- Thank you.
Re: How do we disable LOGIN-REFERRALS? (part 2)
> On 03 Dec 2015, at 17:20, sb wrote: > > On 12/3/15 2:49 PM, Timo Sirainen wrote: > >> There is no code that can be disabled on Dovecot side. >> I think you need to read how LOGIN-REFERRALs actually work. > > This is an excerpt from the RFC: > >> A home server referral may be returned in response to an AUTHENTICATE >> or LOGIN command, or it may appear in the connection startup banner. >> If a server returns a home server referral in a tagged NO response, >> that server does not contain any mailboxes that are accessible to the >> user. If a server returns a home server referral in a tagged OK >> response, it indicates that the user's personal mailboxes are >> elsewhere, but the server contains public mailboxes which are >> readable by the user. After receiving a home server referral, the >> client can not make any assumptions as to whether this was a >> permanent or temporary move of the user. > The client and the server exchange relevant messages. Client doesn't send anything to Dovecot regarding the use of LOGIN-REFERRALS. It simply does a regular authentication and if Dovecot is configured to send a login-referral then Dovecot responds so to the LOGIN or AUTHENTICATE command. The client can't request a referral in any way. > If dovecot cannot disable > the relevant code then either dovecot does not implement the RFC or it does it > so well that it cannot be disabled without rewriting dovecot's code. In > either case, > we want to disable LOGIN-REFERRAL, and have evidence that it has been > disabled. > Removing the keyword from the banner is not sufficient, and the documentation > PasswordDatabase.ExtraFields.Host.txt is far from useful. Dovecot never sends a login referral unless you have explicitly configured passdb to send it. There are no commands, requests or anything related to LOGIN-REFERRALS that can be sent by IMAP client to Dovecot. If you haven't configured a passdb to return a host field, there is zero code that can ever be executed that is in any way related to LOGIN-REFERRALS.
Re: How do we disable LOGIN-REFERRALS? (part 2)
On 12/3/15 2:49 PM, Timo Sirainen wrote: There is no code that can be disabled on Dovecot side. I think you need to read how LOGIN-REFERRALs actually work. This is an excerpt from the RFC: A home server referral may be returned in response to an AUTHENTICATE or LOGIN command, or it may appear in the connection startup banner. If a server returns a home server referral in a tagged NO response, that server does not contain any mailboxes that are accessible to the user. If a server returns a home server referral in a tagged OK response, it indicates that the user's personal mailboxes are elsewhere, but the server contains public mailboxes which are readable by the user. After receiving a home server referral, the client can not make any assumptions as to whether this was a permanent or temporary move of the user. The client and the server exchange relevant messages. If dovecot cannot disable the relevant code then either dovecot does not implement the RFC or it does it so well that it cannot be disabled without rewriting dovecot's code. In either case, we want to disable LOGIN-REFERRAL, and have evidence that it has been disabled. Removing the keyword from the banner is not sufficient, and the documentation PasswordDatabase.ExtraFields.Host.txt is far from useful.
Re: [Dovecot-news] v2.2.20 release candidate released
* Timo Sirainen 2015.12.03 15:27:
> protocol imap {
> namespace inbox {
> mailbox Trash {
> autoexpunge = 5 days
> }
> }
> }
Thanks.
signature.asc
Description: Digital signature
Re: [Dovecot-news] v2.2.20 release candidate released
> On 03 Dec 2015, at 16:09, Thomas Leuxner wrote:
>
> * Timo Sirainen 2015.12.03 14:51:
>
>> + Added mailbox { autoexpunge= } setting. See
>> http://wiki2.dovecot.org/MailboxSettings for details.
>
> namespace inbox {
> mailbox Trash {
>autoexpunge = 5 days
>special_use = \Trash
> }
> }
>
> I'm using autoexpunge on the Trash mailbox. Looking at the wiki text I'm
> unclear on how to limit it to a specific service:
>
>> So it may be better to explicitly enable this only inside protocol imap,
>> pop3 and maybe lmtp.
namespace inbox {
mailbox Trash {
special_use = \Trash
}
}
protocol imap {
namespace inbox {
mailbox Trash {
autoexpunge = 5 days
}
}
}
If you want it for other protocols, you'll unfortunately have to just
copy&paste the entire block.
Re: [Dovecot-news] v2.2.20 release candidate released
* Timo Sirainen 2015.12.03 14:51:
> + Added mailbox { autoexpunge= } setting. See
>http://wiki2.dovecot.org/MailboxSettings for details.
namespace inbox {
mailbox Trash {
autoexpunge = 5 days
special_use = \Trash
}
}
I'm using autoexpunge on the Trash mailbox. Looking at the wiki text I'm
unclear on how to limit it to a specific service:
>So it may be better to explicitly enable this only inside protocol imap, pop3
>and maybe lmtp.
Regards
Thomas
signature.asc
Description: Digital signature
v2.2.20 release candidate released
http://dovecot.org/releases/2.2/rc/dovecot-2.2.20.rc1.tar.gz
http://dovecot.org/releases/2.2/rc/dovecot-2.2.20.rc1.tar.gz.sig
v2.2.20 probably will be released tomorrow or maybe during weekend.
+ Added mailbox { autoexpunge= } setting. See
http://wiki2.dovecot.org/MailboxSettings for details.
+ ssl_options: Added support for no_ticket
+ imap/pop3/managesieve-login: Added postlogin_socket=path passdb extra
field. This allows replacing the default service
imap/pop3/managesieve {} settings for specific users (e.g. running
their imap process via valgrind or strace).
+ doveadm fetch: Added date.sent/received/saved.unixtime
+ fs-posix: Added mode=auto parameter to set the created files' and
directories' mode based on the parent dir if it has setgid-bit.
+ director: Support backends having hostnames, which makes it possible
to verify their SSL certificates.
- director: Directors' state became desynchronized if doveadm director
commands were used to modify the same backend in multiple directors
at the same time with conflicting changes. This fix includes some
extra checks, which makes sure that if such a conflict still happens
it's automatically fixed. In some situations such an automatic fix
may now be unnecessarily triggered and an error logged.
- director: Backend tags weren't working correctly.
- ldap: tls_* settings weren't used for ldaps URIs.
- ldap, mysql: Fixed setting connect timeout.
- auth: userdb lookups via auth-worker couldn't change username
- dsync: Fixed handling deleted directories. Make sure we don't go to
infinite mailbox renaming loop.
- imap: Fixed crash in NOTIFY when there were watched namespaces that
didn't support NOTIFY.
- imap: After SETMETADATA was used, various commands (especially FETCH)
could have started hanging when their output was large.
- stats: Idle sessions weren't refreshed often enough, causing stats
process to forget them and log errors about unknown sessions when
they were updated later.
- stats: Fixed "Duplicate session ID" errors when LMTP delivered to
multiple recipients and fts_autoindex=yes.
- zlib plugin: Fixed copying causing cache corruption when zlib_save
wasn't set, but the source message was compressed.
- fts-solr: Fixed escaping Solr query parameters.
Re: How do we disable LOGIN-REFERRALS? (part 2)
On 03 Dec 2015, at 15:17, sb wrote: > > On 12/3/15 1:32 PM, Timo Sirainen wrote: >> As long as Dovecot doesn't return any login-referrals (which it doesn't >> by default), I don't see why having LOGIN-REFERRALS in the CAPABILITY >> reply would matter. > Because a compatible client will use the capability as advertised by the > server, > and then fail because the server is not honouring its promise. > > One can hide the capability in the banner, but also wants to disable its > engine. > You say that dovecot has it disabled by default, but I have no evidence of > it, yet. I think you need to read how LOGIN-REFERRALs actually work. There is no code that can be disabled on Dovecot side.
Re: How do we disable LOGIN-REFERRALS? (part 2)
On 12/3/15 1:32 PM, Timo Sirainen wrote: As long as Dovecot doesn't return any login-referrals (which it doesn't by default), I don't see why having LOGIN-REFERRALS in the CAPABILITY reply would matter. Because a compatible client will use the capability as advertised by the server, and then fail because the server is not honouring its promise. One can hide the capability in the banner, but also wants to disable its engine. You say that dovecot has it disabled by default, but I have no evidence of it, yet.
Re: How do we disable LOGIN-REFERRALS? (part 2)
On 12/03/2015 01:46 PM, sb wrote: > From /opt/src/dovecot-2.2.19/doc/wiki/PasswordDatabase.ExtraFields.Host.txt >> Login referrals are an IMAP extension specified by RFC 2221 >> [http://www.apps.ietf.org/rfc/rfc2221.html]. They're not supported by >> many >> clients, so you probably don't want to use them normally. > Right. >> The following clients are known to support login referrals: >> >> * Pine >> * Outlook (but not Outlook Express) > We use neither. >> Login referrals are used only if the proxy field isn't set. > We want neither LOGIN-REFERRALS nor proxy. > > Dovecot's configure includes the following by default: >> capability_banner="IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID >> ENABLE IDLE" > If the extension is simply hidden from the banner, an attacker could > still use the extension. If the connection is SSL/TLS encrypted, the attacker can't add/modify login referrals. If it's not encrypted, the attacker could just as well insert the LOGIN-REFERRALS to the CAPABILITY reply if it didn't exist there. > If one removes the string from the banner above, one merely hides the > extension name > in the banner, or also disables the extension's engine? As long as Dovecot doesn't return any login-referrals (which it doesn't by default), I don't see why having LOGIN-REFERRALS in the CAPABILITY reply would matter.
Re: How do we disable LOGIN-REFERRALS? (part 2)
From /opt/src/dovecot-2.2.19/doc/wiki/PasswordDatabase.ExtraFields.Host.txt Login referrals are an IMAP extension specified by RFC 2221 [http://www.apps.ietf.org/rfc/rfc2221.html]. They're not supported by many clients, so you probably don't want to use them normally. Right. The following clients are known to support login referrals: * Pine * Outlook (but not Outlook Express) We use neither. Login referrals are used only if the proxy field isn't set. We want neither LOGIN-REFERRALS nor proxy. Dovecot's configure includes the following by default: capability_banner="IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE" If the extension is simply hidden from the banner, an attacker could still use the extension. If one removes the string from the banner above, one merely hides the extension name in the banner, or also disables the extension's engine?
How do we disable LOGIN-REFERRALS?
Network Working Group M. Gahrns Request for Comments: 2221 Microsoft Category: Standards Track October 1997 IMAP4 Login Referrals ... 6. Security Considerations The IMAP4 login referral mechanism makes use of IMAP URLs, and as such, have the same security considerations as general internet URLs [RFC-1738], and in particular IMAP URLs [IMAP-URL]. A server MUST NOT give a login referral if authentication for that user fails. This is to avoid revealing information about the user's account to an unauthorized user. With the LOGIN-REFERRALS capability, it is potentially easier to write a rogue 'password catching' server that collects login data and then refers the client to their actual IMAP4 server. Although referrals reduce the effort to write such a server, the referral response makes detection of the intrusion easier.
Re: [patch] Fix for bug in TLS/SSL for LMTP with chained certificates
On 02 Dec 2015, at 17:38, NederHost/Sebastiaan Hoogeveen wrote: > > Hi, > > In case of tl;dr: I fixed a bug in TLS support for LMTP which caused chained > certificates not to work, and another one which caused certificate read > errors to be ignored; the patches are attached to this email. > > While testing LMTP with TLS and certificate verification by Postfix I > discovered that certificate chains are not exchanged properly when using > LMTP, even though everything works fine for POP3 and IMAP (both with or > without STARTTLS). On LMTP only the server certificate is included in the TLS > handshake, no intermediate certificates are provided by the server. > > The first problem I fixed is that in > lib-ssl-iostream/iostream-openssl-context.c errors from the > ssl_ctx_use_certificate_chain function are silently ignored because the > function returns 0 for a failure but the caller checks for values smaller > than 0. This problem is fixed in the tiny patch > dovecot-2.2.19-ssl_ctx_certificate_chain_returnvalue.diff. Applied. > After applying this patch the following error message appears in the logs for > LMTP only (IMAP and POP3 still work fine): > > dovecot: lmtp(20683): Error: SSL context initialization failed, disabling > SSL: Can't load SSL certificate: error:0608308E:digital envelope > routines:EVP_PKEY_get1_EC_KEY:expecting a ec key > > It turns out this issue is not related to the reading of the certificate or > its associated chain. Somewhere before ssl_ctx_use_certificate_chain is > called an error is put in the OpenSSL error queue which is never retrieved. > Only after loading the server certificate is the queue checked and because of > the previously existing error the chain is not loaded. I think the error is > related to setting specific protocol options in ssl_iostream_context_set > (which may be different for LMTP than for IMAP or POP3) but I did not > investigate this. http://hg.dovecot.org/dovecot-2.2/rev/302c3c7e11f8 should fix it. > I made the problem go away by making the following two changes: > > 1. The ssl_ctx_use_certificate_chain function now empties the OpenSSL error > queue before doing its work by calling ERR_get_error() until the queue is > empty. > > 2. The openssl_iostream_error function in a similar fashion empties the queue > and returns only the error message for the most recent error (this prevent > earlier errors from 'hiding' later/more relevant ones). > > After applying this second patch LMTP now works properly with certificate > chains. Note that this patch makes previously unhandled errors simply > 'disappear' from the queue, which may be a Very Bad Thing. I guess there is a > more elegant way of handling this "queued error" issue but this works for me > now and I'm actually not a C programmer. These two fixes are included in > dovecot-2.2.19-lmtp_ssl_bug.diff. I changed this to work the same in lib-ssl-iostream as it works in login-common/ssl-proxy-openssl.c (I wonder why it didn't originally work the same way..) and also merged more of the error handling code in login-common and lib-ssl-iostream.
Re: Dovecot doesn't sent rejection message user overquota
Il 02/12/2015 15:49, Marcus Rueckert ha scritto: On 2015-12-02 09:13:04 +0100, Antonello Cioffi wrote: Dec 2 08:58:49 posta2 dovecot: lda(antonen): msgid=<565ea4b9.1020...@uniparthenope.it>: Permanently failed to send rejection: smtp(mail.uniparthenope.it): DATA failed: 550 5.7.1 no third-party DSNs smells like an error message from your smtp server. I solved: it's a very very old header_checks rule in postfix configuration that I use some times ago to stop some kind of spam and i've forgive it Dec 3 10:28:19 posta2 postfix/cleanup[31760]: 3CC8611C049: reject: header Content-Type: multipart/report; report-type=delivery-status;??boundary="32191/mail.uniparthenope.it" from localhost[127.0.0.1]; from=<> to= proto=ESMTP helo=: 5.7.1 no third-party DSNs thanks for your help bye -- Dott. Antonello Cioffi Ufficio Servizi Informatici Università degli Studi di Napoli Parthenope Tel. 081/5475292 - Fax. 081/5475180
Re: CentOS rpm dovecot 2.2.10 auth/db-ldap.c TLS bug/patch
On Tue, Dec 1, 2015 at 5:51 PM, Timo Sirainen wrote: > On 25 Nov 2015, at 15:42, Andrey Fesenko wrote: >> >> Hello, >> CentOS rpm dovecot 2.2.10 сontains bug auth/db-ldap.c TLS (not connect >> LDAP+TLS server ldaps://), exist bug/patch >> https://bugs.centos.org/view.php?id=8267 >> >> As far as the correct patch in upstream dovecot quite a lot of changes >> at this point if there is a correct patch? > > http://hg.dovecot.org/dovecot-2.2/rev/727acba74cbf > Thanks this work too, It needs some work though, since the original version are different (hg and rpm dovecot source version)
