[Dovecot] Dovecot MTA
Hi all,
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of time to be able to create something that was anywhere even close to having Postfix's features. (I would shudder to even think about recreating Dovecot from scratch nowadays.) But slowly over time I've also been thinking of ways how things could be done a bit better, and I think I have enough ideas to start thinking about Dovecot MTA more seriously in a few more months (after my current busy schedule calms down a bit). And (unlike Dovecot!) I'm not planning on taking over the world with the MTA (or at least not very quickly), but it would definitely be useful for many installations I know of.
My main design goals for the MTA are:
In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections.
In some cases you can't really avoid placing mails into a queue. This could be because of temporary failures or maybe because of an abnormal load spike. A mail queue in local disk isn't very nice though, because if the local disk dies, the queued mails are lost. Dovecot MTA will allow the queue to be in object storage and it will also likely support replication (similar to current dsync replication). In both of these cases if a server dies, another server can quickly take over its queue and continue handling it.
Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not:
- Require DKIM configuration. All outgoing mails will be DKIM signed.
- Require the domain’s DNS to contain _submission._tcp SRV record (and actually might as well require _imap._tcp too)
- Require SSL certificates to be configured and always allow remote to use STARTTLS
- Require DANE TLSA record to exist and match the server's configured SSL cert
- Have very good (and strict?) DNSSEC support. If we know a remote server is supposed to have valid DNSSEC entries, but doesn't, fail to deliver mail entirely?
- Add a new DNS record that advertises this is a Dovecot MTA (or compatible). If such entry is found (especially when correctness is guaranteed by DNSSEC), the email sender can assume that certain features exist and work correctly. If they don't, it could indicate an attack and the mail sending should be retried later. This DNS record would of course be good to try to standardize.
Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them.
Try to implement as many existing interfaces as possible (e.g. Milter and various Postfix APIs like policy servers) so that it wouldn’t be necessary to reimplement all the tools and filters.
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Hi! It is possible to look towards Exim. To take as a basis ACL system.
On Fri, 8 Nov 2013 14:07:12 +0100 Timo Sirainen tss@iki.fi writes:
Hi all,
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of time to be able to create something that was anywhere even close to having Postfix's features. (I would shudder to even think about recreating Dovecot from scratch nowadays.) But slowly over time I've also been thinking of ways how things could be done a bit better, and I think I have enough ideas to start thinking about Dovecot MTA more seriously in a few more months (after my current busy schedule calms down a bit). And (unlike Dovecot!) I'm not planning on taking over the world with the MTA (or at least not very quickly), but it would definitely be useful for many installations I know of.
My main design goals for the MTA are:
In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections.
In some cases you can't really avoid placing mails into a queue. This could be because of temporary failures or maybe because of an abnormal load spike. A mail queue in local disk isn't very nice though, because if the local disk dies, the queued mails are lost. Dovecot MTA will allow the queue to be in object storage and it will also likely support replication (similar to current dsync replication). In both of these cases if a server dies, another server can quickly take over its queue and continue handling it.
Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not:
- Require DKIM configuration. All outgoing mails will be DKIM signed.
- Require the domain’s DNS to contain _submission._tcp SRV record (and actually might as well require _imap._tcp too)
- Require SSL certificates to be configured and always allow remote to use STARTTLS
- Require DANE TLSA record to exist and match the server's configured SSL cert
- Have very good (and strict?) DNSSEC support. If we know a remote server is supposed to have valid DNSSEC entries, but doesn't, fail to deliver mail entirely?
- Add a new DNS record that advertises this is a Dovecot MTA (or compatible). If such entry is found (especially when correctness is guaranteed by DNSSEC), the email sender can assume that certain features exist and work correctly. If they don't, it could indicate an attack and the mail sending should be retried later. This DNS record would of course be good to try to standardize.
Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them.
Try to implement as many existing interfaces as possible (e.g. Milter and various Postfix APIs like policy servers) so that it wouldn’t be necessary to reimplement all the tools and filters.
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
-- Best regards, Aleksey Tsvetkov System Administrator Company Grand Vision tel. +7(495)933-39-79, ext. 184
Easy configuration of virtual users and a default location setup to handle virtual users.
On Fri, Nov 8, 2013 at 1:25 PM, Aleksey Tsvetkov wrote: Hi!
It is possible to look towards Exim. To take as a basis ACL system. On Fri, 8 Nov 2013 14:07:12 +0100
Timo Sirainen tss@iki.fi writes: Hi all, I've never really wanted to create my own MTA, because I like Postfix
quite a lot. And I always thought it would require a horribly lot of time
to be able to create something that was anywhere even close to having
Postfix's features. (I would shudder to
even think about recreating Dovecot from scratch nowadays.) But slowly
over time I've also been thinking of ways how things could be done a bit
better, and I think I have enough ideas to start thinking about Dovecot MTA
more seriously in a few more
months (after my current busy schedule calms down a bit). And (unlike
Dovecot!) I'm not planning on taking over the world with the MTA (or at
least not very quickly), but it would definitely be useful for many
installations I know of. My main design goals for the MTA are: In normal load don't queue mails, just continue delivering the mail
through different processes/services until it succeeds or fails, and only
after that return ok/failure to the SMTP client. So there's no (forced)
post-queue filtering, everything
would normally happen pre-queue. This is required because in Germany (and
EU in general?) you aren't allowed to just drop spams after SMTP server has
responsed OK to the client, even if you’re 100% sure it’s a spam. So this
would also mean that the SMTP
DATA replies will come more slowly, which means that the SMTP server must
be able to handle a lot more concurrent SMTP connections, which means that
in large installations the smtpd process must be able to asynchronously
handle multiple SMTP client
connections. In some cases you can't really avoid placing mails into a queue. This
could be because of temporary failures or maybe because of an abnormal load
spike. A mail queue in local disk isn't very nice though, because if the
local disk dies, the queued
mails are lost. Dovecot MTA will allow the queue to be in object storage
and it will also likely support replication (similar to current dsync
replication). In both of these cases if a server dies, another server can
quickly take over its queue and
continue handling it. Dovecot MTA is a new product, which means we can add some requirements
to how it's being used, especially related to securely sending emails
between servers. It could do a bunch of checks at startup and fail to even
start if everything isn't correct.
Here are some things I had in mind - not sure if all of these are good
ideas or not: Configuration: It would take years to implement all of the settings
that Postfix has, but I think it's not going to be necessary. In fact I
think the number of new settings to dovecot.conf that Dovecot MTA requires
would be very minimal. Instead
nearly all of the configuration could be done using Sieve scripts. We'd
need to implement some new MTA-specific Sieve extensions and a few core
features/configurations/databases that the scripts can use, but after that
there wouldn't be really any
limits to what could be done with them. Try to implement as many existing interfaces as possible (e.g. Milter
and various Postfix APIs like policy servers) so that it wouldn’t be
necessary to reimplement all the tools and filters. So perhaps something like this could be done in time for Dovecot v2.4.
Any thoughts/ideas/suggestions? --
Best regards,
Aleksey Tsvetkov
System Administrator
Company Grand Vision
tel. +7(495)933-39-79, ext. 184 --
Daniel Reinhardt
cryptodan@cryptodan.net
http://www.cryptodan.net
301-875-7018(c)
410-455-0488(h)
On 8.11.2013, at 14.31, Daniel Reinhardt cryptodan@gmail.com wrote:
Easy configuration of virtual users and a default location setup to handle virtual users.
The user handling would be exactly the same as it is now (same userdb settings). Dovecot MTA isn’t intended to be run standalone, most likely it can only deliver mails to Dovecot LMTP.
On 08/11/2013 13:34, Timo Sirainen wrote:
Dovecot MTA isn’t intended to be run standalone, most likely it can only deliver mails to Dovecot LMTP.
May I clarify? So Dovecot MTA might be for inbound SMTP only? Or also for outbound SMTP? (From the feature list I'd assumed outbound, as well.)
If also for outbound, we have thought to run inbound and outbound on different servers, with the outbound server not listening to any internet-capable ports, simply to reduce further the opportunity for external access leading to spam generation (because any inbound access could lead to privilege escalation due to some exploit, and alter the ACLs, for example).
Running on separate servers would imply standalone (unless config data is on NFS, perhaps).
Very supportive for the ideas listed, especially around email authentication, and security.
Ron
On 8.11.2013, at 16.15, Ron Leach ronleach@tesco.net wrote:
On 08/11/2013 13:34, Timo Sirainen wrote:
Dovecot MTA isn’t intended to be run standalone, most likely it can only deliver mails to Dovecot LMTP.
May I clarify? So Dovecot MTA might be for inbound SMTP only? Or also for outbound SMTP? (From the feature list I'd assumed outbound, as well.)
Ah, I had actually been mostly just thinking about inbound SMTP features. It should of course support outbound SMTP as well, but I’m less familiar about what functionality would be useful for that.
By “not standalone” I meant mainly that it won’t duplicate any existing Dovecot functionality, like passdbs/userdbs/mail delivery.
On 2013-11-08 10:22 AM, Timo Sirainen tss@iki.fi wrote:
Ah, I had actually been mostly just thinking about inbound SMTP features.
Hmmm.... well, I'd hate to see this turn into a huge time-sink for you. The fact is, postfix's maturity combined with its new postscreen capabilities will make it a very, very hard sell to postfix shops - especially the larger ones that rely heavily on postfix's ability to filter out the crap with as few resources as possible - and postscreen just increased that already powerful capability by at least one or two orders of magnitude.
I'm just having a hard time seeing it. I think it would be better to focus more on outbound capabilities/features myself, so, by default, dovecot would handle all mail destined for a 'local' domain (one handled by the same dovecot server), with the ability to selectively choose (ie 'transports') which external domains dove_smtp handles directly (initially other dovecot servers), then passes all other 'external' mail to the outbound proxy.
But, that is just me... it sounds like you have given this a bit of thought, and it also sounds like there is a good reason for that - maybe a paying customer? ;)
--
Best regards,
*/Charles/*
On 11/08/2013 07:43 AM, Charles Marcus wrote:
On 2013-11-08 10:22 AM, Timo Sirainen tss@iki.fi wrote:
Ah, I had actually been mostly just thinking about inbound SMTP features.
Hmmm.... well, I'd hate to see this turn into a huge time-sink for you. The fact is, postfix's maturity combined with its new postscreen capabilities will make it a very, very hard sell to postfix shops - especially the larger ones that rely heavily on postfix's ability to filter out the crap with as few resources as possible - and postscreen just increased that already powerful capability by at least one or two orders of magnitude.
Likewise, exim users aren't likely to be sold. Most of things originally listed are either standard or easily accomplished in exim.
I would probably be pretty skeptical and uninterested in a Dovecot MTA. No offense. I think you should look at other existing MTAs besides postfix before concluding there is a hole that needs filling.
(You know the old Internet saying ... all programs evolve until they can send email. I guess you are getting there. :-)
On 2013-11-08 1:35 PM, WJCarpenter bill-dovecot@carpenter.org wrote:
I would probably be pretty skeptical and uninterested in a Dovecot MTA. No offense. I think you should look at other existing MTAs besides postfix before concluding there is a hole that needs filling.
The one exception to this though, is if it was simply implemented as a proxy, but used for internal/local only emails - so, no need to involve postfix or Exim for mail submitted to the dovecot_mta if the recipient is destined for the dovecot_LDA...
The more I think about it the more I even like this idea...
--
Best regards,
*/Charles/*
On 11/08/2013 10:46 AM, Charles Marcus wrote:
On 2013-11-08 1:35 PM, WJCarpenter bill-dovecot@carpenter.org wrote:
I would probably be pretty skeptical and uninterested in a Dovecot MTA. No offense. I think you should look at other existing MTAs besides postfix before concluding there is a hole that needs filling.
The one exception to this though, is if it was simply implemented as a proxy, but used for internal/local only emails - so, no need to involve postfix or Exim for mail submitted to the dovecot_mta if the recipient is destined for the dovecot_LDA...
The more I think about it the more I even like this idea...
Well, that's sort of true for operational efficiency kinds of things, but do you really one to configure one program for internal mail and another for externally sent/received mail? I don't, but tastes vary. :-)
On 2013-11-08 2:16 PM, WJCarpenter bill-dovecot@carpenter.org wrote:
On 11/08/2013 10:46 AM, Charles Marcus wrote:
On 2013-11-08 1:35 PM, WJCarpenter bill-dovecot@carpenter.org wrote:
I would probably be pretty skeptical and uninterested in a Dovecot MTA. No offense. I think you should look at other existing MTAs besides postfix before concluding there is a hole that needs filling.
The one exception to this though, is if it was simply implemented as a proxy, but used for internal/local only emails - so, no need to involve postfix or Exim for mail submitted to the dovecot_mta if the recipient is destined for the dovecot_LDA...
The more I think about it the more I even like this idea...
Well, that's sort of true for operational efficiency kinds of things, but do you really one to configure one program for internal mail and another for externally sent/received mail? I don't, but tastes vary. :-)
As long as the configuration was simple, I don't see a problem...
What seems inefficient to me, especially since dovecot now has a submission server, is to submit to dovecot, then pass to postfix, then back to dovecot (for local mail)...
--
Best regards,
*/Charles/*
On Fri, Nov 08, 2013 at 04:22:13PM +0100, Timo Sirainen wrote:
Ah, I had actually been mostly just thinking about inbound SMTP features. It should of course support outbound SMTP as well, but I’m less familiar about what functionality would be useful for that.
Outbound is mostly the same as inbound, except requirement of authentication and TLS for the "submission" (587/tcp) and ssl wrapped "smtps" port 465/tcp.
Features we'd want:
- authentication
- per user rate limiting might be handled by Dovecot MTA instead of external program?
- spam filtering trough milter?
- virus filtering trough milter?
- Per user Geo-blocking would be great!
- Protection from password guessing ?
Plus it would be great if it could check if the authentication is still valid when re-using connection, ref missing feature in postfix:
http://postfix.1071664.n5.nabble.com/Solution-to-SMTPAuth-compromised-accounts-td61415.html-jf
You can indeed get exim to reply post-DATA having done quite a lot of decision making, and also exim will deliver immediately as opposed to queuing, but:
just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. Does that mean something LMTP-like? Reply with OK after the delivery is totally complete?
On 11/08/2013 08:25 AM, Aleksey Tsvetkov wrote:
Hi! It is possible to look towards Exim. To take as a basis ACL system.
Very interesting.. a few questions if I may?
Hi all,
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of time to be able to create something that was anywhere even close to having Postfix's features. (I would shudder to even think about recreating Dovecot from scratch nowadays.) But slowly over time I've also been thinking of ways how things could be done a bit better, and I think I have enough ideas to start thinking about Dovecot MTA more seriously in a few more months (after my current busy schedule calms down a bit). And (unlike Dovecot!) I'm not planning on taking over the world with the MTA (or at least not very quickly), but it would definitely be useful for many installations I know of.
My main design goals for the MTA are:
- In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections. This is basically what I normally do with exim, and I believe it can be achieved with postfix, so basically your point is a single asynchronous smtpd for multiple connections? My experience has been that the real problem with SMTP-time decision making is the concurrency of the extremely heavy (e.g.) spamassassin
On 11/08/2013 08:07 AM, Timo Sirainen wrote: processes, heavy in both memory and CPU, and I/O if you use bayes which you should.
- In some cases you can't really avoid placing mails into a queue. This could be because of temporary failures or maybe because of an abnormal load spike. A mail queue in local disk isn't very nice though, because if the local disk dies, the queued mails are lost. Dovecot MTA will allow the queue to be in object storage and it will also likely support replication (similar to current dsync replication). In both of these cases if a server dies, another server can quickly take over its queue and continue handling it.
Yes that would be nice. Another thing regarding multiple servers that I'd build in is a much more powerful way to manage scanning backends, keep track of dead ones (like freeradius zombie/dead tracking).
- Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not: They are all good ideas as long as these requirements can be turned off per site :-)
- Require DKIM configuration. All outgoing mails will be DKIM signed.
- Require the domain’s DNS to contain _submission._tcp SRV record (and actually might as well require _imap._tcp too)
- Require SSL certificates to be configured and always allow remote to use STARTTLS
- Require DANE TLSA record to exist and match the server's configured SSL cert
- Have very good (and strict?) DNSSEC support. If we know a remote server is supposed to have valid DNSSEC entries, but doesn't, fail to deliver mail entirely?
- Add a new DNS record that advertises this is a Dovecot MTA (or compatible). If such entry is found (especially when correctness is guaranteed by DNSSEC), the email sender can assume that certain features exist and work correctly. If they don't, it could indicate an attack and the mail sending should be retried later. This DNS record would of course be good to try to standardize.
- Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them. It comes to mind that you would want a separate master process for this in case one would run it on the same box with dovecot imap. Or at least a way to restart/reconfigure it separately.
- Try to implement as many existing interfaces as possible (e.g. Milter and various Postfix APIs like policy servers) so that it wouldn’t be necessary to reimplement all the tools and filters.
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
On 8.11.2013, at 14.29, Gedalya gedalya@gedalya.net wrote:
- In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections. This is basically what I normally do with exim, and I believe it can be achieved with postfix, so basically your point is a single asynchronous smtpd for multiple connections?
But can you (easily) configure them so that pre-queue filtering happens normally, except under heavy load it would automatically switch to post-queue filtering to avoid temporarily rejecting mails?
My experience has been that the real problem with SMTP-time decision making is the concurrency of the extremely heavy (e.g.) spamassassin processes, heavy in both memory and CPU, and I/O if you use bayes which you should.
Yeah. In cloud(-like) environments the idea is also that Antispam/virus instances could be started and stopped on the automatically on the fly as needed.
- Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not: They are all good ideas as long as these requirements can be turned off per site :-)
That was kind of the idea, that some of these couldn’t be turned off :) So the idea being that Dovecot MTA would slowly start making email a secure communication method.
- Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them. It comes to mind that you would want a separate master process for this in case one would run it on the same box with dovecot imap. Or at least a way to restart/reconfigure it separately.
You could run two Dovecot instances if you wanted to. But I have also some plans for making it possible to restart/upgrade Dovecot without losing any existing connections.
On 11/08/2013 08:39 AM, Timo Sirainen wrote:
On 8.11.2013, at 14.29, Gedalya gedalya@gedalya.net wrote:
- In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections. This is basically what I normally do with exim, and I believe it can be achieved with postfix, so basically your point is a single asynchronous smtpd for multiple connections? But can you (easily) configure them so that pre-queue filtering happens normally, except under heavy load it would automatically switch to post-queue filtering to avoid temporarily rejecting mails?
Dunno.. define "easy". I love exim, but some people would say even simple things are not easy with it. But I would agree that a lot can be achieved if you start designing something with these problems in mind. We could all really use a flexible way to decide when to do things and on which back-end server dependent upon what is available, and general load on the system.
My experience has been that the real problem with SMTP-time decision making is the concurrency of the extremely heavy (e.g.) spamassassin processes, heavy in both memory and CPU, and I/O if you use bayes which you should. Yeah. In cloud(-like) environments the idea is also that Antispam/virus instances could be started and stopped on the automatically on the fly as needed.
- Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not: They are all good ideas as long as these requirements can be turned off per site :-) That was kind of the idea, that some of these couldn’t be turned off :) So the idea being that Dovecot MTA would slowly start making email a secure communication method.
OK that's a pretty aggressively noble idea. I'm in favor. You'd probably want to (also) run the tests externally and publicly as a form of positive feedback - like a web-based test that grants a domain a "dovecot certified" status.
- Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them. It comes to mind that you would want a separate master process for this in case one would run it on the same box with dovecot imap. Or at least a way to restart/reconfigure it separately. You could run two Dovecot instances if you wanted to. But I have also some plans for making it possible to restart/upgrade Dovecot without losing any existing connections.
That would be warmly received.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 08.11.2013 14:07, schrieb Timo Sirainen:
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Hi Timo, lot of good ideas, but in my world a new/better imap client, cross plattform, with extended and working groupware feature would be more needed, as you wrote, there are allready good working smtp servers, which have nearly all features you want to implement, perhaps dovecot mta will be a good idea for making smaller dovecot setups more easy. But perhaps doing it like a "smtp proxy" would be more easy. I agree doing more sieve stuff. I am critical about new DNS stuff, cause this must be widly agreed by people. However i will think about your ideas in more detail, next days and mail it to the list.
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSfPYuAAoJEP8jBObu0LlELFYH/1Bv5mp3I2FH8wWr1GywaYWQ XHYVDSZH96q0m5BNpfYjS66y1+6BqNOQcoLtE04hJixX7ccOZs96V9LyOt26mz5C S6xHBl6afj8vhnP1B1CbXzBIqicSG4PVuNvRvFsgxYKzJtwrxujXOJptbW3k5jnB I3tHdya3rFUyMON9OrMAbAlNEDEOJFU7Eju6R32PXOqHxPvMmpcOysacitr/Lsn8 oe1FYWveL4uiApDG9pAuUnt3YfwmEFBk9jKcxTLSYYPag+mDebCgPdXn1fsUV4xY 4zrg0qJE20/U/I0oP9mGDoP6d0UXDgXoyN0Rcy0kEOfsqPUg8hcWe7qn8Nwtc9o= =TIMH -----END PGP SIGNATURE-----
On 8.11.2013, at 15.33, Robert Schetterer rs@sys4.de wrote:
Am 08.11.2013 14:07, schrieb Timo Sirainen:
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Hi Timo, lot of good ideas, but in my world a new/better imap client, cross plattform, with extended and working groupware feature would be more needed,
Would be nice yes, but I don’t think client side development is something I’m going to do anytime soon.
as you wrote, there are allready good working smtp servers, which have nearly all features you want to implement, perhaps dovecot mta will be a good idea for making smaller dovecot setups more easy.
Actually its main target audience is large ISPs and such :) The Sieve scripting for configurations is especially useful for many who want complex configurations.
Timo Sirainen skrev den 2013-11-08 15:44:
Actually its main target audience is large ISPs and such :) The Sieve scripting for configurations is especially useful for many who want complex configurations.
extend dovecot -n to output current config as xml ?
maybe even configure it all via xml ?
backports of policy server in 2.x to 1.x, support postfix more in policy services
On 10.11.2013, at 21.24, Benny Pedersen me@junc.eu wrote:
extend dovecot -n to output current config as xml ?
maybe even configure it all via xml ?
All the configuration goes through src/config/* code, which can be easily replaced with anything else. The original idea was to make it possible to store the configuration in different formats, like XML or SQL. Then again, the current config code is horrible and should be rewritten, especially to make it more modular and be able to use different formats without having to recreate the whole config code. And it’s currently spending way too much CPU, which might become a problem in some complex setups. So yeah, I think it would be nice, but I also think there are a lot of other much more important things that need to be done.
Timo Sirainen skrev den 2013-11-10 21:38:
On 10.11.2013, at 21.24, Benny Pedersen me@junc.eu wrote:
extend dovecot -n to output current config as xml ?
maybe even configure it all via xml ?
All the configuration goes through src/config/* code, which can be easily replaced with anything else. The original idea was to make it possible to store the configuration in different formats, like XML or SQL. Then again, the current config code is horrible and should be rewritten, especially to make it more modular and be able to use different formats without having to recreate the whole config code. And it’s currently spending way too much CPU, which might become a problem in some complex setups. So yeah, I think it would be nice, but I also think there are a lot of other much more important things that need to be done.
its also if xml its simple to make webconfigs from the xml file, but nice that you see config as a problem that needs redisigning before create another problem with subject, here i still using dovecot 1.2.17 in gentoo, i feal no need yet to discard that old software yet here, asked gentoo devs to put it back to portage, but was denied for some reason i just dont understand as you still have wiki for version 1 it should imho be supported in os'es as well
for the dovecot submission server will that mean dovecot will now get the imap folder for sending mails ?
thanks btw for brind mta up, i think dovecot/postfix is a well working combo
Am 10.11.2013 22:39, schrieb Benny Pedersen:
here i still using dovecot 1.2.17 in gentoo, i feal no need yet to discard that old software yet here, asked gentoo devs to put it back to portage, but was denied for some reason i just dont understand
what exactly dou you not understand in no longer supported upstream which is *here* and the last update is 2.5 years ago?
as you still have wiki for version 1
maybe the 1.0 wiki should be deleted if that helps even you to understand that 1.x is EOL long time ago? there where 2.0 and 2.1 and so who do you think is wasting it's time supporting *four major releases*?
it should imho be supported in os'es as well
why?
if you do not care more than two years about a upgrade why do you think upstream and distribution-maintainers should care about you?
On 2013-11-10 4:46 PM, Reindl Harald h.reindl@thelounge.net wrote:
maybe the 1.0 wiki should be deleted if that helps even you to understand that 1.x is EOL long time ago? there where 2.0 and 2.1 and so who do you think is wasting it's time supporting *four major releases*?
Well, it would probably be a good thing to add a major, impossible to miss disclaimer on all wiki1 pages that the 1.x series is no longer supported...
Wietse did the same thing for old/obsolete postfix pages way back (I remember when it came up on the mail list) by adding a watermark/background to all old/obsolete pages... here is an example:
http://www.postfix.org/spam.html
--
Best regards,
*/Charles/*
Am 11.11.2013 12:29, schrieb Charles Marcus:
On 2013-11-10 4:46 PM, Reindl Harald h.reindl@thelounge.net wrote:
maybe the 1.0 wiki should be deleted if that helps even you to understand that 1.x is EOL long time ago? there where 2.0 and 2.1 and so who do you think is wasting it's time supporting *four major releases*?
Well, it would probably be a good thing to add a major, impossible to miss disclaimer on all wiki1 pages that the 1.x series is no longer supported...
it was explained *to you* on this list several times in the past and you insist to write postings "but i still use 1.x" which may suggest to other readers "hey, so it must be fine"
so what does a disclaimer help in case of users like you which insist to ignore whatever people tell them in whatever context?
wll, maybe you are some kind of special in that context.......
On 2013-11-11 6:35 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 11.11.2013 12:29, schrieb Charles Marcus:
Well, it would probably be a good thing to add a major, impossible to miss disclaimer on all wiki1 pages that the 1.x series is no longer supported..
it was explained *to you* on this list several times in the past and you insist to write postings "but i still use 1.x" which may suggest to other readers "hey, so it must be fine"
so what does a disclaimer help in case of users like you which insist to ignore whatever people tell them in whatever context?
wll, maybe you are some kind of special in that context.......
??? I've *never* used 1.x, I started off with 2.1.x...
Maybe you should stop posting to mail lists before you've had your morning coffee...
--
Best regards,
*/Charles/*
Am 11.11.2013 12:42, schrieb Charles Marcus:
On 2013-11-11 6:35 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 11.11.2013 12:29, schrieb Charles Marcus:
Well, it would probably be a good thing to add a major, impossible to miss disclaimer on all wiki1 pages that the 1.x series is no longer supported..
it was explained *to you* on this list several times in the past and you insist to write postings "but i still use 1.x" which may suggest to other readers "hey, so it must be fine"
so what does a disclaimer help in case of users like you which insist to ignore whatever people tell them in whatever context?
wll, maybe you are some kind of special in that context.......
??? I've *never* used 1.x, I started off with 2.1.x...
Maybe you should stop posting to mail lists before you've had your morning coffee...
for some reason i tend to mix up you and Benny Pedersen, maybe historical because the unforgetable TLS/SSL discussion with you flagged both as lerning restistent and that you quote and reply a repsonse to Benny made it easier to mix up
On 11.11.2013, at 13.29, Charles Marcus CMarcus@Media-Brokers.com wrote:
On 2013-11-10 4:46 PM, Reindl Harald h.reindl@thelounge.net wrote:
maybe the 1.0 wiki should be deleted if that helps even you to understand that 1.x is EOL long time ago? there where 2.0 and 2.1 and so who do you think is wasting it's time supporting *four major releases*?
Well, it would probably be a good thing to add a major, impossible to miss disclaimer on all wiki1 pages that the 1.x series is no longer supported...
Wietse did the same thing for old/obsolete postfix pages way back (I remember when it came up on the mail list) by adding a watermark/background to all old/obsolete pages... here is an example:
That’s also been my plan, but for a long time I didn’t do it because Debian was still using Dovecot v1.x. But yeah, now’s a good time. Added.
On 11/11/2013 01:59 PM, Timo Sirainen wrote:
On 11.11.2013, at 13.29, Charles Marcus CMarcus@Media-Brokers.com wrote:
On 2013-11-10 4:46 PM, Reindl Harald h.reindl@thelounge.net wrote:
maybe the 1.0 wiki should be deleted if that helps even you to understand that 1.x is EOL long time ago? there where 2.0 and 2.1 and so who do you think is wasting it's time supporting *four major releases*?
Well, it would probably be a good thing to add a major, impossible to miss disclaimer on all wiki1 pages that the 1.x series is no longer supported...
Wietse did the same thing for old/obsolete postfix pages way back (I remember when it came up on the mail list) by adding a watermark/background to all old/obsolete pages... here is an example:
That’s also been my plan, but for a long time I didn’t do it because Debian was still using Dovecot v1.x. But yeah, now’s a good time. Added.
In addition to this, it could be a nice idea to move all dovecot 1.x content to the wiki1.dovecot.org subdomain. Searches for 'dovecot <generic feature>' in google are persistently showing wiki.dovecot.org as top hits, and the wiki2 contents with lower priority. That surely doesn't help beginners...
For example: https://www.google.nl/search?q=dovecot+lda
Regards, Tom
On 2013-11-11 8:17 AM, Tom Hendrikx tom@whyscream.net wrote:
In addition to this, it could be a nice idea to move all dovecot 1.x content to the wiki1.dovecot.org subdomain. Searches for 'dovecot <generic feature>' in google are persistently showing wiki.dovecot.org as top hits, and the wiki2 contents with lower priority. That surely doesn't help beginners... For example: https://www.google.nl/search?q=dovecot+lda Regards, Tom
I agree... I was not a fan of the whole wiki1 vs wiki2 thing from the beginning...
--
Best regards,
*/Charles/*
Am 10.11.2013 21:24, schrieb Benny Pedersen:
Timo Sirainen skrev den 2013-11-08 15:44:
Actually its main target audience is large ISPs and such :) The Sieve scripting for configurations is especially useful for many who want complex configurations.
extend dovecot -n to output current config as xml ?
maybe even configure it all via xml ?
backports of policy server in 2.x to 1.x
1.x is dead since a long long time, any second backport features is completly wasted time
On 2013-11-08 9:33 AM, Robert Schetterer rs@sys4.de wrote:
Hi Timo, lot of good ideas, but in my world a new/better imap client, cross plattform, with extended and working groupware feature would be more needed, as you wrote, there are allready good working smtp servers
I agree... would *love* to see you (Timo) work on a cross-platform IMAP only (or at least IMAP optimized) mail client!
But perhaps doing it like a "smtp proxy" would be more easy. I agree doing more sieve stuff. I am critical about new DNS stuff, cause this must be widly agreed by people.
Also exactly (smtp_proxy) what I was thinking...
Postfix, especially now that it has postscreen features, is going to be extremely hard to beat, as far as security (especially in keeping the spambots away) goes...
Maybe the very first version could be just a simple smtp_proxy, then start adding features that can work pre-proxy, until eventually you get to the point it could handle everything by itself - or maybe you'd find that you could do everything you'd want to do in the pre-proxy features and wouldn't have to worry about duplicating all of the features of the mature MTAs out there...
And the first pre-proxy feature could be for handling mails with a local destination - and I'm thinking specifically about my old feature request for the 'submission_server' feature so that emails sent would automatically have a copy added to the sent folder, so that clients could disable the 'Copy to sent folder' feature and avoid the overhead of uploading the email twice. Maybe even be able to detect somehow (not sure if this is possible to be done reliably) if a client is configured to save a copy to sent folder to prevent duplicates of sent messages - and best would be to be able to detect this and refuse the copy with an informative message to disable the Save to sent feature in the MUA...
However i will think about your ideas in more detail, next days and mail it to the list.
Me too...
Thanks Timo!
--
Best regards,
*/Charles/*
On 8.11.2013, at 16.12, Charles Marcus CMarcus@Media-Brokers.com wrote:
And the first pre-proxy feature could be for handling mails with a local destination - and I'm thinking specifically about my old feature request for the 'submission_server' feature so that emails sent would automatically have a copy added to the sent folder, so that clients could disable the 'Copy to sent folder' feature and avoid the overhead of uploading the email twice. Maybe even be able to detect somehow (not sure if this is possible to be done reliably) if a client is configured to save a copy to sent folder to prevent duplicates of sent messages - and best would be to be able to detect this and refuse the copy with an informative message to disable the Save to sent feature in the MUA…
This is more about the SMTP submission server, which is already more or less implemented, although without the auto-bcc-feature: http://hg.rename-it.nl/dovecot-2.2-patches/file/9d3dd00ecc31/submission.patc...
Hi Timo,
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Many good ideas but with Exim and Postfix we do have two very powerful MTAs out there. I doubt there is demand for an additional one and this project will eat much time which can be invested to enhance your great IMAP server.
Heiko
Heiko Schlichting Freie Universität Berlin heiko.schlichting@fu-berlin.de Zentraleinrichtung für Datenverarbeitung Telefon +49 30 838-54327 Fabeckstraße 32 Telefax +49 30 838454327 14195 Berlin
Hi Timo,
I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends).
Only if you have enough personal resources and Dovecot as an IMAP server will not "loose your attention", I would love to see your expertise in making a better MTA.
You are talking about bigger ISP installations, and there you always have at least 3 tiers: Internet-facing SMTP servers, in-the-middle-SMTP-servers delivering local mail to Dovecot via LDA or LMTP, and some outbound SMTP servers. For these middle-SMTP-servers that more or less just connect to Dovecot to deliver local mails I could see a more lightweight MTA solution, so instead of having Postfix+Dovecot I would like to see Dovecot(+MTA features) only.
I'm not sure if I would use your MTA as the Internet-facing server, where "just" a fast SMTP server is needed with good Spam filters, Anti-DDOS-Features and so on. But that would be the position where all your strict DNS and TLS features are needed. I would love making email more secure by default.
I totally like your idea of the object storage instead of local files for queues. That is an awesome feature for situations where your harddisks fails, your postfix-server burns down or goes into long maintenance. Having mails in a more central (redundant) place is very cool, so if one server dies another can quickly take over all "his" mails. That feature is awesome for the outbound SMTP servers, where millions of mails are "stored" in the queues for many days, a harddisk failure is a big problem there.
Sum up: I would love to see you working on a MTA, but ONLY if you don't neglect the worlds best IMAP server :-)
Michael
On 8.11.2013, at 21.47, Michael Kliewe mkliewe@gmx.de wrote:
Sum up: I would love to see you working on a MTA, but ONLY if you don't neglect the worlds best IMAP server :-)
I’m not going to start Dovecot MTA until there are more Dovecot developers. Ideally the new developer(s) would be writing most of the MTA code..
On 8.11.2013, at 21.47, Michael Kliewe mkliewe@gmx.de wrote:
I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends).
Oh, and the built-in health checker for directors isn’t planned at all. There’s no need for it to be built-in, and it’s better to use a script that different installations can easily modify for their own purposes. A somewhat better health-checking script (that could differentiate between temporary and permanent failures) would be good though. And Dovecot roadmap is slowly shrinking .. there aren’t all that many big features left anymore. Soon it’s mainly going to be improvements to reliability and performance. So I need to find some new things to do in any case. :)
On 11/9/13, Michael Kliewe mkliewe@gmx.de wrote:
Hi Timo,
I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends).
Only if you have enough personal resources and Dovecot as an IMAP server will not "loose your attention", I would love to see your expertise in making a better MTA.
Yes, some of us have been waiting for some years now, for a configurable change to alter the method of dovecots method of failover, which is just load balancing between servers rather than true failover, like postix, I see now why it gets no importance.
On 9.11.2013, at 5.11, Nick Edwards nick.z.edwards@gmail.com wrote:
On 11/9/13, Michael Kliewe mkliewe@gmx.de wrote:
Hi Timo,
I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends).
Only if you have enough personal resources and Dovecot as an IMAP server will not "loose your attention", I would love to see your expertise in making a better MTA.
Yes, some of us have been waiting for some years now, for a configurable change to alter the method of dovecots method of failover, which is just load balancing between servers rather than true failover, like postix, I see now why it gets no importance.
Ah, you’re talking about SQL connections. Had to look up from old mails what you were talking about. It hasn’t changed, because I think the current behavior with load balancing + failover is more useful than failover-only. And you can already do failover-only with an external load balancer. Sure, Dovecot could also implement it, but it’s not something I especially want to spend time on implementing.
On 11/9/13, Timo Sirainen tss@iki.fi wrote:
On 9.11.2013, at 5.11, Nick Edwards nick.z.edwards@gmail.com wrote:
On 11/9/13, Michael Kliewe mkliewe@gmx.de wrote:
Hi Timo,
I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends).
Only if you have enough personal resources and Dovecot as an IMAP server will not "loose your attention", I would love to see your expertise in making a better MTA.
Yes, some of us have been waiting for some years now, for a configurable change to alter the method of dovecots method of failover, which is just load balancing between servers rather than true failover, like postix, I see now why it gets no importance.
Ah, you’re talking about SQL connections. Had to look up from old mails what you were talking about. It hasn’t changed, because I think the current behavior with load balancing + failover is more useful than failover-only. And you can already do failover-only with an external load balancer. Sure, Dovecot could also implement it, but it’s not something I especially want to spend time on implementing.
My employer has 18 pop3 servers, one imap customer access (imap here has so little use we cant justify a redundant machine, not for 11, yes, eleven only users after 2 years of offering imap , and 2 imap (webmail).
Sp, each server has a replicated mysql database
If I use your "better" method, I have 18 machines polling themselves and the MASTER server, this needlessly slams the daylights out of the master as I'm sure even you can imagine.
We have 4 customer relay smtp servers and 4 inbound smtp servers, postifx, using its failover and "better" method, means they only hit the master server when the local mysql unix socket is not listening, ie, mysqld is stopped - the master server NEVER sees them.
How is your method, "better" than true failover like method used by postfix, your methods is load balancing, it is not failover, and causes problems on larger networks
I'm sure in some cases most people using it are happy and wont have performance increases noticeable, but if you are going to offer a backup for auth, it really shoulds be able to configure, if we want it to DoS our master, or only talk to master when it cant talk local, so I think it should be matter you need to consider, else you are only half arsed doing it, and like implying we should go introduce a further point of failure, by using yet more third party softwares
My company have 36 dovecots, one biggest ISP in country 3 million user, agree with Nick poster, we had stop use dovecot load balance because too bad effect on primary database, now use single localhost, we have script run every 30 second to test login, if fail sleep 30 second, try again, fail and down ethernet interface so hardware load balancer see server not answer and can not use, nagios soon tell us of problem, very very bad and stupid way, but only option is safe, we have look at alternative to dovecot for this and still look, not happy with unreliable softwares to immitate feature.
big network mean big time locate and fix problem when arise so you be good to say no extra point of failure. Too many cog in chain eventually lead to problem.
Timo pleaz reconsider feature
On Sun, Nov 10, 2013 at 4:21 PM, Nick Edwards nick.z.edwards@gmail.comwrote:
On 11/9/13, Timo Sirainen tss@iki.fi wrote:
On 9.11.2013, at 5.11, Nick Edwards nick.z.edwards@gmail.com wrote:
On 11/9/13, Michael Kliewe mkliewe@gmx.de wrote:
Hi Timo,
I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends).
Only if you have enough personal resources and Dovecot as an IMAP server will not "loose your attention", I would love to see your expertise in making a better MTA.
Yes, some of us have been waiting for some years now, for a configurable change to alter the method of dovecots method of failover, which is just load balancing between servers rather than true failover, like postix, I see now why it gets no importance.
Ah, you’re talking about SQL connections. Had to look up from old mails what you were talking about. It hasn’t changed, because I think the current behavior with load balancing + failover is more useful than failover-only. And you can already do failover-only with an external load balancer. Sure, Dovecot could also implement it, but it’s not something I especially want to spend time on implementing.
My employer has 18 pop3 servers, one imap customer access (imap here has so little use we cant justify a redundant machine, not for 11, yes, eleven only users after 2 years of offering imap , and 2 imap (webmail).
Sp, each server has a replicated mysql database
If I use your "better" method, I have 18 machines polling themselves and the MASTER server, this needlessly slams the daylights out of the master as I'm sure even you can imagine.
We have 4 customer relay smtp servers and 4 inbound smtp servers, postifx, using its failover and "better" method, means they only hit the master server when the local mysql unix socket is not listening, ie, mysqld is stopped - the master server NEVER sees them.
How is your method, "better" than true failover like method used by postfix, your methods is load balancing, it is not failover, and causes problems on larger networks
I'm sure in some cases most people using it are happy and wont have performance increases noticeable, but if you are going to offer a backup for auth, it really shoulds be able to configure, if we want it to DoS our master, or only talk to master when it cant talk local, so I think it should be matter you need to consider, else you are only half arsed doing it, and like implying we should go introduce a further point of failure, by using yet more third party softwares
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 11.11.2013 06:24, schrieb Edwardo Garcia:
My company have 36 dovecots, one biggest ISP in country 3 million user, agree with Nick poster, we had stop use dovecot load balance because too bad effect on primary database, now use single localhost, we have script run every 30 second to test login, if fail sleep 30 second, try again, fail and down ethernet interface so hardware load balancer see server not answer and can not use, nagios soon tell us of problem, very very bad and stupid way, but only option is safe, we have look at alternative to dovecot for this and still look, not happy with unreliable softwares to immitate feature.
big network mean big time locate and fix problem when arise so you be good to say no extra point of failure. Too many cog in chain eventually lead to problem.
Wow thats big, and may have implications out of my scope, but database replication is not the job of dovecot, after all why not use loadbalancer like keepalived etc and setup proxies on them so you may combine check feaures from loadbalancers to target related dovecot proxies, which themselves conect to backhand dovecot servers, also its easy to monitor, for sure you may need some shared storage too, which is again not real related to dovecot , i tested ceph , so i think its possible to have seperate mount points with i.e ocfs2 for each domain.
At the end ,for such big setups there should be enough budget to get things solved by hire specialists for each software part which is involved
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSgJWEAAoJEP8jBObu0LlEjpcIAKcZofBBiVGw9EqKzmEoGqTq y3A0CqnsmSmi21V5ofBlyrYpNSkusd+V2mKPFIUBoABwpFyWxUsQgO5n22lGX70+ 7Tkqa4ClBM7ImrXVfZ/uznkDlOwfIZGomIoouYPdm+4mq5oRVv+jmUv4PBg9fzi2 6cVOG8WBMuLtx/vBJypWoixxd075pv0/mCXSHZvFL9Th8TAk39p73rZ+woJPcN3w Qb6EKNcaOvl9PNVzjpquDP9jWrynUCCp70sUAhnHqc0778m2Gjx5boj2kXpSpgPz Tro9F6UesJU62sAyjzled2Jm2XH5EuhAhwLOlUZP88B1N7Ijs7vHTfnWPQelnaM= =pBeW -----END PGP SIGNATURE-----
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
Silly offer one option if it cause denial of service, again setting up more third party softwares is not answer, more cogs in chain, more chances of breakage, we think dropping server altogether is better if server auth not work rather than overload master server because of dovecot design.
On Mon, Nov 11, 2013 at 6:30 PM, Robert Schetterer rs@sys4.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 11.11.2013 06:24, schrieb Edwardo Garcia:
My company have 36 dovecots, one biggest ISP in country 3 million user, agree with Nick poster, we had stop use dovecot load balance because too bad effect on primary database, now use single localhost, we have script run every 30 second to test login, if fail sleep 30 second, try again, fail and down ethernet interface so hardware load balancer see server not answer and can not use, nagios soon tell us of problem, very very bad and stupid way, but only option is safe, we have look at alternative to dovecot for this and still look, not happy with unreliable softwares to immitate feature.
big network mean big time locate and fix problem when arise so you be good to say no extra point of failure. Too many cog in chain eventually lead to problem.
Wow thats big, and may have implications out of my scope, but database replication is not the job of dovecot, after all why not use loadbalancer like keepalived etc and setup proxies on them so you may combine check feaures from loadbalancers to target related dovecot proxies, which themselves conect to backhand dovecot servers, also its easy to monitor, for sure you may need some shared storage too, which is again not real related to dovecot , i tested ceph , so i think its possible to have seperate mount points with i.e ocfs2 for each domain.
At the end ,for such big setups there should be enough budget to get things solved by hire specialists for each software part which is involved
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSgJWEAAoJEP8jBObu0LlEjpcIAKcZofBBiVGw9EqKzmEoGqTq y3A0CqnsmSmi21V5ofBlyrYpNSkusd+V2mKPFIUBoABwpFyWxUsQgO5n22lGX70+ 7Tkqa4ClBM7ImrXVfZ/uznkDlOwfIZGomIoouYPdm+4mq5oRVv+jmUv4PBg9fzi2 6cVOG8WBMuLtx/vBJypWoixxd075pv0/mCXSHZvFL9Th8TAk39p73rZ+woJPcN3w Qb6EKNcaOvl9PNVzjpquDP9jWrynUCCp70sUAhnHqc0778m2Gjx5boj2kXpSpgPz Tro9F6UesJU62sAyjzled2Jm2XH5EuhAhwLOlUZP88B1N7Ijs7vHTfnWPQelnaM= =pBeW -----END PGP SIGNATURE-----
On 2013-11-11 5:58 AM, Edwardo Garcia wdgarc88@gmail.com wrote:
Silly offer one option if it cause denial of service, again setting up more third party softwares is not answer, more cogs in chain, more chances of breakage, we think dropping server altogether is better if server auth not work rather than overload master server because of dovecot design.
I'm quite certain Timo would be very happy to provide a quote to you for what it would cost to implement this for you... or, you could do so yourself (it is open-source software after all).
Otherwise, I think you should reconsider your comments and apologize to Timo and the list for your childish whining.
--
Best regards,
*/Charles/*
Edwardo Garcia skrev den 2013-11-11 11:58:
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
so move to postgresql/mysql backend and change from dovecot to dbmail ?
why blame dovecot for using fs mail store ?
is your problem unstable nfs ?
give up and get google app mx :)
On 2013-11-11 1:28 PM, Benny Pedersen me@junc.eu wrote:
Edwardo Garcia skrev den 2013-11-11 11:58:
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
so move to postgresql/mysql backend and change from dovecot to dbmail ?
why blame dovecot for using fs mail store ?
is your problem unstable nfs ?
give up and get google app mx :)
Benny, you really should just stop talking for the most part, most of what you say is not just irrelevant or OT, it is plain ridiculous.
The comments discussing how dovecot handles non-responsive mysql hosts have absolutely NOTHING to do with using NFS or SQL for mail storage.
In fact, I'd go so far as to say they do seem to have a valid point, although I haven't looked closely at the details, because I don't need to (have just a single mysql DB for user verifying/authenticating) - but since the need is one more for larger or even commercial shops, then they should be able to deal with the issues themselves - either via scripts, as has been suggested by Timo, or simply by doing the heavy lifting and writing the code (or paying Timo to write the code) to do what they are whining that it doesn't do.
--
Best regards,
*/Charles/*
This thread really should be starting to die soon. Very little of it has to do with the MTA subject itself.. If you have other complaints, create new threads with new subjects.
On 11.11.2013, at 20.56, Charles Marcus CMarcus@Media-Brokers.com wrote:
On 2013-11-11 1:28 PM, Benny Pedersen me@junc.eu wrote:
Edwardo Garcia skrev den 2013-11-11 11:58:
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
so move to postgresql/mysql backend and change from dovecot to dbmail ?
why blame dovecot for using fs mail store ?
is your problem unstable nfs ?
give up and get google app mx :)
Benny, you really should just stop talking for the most part, most of what you say is not just irrelevant or OT, it is plain ridiculous.
The comments discussing how dovecot handles non-responsive mysql hosts have absolutely NOTHING to do with using NFS or SQL for mail storage.
In fact, I'd go so far as to say they do seem to have a valid point, although I haven't looked closely at the details, because I don't need to (have just a single mysql DB for user verifying/authenticating) - but since the need is one more for larger or even commercial shops, then they should be able to deal with the issues themselves - either via scripts, as has been suggested by Timo, or simply by doing the heavy lifting and writing the code (or paying Timo to write the code) to do what they are whining that it doesn't do.
--
Best regards,
*/Charles/*
On 12/11/2013 04:28, Benny Pedersen wrote:
Edwardo Garcia skrev den 2013-11-11 11:58:
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
so move to postgresql/mysql backend and change from dovecot to dbmail ?
why blame dovecot for using fs mail store ?
is your problem unstable nfs ?
give up and get google app mx :)
WTF drugs are you on? Or maybe its more to the point of what medication you're not taking.
Briefly reading, he;s talking about the same problem i and a few otehrs have brought up in the past (i gave up on it since Timo made it very clear he has no interest at all and Edward is really wasting his time) *dovecot authentication for users* unless I missed something, possible, so much noise on this list I rarely bother to read it anymore, and this mornings reading reaffirms why i dont
Am 12.11.2013 02:14, schrieb Noel Butler:
On 12/11/2013 04:28, Benny Pedersen wrote:
Edwardo Garcia skrev den 2013-11-11 11:58:
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
so move to postgresql/mysql backend and change from dovecot to dbmail ?
why blame dovecot for using fs mail store ?
is your problem unstable nfs ?
give up and get google app mx :)
WTF drugs are you on? Or maybe its more to the point of what medication you're not taking
you smartass better should have read all your mails before suggest someone should reridect my repsones to our ISP in your previous answer
oh, yeah, i know, you are not reading this but have the mouth open and playing the saint internet police
Pls, people, be kind and polite! Thats not the way for talking to each other! Greetings, Martin
Am 12.11.2013 10:30, schrieb Reindl Harald:
Am 12.11.2013 02:14, schrieb Noel Butler:
On 12/11/2013 04:28, Benny Pedersen wrote:
Edwardo Garcia skrev den 2013-11-11 11:58:
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
so move to postgresql/mysql backend and change from dovecot to dbmail ?
why blame dovecot for using fs mail store ?
is your problem unstable nfs ?
give up and get google app mx :)
WTF drugs are you on? Or maybe its more to the point of what medication you're not taking
you smartass better should have read all your mails before suggest someone should reridect my repsones to our ISP in your previous answer
oh, yeah, i know, you are not reading this but have the mouth open and playing the saint internet police
-- Viele Grüße,
Martin Rabl
tell that Noel which is blocking my messages and so did not read what i quoted from Benny's trolling but opens his mouth
tell that Noel which is abusing his power by set complete IP-ranges on RBL lists he maintains because he does not like one person using a mailserver on that range besides many other people
blocked using bl.alt-backspace.org; This range is used by caustic Internet troll Harald Reindl h.reindl@thelounge.net / ACCESS DENIED - see http://www.alt-backspace.org/usage.php#misc (in reply to RCPT TO command)
tell that Noel which recommends redirect to our ISP
if allof (header :contains "From" "thelounge.net", header :contains "From" "rhsoft.net") { redirect "abuse@inode.at"; }
Am 12.11.2013 10:36, schrieb Martin Rabl:
Pls, people, be kind and polite! Thats not the way for talking to each other! Greetings, Martin
Am 12.11.2013 10:30, schrieb Reindl Harald:
Am 12.11.2013 02:14, schrieb Noel Butler:
On 12/11/2013 04:28, Benny Pedersen wrote:
Edwardo Garcia skrev den 2013-11-11 11:58:
But is dovecot job to authenticate, mysql replicate fine, it is dovecot that is not fine by ignoring desire effect by only talk localhost and not any other unless locahost auth not respond.
so move to postgresql/mysql backend and change from dovecot to dbmail ?
why blame dovecot for using fs mail store ?
is your problem unstable nfs ?
give up and get google app mx :)
WTF drugs are you on? Or maybe its more to the point of what medication you're not taking
you smartass better should have read all your mails before suggest someone should reridect my repsones to our ISP in your previous answer
oh, yeah, i know, you are not reading this but have the mouth open and playing the saint internet police
On 2013-11-11 12:24 AM, Edwardo Garcia wdgarc88@gmail.com wrote:
My company have 36 dovecots, one biggest ISP in country 3 million user, agree with Nick poster, we had stop use dovecot load balance because too bad effect on primary database, now use single localhost, we have script run every 30 second to test login, if fail sleep 30 second, try again, fail and down ethernet interface so hardware load balancer see server not answer and can not use, nagios soon tell us of problem, very very bad and stupid way, but only option is safe, we have look at alternative to dovecot for this and still look, not happy with unreliable softwares to immitate feature.
big network mean big time locate and fix problem when arise so you be good to say no extra point of failure. Too many cog in chain eventually lead to problem.
Timo pleaz reconsider feature
Well, since you are so big, and really need this feature in your large COMMERCIAL environment, maybe you should step up and PAY Timo to implement it?
Comments like this really piss me off.
--
Best regards,
*/Charles/*
Charles Marcus skrev den 2013-11-11 12:34:
Well, since you are so big, and really need this feature in your large COMMERCIAL environment, maybe you should step up and PAY Timo to implement it?
Comments like this really piss me off.
payments could be with working patch, nobody cares :(
same goes with opendmarc/opendkim where google servers needs there patches, arg !
why do you not simply shut up?
Am 11.11.2013 19:20, schrieb Benny Pedersen:
payments could be with working patch, nobody cares :(
Am 11.11.2013 19:28, schrieb Benny Pedersen:
so move to postgresql/mysql backend and change from dovecot to dbmail ? why blame dovecot for using fs mail store ? is your problem unstable nfs ? give up and get google app mx :)
Am 10.11.2013 20:15, schrieb Benny Pedersen:
why is users not just change from postfix/dovecot to currier-* ? its imho much better :) http://www.courier-mta.org/
Am 10.11.2013 21:24, schrieb Benny Pedersen:
backports of policy server in 2.x to 1.x, support postfix more in policy services
Am 10.11.2013 22:39, schrieb Benny Pedersen:
here i still using dovecot 1.2.17 in gentoo, i feal no need yet to discard that old software yet here, asked gentoo devs to put it back to portage, but was denied for some reason i just dont understand
My installation is only serving 1/10 of your size, but long time ago we migrated off mysql for userdatabase, and over to LDAP. The MySQL data source had issues (not dovecot related), and didn't seem like the right tool for the job.
Initially we kept mysql as the authoritative database over our users, and mirrored the user details over to LDAP/389ds -- which we pointed dovecot and postfix to. Then eventually we migrated completely out of MySQL as user database. LDAP/389ds gives us easy multimaster replication, easy integration with dovecot, postfix, etc., client side support for failover between servers, and it is very fast. I don't think we've ever had any issue with the userdb after migrating to LDAP.
our two 389ds servers are doing about 80 ldap bind() authentications per second (plus dovecot auth cache is masking a lot more), 300 searches/s and are using about 20% of a single cpu core each.
So, I would very much recommend you look into if something similar can work for you.
-jf
On Mon, Nov 11, 2013 at 03:24:46PM +1000, Edwardo Garcia wrote:
My company have 36 dovecots, one biggest ISP in country 3 million user, agree with Nick poster, we had stop use dovecot load balance because too bad effect on primary database, now use single localhost, we have script run every 30 second to test login, if fail sleep 30 second, try again, fail and down ethernet interface so hardware load balancer see server not answer and can not use, nagios soon tell us of problem, very very bad and stupid way, but only option is safe, we have look at alternative to dovecot for this and still look, not happy with unreliable softwares to immitate feature.
big network mean big time locate and fix problem when arise so you be good to say no extra point of failure. Too many cog in chain eventually lead to problem.
Timo pleaz reconsider feature
On Sun, Nov 10, 2013 at 4:21 PM, Nick Edwards nick.z.edwards@gmail.comwrote:
On 11/9/13, Timo Sirainen tss@iki.fi wrote:
On 9.11.2013, at 5.11, Nick Edwards nick.z.edwards@gmail.com wrote:
On 11/9/13, Michael Kliewe mkliewe@gmx.de wrote:
Hi Timo,
I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends).
Only if you have enough personal resources and Dovecot as an IMAP server will not "loose your attention", I would love to see your expertise in making a better MTA.
Yes, some of us have been waiting for some years now, for a configurable change to alter the method of dovecots method of failover, which is just load balancing between servers rather than true failover, like postix, I see now why it gets no importance.
Ah, you’re talking about SQL connections. Had to look up from old mails what you were talking about. It hasn’t changed, because I think the current behavior with load balancing + failover is more useful than failover-only. And you can already do failover-only with an external load balancer. Sure, Dovecot could also implement it, but it’s not something I especially want to spend time on implementing.
My employer has 18 pop3 servers, one imap customer access (imap here has so little use we cant justify a redundant machine, not for 11, yes, eleven only users after 2 years of offering imap , and 2 imap (webmail).
Sp, each server has a replicated mysql database
If I use your "better" method, I have 18 machines polling themselves and the MASTER server, this needlessly slams the daylights out of the master as I'm sure even you can imagine.
We have 4 customer relay smtp servers and 4 inbound smtp servers, postifx, using its failover and "better" method, means they only hit the master server when the local mysql unix socket is not listening, ie, mysqld is stopped - the master server NEVER sees them.
How is your method, "better" than true failover like method used by postfix, your methods is load balancing, it is not failover, and causes problems on larger networks
I'm sure in some cases most people using it are happy and wont have performance increases noticeable, but if you are going to offer a backup for auth, it really shoulds be able to configure, if we want it to DoS our master, or only talk to master when it cant talk local, so I think it should be matter you need to consider, else you are only half arsed doing it, and like implying we should go introduce a further point of failure, by using yet more third party softwares
On 11/8/2013 7:07 AM, Timo Sirainen wrote:
I've never really wanted to create my own MTA, because I like Postfix
And given Postfix, Exim, etc, are mature and feature complete, why would you want to at this time?
My main design goals for the MTA are: ...
- Dovecot MTA is a new product
"Product". Open source developers usually don't refer to new projects as "products".
- Configuration: ...Instead nearly all of the configuration could be done using Sieve scripts. ...
- Try to implement as many existing interfaces as possible (e.g. Milter and various Postfix APIs like policy servers) so that it wouldn’t be necessary to reimplement all the tools and filters.
It seems pretty clear your long term goal with this is to sew up Dovecot into a single source integrated stack that doesn't require an external MTA, and to sell the stack as a product.
If this is your motivation behind this MTA, please state so. If this future integrated Dovecot stack product may negatively impact current open source Dovecot users, please state so.
-- Stan
On 9.11.2013, at 3.57, Stan Hoeppner stan@hardwarefreak.com wrote:
My main design goals for the MTA are: ...
- Dovecot MTA is a new product
"Product". Open source developers usually don't refer to new projects as "products”.
Maybe I’ve been talking to business people for too long now :)
- Configuration: ...Instead nearly all of the configuration could be done using Sieve scripts. ...
- Try to implement as many existing interfaces as possible (e.g. Milter and various Postfix APIs like policy servers) so that it wouldn’t be necessary to reimplement all the tools and filters.
It seems pretty clear your long term goal with this is to sew up Dovecot into a single source integrated stack that doesn't require an external MTA, and to sell the stack as a product.
If this is your motivation behind this MTA, please state so. If this future integrated Dovecot stack product may negatively impact current open source Dovecot users, please state so.
We’re already more or less selling what we’re planning on selling, but currently the MTA is Postfix. But yeah, the new MTA needs to have some business reason for bringing it into existence. Still, I don’t see how it could negatively impact Dovecot. It’s going to be open source anyway.
Hi Timo,
You really love Postfix. Now take some time and look at Exim too. It has many of the features and would probably be much better with your input - to improve the areas you see as lacking. You are capable of churning out an excellent product, but for this one, I'd suggest you just engage the Exim Developers and push your ideas/contributions to them and in a shorter time you can get this shiny MTA you are dreaming of. Worse case scenario - just fork out Exim. Exim+Dovecot has worked very well for me for years. I started using Exim and Dovecot from their inceptions. I am not sure I'd be excited about anything else.
On 8 November 2013 16:07, Timo Sirainen tss@iki.fi wrote:
Hi all,
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of time to be able to create something that was anywhere even close to having Postfix's features. (I would shudder to even think about recreating Dovecot from scratch nowadays.) But slowly over time I've also been thinking of ways how things could be done a bit better, and I think I have enough ideas to start thinking about Dovecot MTA more seriously in a few more months (after my current busy schedule calms down a bit). And (unlike Dovecot!) I'm not planning on taking over the world with the MTA (or at least not very quickly), but it would definitely be useful for many installations I know of.
My main design goals for the MTA are:
In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections.
In some cases you can't really avoid placing mails into a queue. This could be because of temporary failures or maybe because of an abnormal load spike. A mail queue in local disk isn't very nice though, because if the local disk dies, the queued mails are lost. Dovecot MTA will allow the queue to be in object storage and it will also likely support replication (similar to current dsync replication). In both of these cases if a server dies, another server can quickly take over its queue and continue handling it.
Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not:
- Require DKIM configuration. All outgoing mails will be DKIM signed.
- Require the domain’s DNS to contain _submission._tcp SRV record (and actually might as well require _imap._tcp too)
- Require SSL certificates to be configured and always allow remote to use STARTTLS
- Require DANE TLSA record to exist and match the server's configured SSL cert
- Have very good (and strict?) DNSSEC support. If we know a remote server is supposed to have valid DNSSEC entries, but doesn't, fail to deliver mail entirely?
- Add a new DNS record that advertises this is a Dovecot MTA (or compatible). If such entry is found (especially when correctness is guaranteed by DNSSEC), the email sender can assume that certain features exist and work correctly. If they don't, it could indicate an attack and the mail sending should be retried later. This DNS record would of course be good to try to standardize.
Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them.
Try to implement as many existing interfaces as possible (e.g. Milter and various Postfix APIs like policy servers) so that it wouldn’t be necessary to reimplement all the tools and filters.
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler."
On Friday 08 of November 2013, Timo Sirainen wrote:
My main design goals for the MTA are: [...] the number of new settings to dovecot.conf that Dovecot MTA requires would
- Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think
be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them.
What I would love is configuration flexibility, some simplified programming language for configuration to allow doing magic things with this new mta and not just be limited by fixed configuration boundaries.
exim allows much of such flexibility (including delivery dependant on moon phase - can be easily implemented) but its configuration language is horrible.
(For simple mta lovers - http://opensmtpd.org/)
-- Arkadiusz Miśkiewicz, arekm / maven.pl
On 11/8/2013 5:07 AM, Timo Sirainen wrote:
I've never really wanted to create my own MTA,
Then please don't. Dovecot took over because the mailbox side of email was a wheel that needed reinventing. That is not the case with SMTP servers. Fork Exim or Postfix if you want to create an MTA. There's 14+ years of operational wisdom rolled into Postfix and even more for Exim.
On 11/08/2013 02:07 PM, Timo Sirainen wrote:
[...] So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Have you considered creating SMTP MSA (port 587) server as "step one"?
Making dovecot itself handle SMTP AUTH may help to better integrate dovecot with a few more MTA servers.
Am 10.11.2013 00:48, schrieb Andrzej A. Filip:
On 11/08/2013 02:07 PM, Timo Sirainen wrote:
[...] So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Have you considered creating SMTP MSA (port 587) server as "step one"?
Making dovecot itself handle SMTP AUTH may help to better integrate dovecot with a few more MTA servers.
hardly - only in very small environments this could work
everywhere else you have sender-dependent relay hosts, RCPT dependent relayhosts and all sort of aliases which you *do not* want treated different between incoming mail from outside or a internal server and submission mail
the only real difference between submission is that it is authenticated and because the authentication a few restrictions are not applied
but in usual there is and must not be any difference in the mail-routing
so no - make it complete or not at all
On 11/10/2013 12:59 AM, Reindl Harald wrote:
Am 10.11.2013 00:48, schrieb Andrzej A. Filip:
On 11/08/2013 02:07 PM, Timo Sirainen wrote:
[...] So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Have you considered creating SMTP MSA (port 587) server as "step one"?
Making dovecot itself handle SMTP AUTH may help to better integrate dovecot with a few more MTA servers.
hardly - only in very small environments this could work
everywhere else you have sender-dependent relay hosts, RCPT dependent relayhosts and all sort of aliases which you *do not* want treated different between incoming mail from outside or a internal server and submission mail
the only real difference between submission is that it is authenticated and because the authentication a few restrictions are not applied
but in usual there is and must not be any difference in the mail-routing
so no - make it complete or not at all
Would "simple MTA" make more sense to you?
- MSA
- sending out via smart host
- accepting incoming from email gateway
It may make sense for organizations with geographically distributed branches.
Am 10.11.2013 01:29, schrieb Andrzej A. Filip:
On 11/10/2013 12:59 AM, Reindl Harald wrote:
Am 10.11.2013 00:48, schrieb Andrzej A. Filip:
On 11/08/2013 02:07 PM, Timo Sirainen wrote:
[...] So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
Have you considered creating SMTP MSA (port 587) server as "step one"?
Making dovecot itself handle SMTP AUTH may help to better integrate dovecot with a few more MTA servers.
hardly - only in very small environments this could work
everywhere else you have sender-dependent relay hosts, RCPT dependent relayhosts and all sort of aliases which you *do not* want treated different between incoming mail from outside or a internal server and submission mail
the only real difference between submission is that it is authenticated and because the authentication a few restrictions are not applied
but in usual there is and must not be any difference in the mail-routing
so no - make it complete or not at all
Would "simple MTA" make more sense to you?
- MSA
- sending out via smart host
- accepting incoming from email gateway
It may make sense for organizations with geographically distributed branches
honestly having a new MTA makes no sense at all for me it is hard to impossible to beat out postfix/exim these days
the unix principle is have one tool for one job and let work the tools together
On Sun, Nov 10, 2013 at 12:59:27AM +0100, Reindl Harald wrote:
everywhere else you have sender-dependent relay hosts, RCPT dependent relayhosts and all sort of aliases which you *do not* want treated different between incoming mail from outside or a internal server and submission mail
the only real difference between submission is that it is authenticated and because the authentication a few restrictions are not applied
I don't quite agree. Our "smarthosts" has very little local knowledge about where to route messages. They only follow MX records. It's the incoming SMTP servers that has all the knowledge, and needs to be robust against millions of broken mailservers and spam-bots on the internet.
The fact that submission is authenticated is an opportunity to integrate better with the userdb than postfix and exim does. To have native quotas, brute-force protection, per user geo-blocking, etc.. that are difficult to achieve with the general SMTP servers.
but in usual there is and must not be any difference in the mail-routing
Incoming SMTP servers routes to dovecot-LMTP, internal exchange, and more. Outgoing would only need to follow MX (even for messages heading back home to us).
-jf
Hi Timo,
Am 08.11.2013 14:07, schrieb Timo Sirainen:
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of
...and there virtually nothing which could not be built with Postfix. Maybe a Postfix addon/proxy for easier integration of Dovecot would help. If I need a very fast MTA for e.g. a Raspberry based mail system I would prefer qmail as MTA.
My main design goals for the MTA are: ... hmm - I consider still to use Postfix as MTA, because it is a nightmare to replace all those MTA monitoring tools, log analyzer and other support tools. Did you asked Wietse for those improvements in Postfix?
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
To the risk to become off topic:
Please consider to add server side private/public key encryption for incoming mails. If client logs on, the password is used to unlock users server side private key. If mail arrives from MTA or any other source, mail is encrypted with users public key. Key pair should be located in LDAP or SQL server. PGP and S/MIME should be supported. This is for the situation if NSA or other organizations asks admin for users mail insistently, see http://xkcd.com/538/
A much better solution would be to improve IMAP protocol to allow user to use his client certificate not only for authentication on IMAP server but decrypt his mails also. Dovecot needs only public key and client does decryption.
This should not replace end-to-end encryption provided by enigmail etc.
Christian
Timo,
- Timo Sirainen dovecot@dovecot.org:
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of time to be able to create something that was anywhere even close to having Postfix's features. (I would shudder to even think about recreating Dovecot from scratch nowadays.) But slowly over time I've also been thinking of ways how things could be done a bit better, and I think I have enough ideas to start thinking about Dovecot MTA more seriously in a few more months (after my current busy schedule calms down a bit). And (unlike Dovecot!) I'm not planning on taking over the world with the MTA (or at least not very quickly), but it would definitely be useful for many installations I know of.
which problems would your MTA solve? I can't speak for Exim. The only functional shortcoming on the Postfix side I know of is its lack for URLAUTH support.
My main design goals for the MTA are:
- In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections.
Here in Germany (and with Postfix) we use the pre-queue smtpd_proxy_filter and the Sendmail MILTER API to process mail compliant with local jurisdiction. Usually you need that on the inbound side. On the submission side, where MUAs connect and users tend to complain that submission takes to long (message is scanned in session) the organizational context may allow to post-queue process such messages.
- In some cases you can't really avoid placing mails into a queue. This could be because of temporary failures or maybe because of an abnormal load spike. A mail queue in local disk isn't very nice though, because if the local disk dies, the queued mails are lost. Dovecot MTA will allow the queue to be in object storage and it will also likely support replication (similar to current dsync replication). In both of these cases if a server dies, another server can quickly take over its queue and continue handling it.
If the local disk dies it does not necessarily need to be lost if you mirror the message and a failover SMTP instance takes over and delivers the dead MTAs messages.
- Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not:
- Require DKIM configuration. All outgoing mails will be DKIM signed.
I agree. Every MTA should be required to DKIM-sign outgoing messages. But having a DKIM signature on outgoing messages is a policy and not a function.
I don't see the benefit to build an extra MTA for that. There already are several implementations out there that provide DKIM signing and verification and they hardly slow down an MTA.
- Require the domain’s DNS to contain _submission._tcp SRV record (and actually might as well require _imap._tcp too)
Are you referring to RFC 6186 http://tools.ietf.org/html/rfc6186? I consider that a MUA feature which helps users to setup their MUA easily and not something a MTA would benefit from. Besides I think Microsofts autodiscover and Mozillas autoconfig services that autoconfiguration to a much higher level. "SRV Records for Locating Email Submission/Access Services" can tell you where the service is, but they don't fix your login or tell you it is wrong - autodiscover and autoconfig can do that.
- Require SSL certificates to be configured and always allow remote to use STARTTLS
A policy not a functional deficit. Every reasonable MTA, I know of, can do that.
- Require DANE TLSA record to exist and match the server's configured SSL cert
A policy and a functional deficit. I'd say that's because currently DANE is in RFC draft status. Postfix snapshot can do that. Postfix 2.11, expected to be published in Q1/2014, will likely support it. I expect other MTAs to adopt DANE soon.
- Have very good (and strict?) DNSSEC support. If we know a remote server is supposed to have valid DNSSEC entries, but doesn't, fail to deliver mail entirely?
How would you know? A destination server policy? The only trustful way to automatically retrieve such a policy would be a DNSSEC query result, which won't work in this case because that DNSSEC status is what you are looking for. Sounds like a chicken-and-egg problem to me. :)
That leaves it to local policies noted in e.g. a map. Postfix 2.11 will support that by expanding its current smtp_tls_policy_maps parameter with the new 'dane-only' option:
dane-only Mandatory DANE TLS. The TLS policy for the destination is obtained via TLSA records in DNSSEC. If no TLSA records are found, or none are usable, no connection is made to the server. (...)
- Add a new DNS record that advertises this is a Dovecot MTA (or compatible). If such entry is found (especially when correctness is guaranteed by DNSSEC), the email sender can assume that certain features exist and work correctly. If they don't, it could indicate an attack and the mail sending should be retried later. This DNS record would of course be good to try to standardize.
Is this a variation of DANE? DANE for MUAs? It would be an MUA feature and not one to implement in the MTA, right?
I like the idea. But given the speed it takes MUA producers to adopt new standards I doubt we will see such a standard in widely deployed MUAs (Outlook, Mail, Thunderbird [dying project]) within reasonable time. Besides the impression I have that vendors are moving to webclients/web app solutions.
- Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them.
I understand the costs to implement features are low. That's good. What are the costs for admins to learn the new features. To me it seems (writing 'seems' on purpose, because I don't 'know') most of the features you proposed are policies and not features.
Current MTAs are/will be able to support the functionality required to enforce the policies you listed. If I am right about all this, then I'd conclude it would be more useful to create and publish a BCP document and - optionally - submit that to IETF. IIRC last time I spoke to Alexey he was looking for a BCP for IMAP.
- Try to implement as many existing interfaces as possible (e.g. Milter and various Postfix APIs like policy servers) so that it wouldn’t be necessary to reimplement all the tools and filters.
I would *love* IMAP - especially Dovecot - do adopt these filter APIs on the IMAP side - connection, session and content filters.
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
From what I have read I am not convinced a Dovecot MTA would implement anything that takes SMTP itself any further. I see pain, but no gain. ;)
You'd have an additional Dovecot product, which might make sense. But its not up to me to judge on that.
Personally, I would like Dovecot to add other protocols on top of its message store. But that's another story out of this discussions scope. :)
p@rick
-- [*] 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
On 08/11/2013 14:07, Timo Sirainen wrote:
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of time to be able to create something that was anywhere even close to having Postfix's features.
Hello Timo,
I don't want to put too much stop energy into this, and I'm not really in the position to tell you what to do with your time and energies, but I feel that the world does not need another MTA, and that most of your design goals can be very well accomplished with existing tools or minimal extensions to them.
At the same time I see here on the mailing list frequent reports of bugs in Dovecot that would have been quite easy to catch with more test coverage. Spending time and energies into extending unit and integration tests for the current Dovecot would IMHO be very well worth.
Additionally I feel that Dovecot documentation can see some love as well. Having the wiki as main source of documentation does not look very polished, compared, for example to the extremely good written and maintained Postfix documentation.
I know that designing something from scratch is much more catchy than polishing a mature project. At the same time realizing a MTA capable of replacing existing solutions in non trivial cases is probably that much work that the fun will end quickly :)
Just my two cents.
Best, Daniele
On 10.11.2013, at 20.00, Daniele Nicolodi daniele@grinta.net wrote:
At the same time I see here on the mailing list frequent reports of bugs in Dovecot that would have been quite easy to catch with more test coverage. Spending time and energies into extending unit and integration tests for the current Dovecot would IMHO be very well worth.
This is definitely something that’s going to improve in future, regardless of what other Dovecot features are going to be implemented.
Additionally I feel that Dovecot documentation can see some love as well. Having the wiki as main source of documentation does not look very polished, compared, for example to the extremely good written and maintained Postfix documentation.
I don’t know how to improve the current documentation. (Other than implementing the few missing man pages.) There is going to be a Dovecot book soon though, maybe that’ll help.
On 11/10/2013 08:04 PM, Timo Sirainen wrote:
On 10.11.2013, at 20.00, Daniele Nicolodi daniele@grinta.net wrote:
Additionally I feel that Dovecot documentation can see some love as well. Having the wiki as main source of documentation does not look very polished, compared, for example to the extremely good written and maintained Postfix documentation.
I don’t know how to improve the current documentation. (Other than implementing the few missing man pages.) There is going to be a Dovecot book soon though, maybe that’ll help.
How Dovecot documentation can be improved? Well, what I find extremely helpful from the Postfix documentation but cannot find the equivalent for Dovecot is: http://www.postfix.org/postconf.5.html
Wiki's are helpful, but a full list of all configuration parameters, how they work and, when applicable, how they are related to other parameters will likely help a lot of users.
-- Rob
On Mon, 11 Nov 2013, Rob Sterenborg (lists) wrote:
On 11/10/2013 08:04 PM, Timo Sirainen wrote:
On 10.11.2013, at 20.00, Daniele Nicolodi daniele@grinta.net wrote:
Additionally I feel that Dovecot documentation can see some love as well. Having the wiki as main source of documentation does not look very polished, compared, for example to the extremely good written and maintained Postfix documentation.
I don?t know how to improve the current documentation. (Other than implementing the few missing man pages.) There is going to be a Dovecot book soon though, maybe that?ll help.
How Dovecot documentation can be improved? Well, what I find extremely helpful from the Postfix documentation but cannot find the equivalent for Dovecot is: http://www.postfix.org/postconf.5.html
Wiki's are helpful, but a full list of all configuration parameters, how they work and, when applicable, how they are related to other parameters will likely help a lot of users.
My experience is wiki's and a lot of equivalent are sort of a scattershot approach to deal with specific issues. They don't work well as the formal documentation.
I'd like to see one structured manual that starts at a high level and works its way down into the details. I tend to be someone who likes to skim documentation looking for what I need. As a result, I'm not a fan of documentation that consists of lots of links elsewhere since that's difficult to skim.
Ideally, this structured manual would start with an overview of what Dovecot is and its major components (I consider the IMAP/POP server a separate component from the Dovecot LDA as each can be used independent of the other). From there more detail about each of the major components and how to use and configure them. From there, even more detail as needed.
In a note a few days ago, I said I don't know enough about Dovecot to write new documentation. But I realized there is an area I can help with which is reviewing it to help make sure it makes sense even to the neophyte. Review it and provide feedback to the author along the lines of "I have no clue what this means" where appropriate.
I think one of the problems that plagues documentation everywhere is a tendency to assume knowledge that the reader doesn't have. When you're too close to a project, you tend to forget that everyone doesn't know what you know. It's something I am sometimes guilty of in my full-time job when I send out an email saying something needs to be a priority without explaining why it needs to be a priority (assuming the recipient knows the why).
Writing good documentation is hard, no question about it. And it is very overlooked and undervalued many places.
-- Larry Stone lstone19@stonejongleux.com
On Nov 10, 2013, at 1:00 PM, Daniele Nicolodi daniele@grinta.net wrote:
On 08/11/2013 14:07, Timo Sirainen wrote:
I've never really wanted to create my own MTA, because I like Postfix quite a lot. And I always thought it would require a horribly lot of time to be able to create something that was anywhere even close to having Postfix's features.
Hello Timo,
I don't want to put too much stop energy into this, and I'm not really in the position to tell you what to do with your time and energies, but I feel that the world does not need another MTA, and that most of your design goals can be very well accomplished with existing tools or minimal extensions to them.
At the same time I see here on the mailing list frequent reports of bugs in Dovecot that would have been quite easy to catch with more test coverage. Spending time and energies into extending unit and integration tests for the current Dovecot would IMHO be very well worth.
I totally agree. I'm fairly new to Dovecot and am already quite cautious. Frequent new versions that always seem to have lots of bugs. Compare that to Postfix which has very infrequent new versions although lots of "snapshots" that are intermediate versions for those who want to test or really, really need a new feature.
This shows in the amount of traffic the Dovecot list generates compared to the Postfix list.
Additionally I feel that Dovecot documentation can see some love as well. Having the wiki as main source of documentation does not look very polished, compared, for example to the extremely good written and maintained Postfix documentation.
Agree here too. IMHO, the Dovecot documentation has become disjointed due to the feature creep that has made it into Dovecot.
As I said in a post back in March: "All of this said (and much of it not worth repeating), one problem that seems to affect all software as it grows is that as documentation is "patched" to describe new features, it becomes too complex for the new user who just wants to do something simple to figure how to do that simple stuff. For the user who has been along for the long ride since the software started, it makes sense but the new user is overwhelmed. Rewriting documentation is no easy task but it can help for someone to take a look at it the way a new user might who knows nothing about the software.
I don't know the history of Dovecot but my guess would be the Dovecot LDA was added after the Dovecot POP/IMAP server component. Why? Because the www.dovecot.org Overview says "Dovecot is an open source IMAP and POP3 email server for Linux/UNIX-like systems" without any mention of the Dovecot LDA anywhere on that front page. Longtime users know about the Dovecot LDA but they rarely read that first page and it's harder to notice something is missing than it is to notice something is wrong."
Timo said in his reply that he doesn't know how to improve the current documentation. I'll take him at his word. I submit that it really needs a total rewrite, not continued editing. And before someone suggests if I believe it needs to be rewritten, I should offer to do it myself, I will just say that I don't know anywhere near enough about Dovecot to do that. I use a very small subset of Dovecot's capability (I started with it as a drop-in replacement for UW-IMAP; other than Dovecot's authentication module, if UW-IMAP didn't do it, then I don't use that feature in Dovecot) and have no experience with the Dovecot LDA.
-- Larry Stone lstone19@stonejongleux.com http://www.stonejongleux.com/
On 11/10/2013 02:20 PM, Larry Stone wrote:
Timo said in his reply that he doesn't know how to improve the current documentation. I'll take him at his word. I submit that it really needs a total rewrite, not continued editing. And before someone suggests if I believe it needs to be rewritten, I should offer to do it myself, I will just say that I don't know anywhere near enough about Dovecot to do that. I use a very small subset of Dovecot's capability (I started with it as a drop-in replacement for UW-IMAP; other than Dovecot's authentication module, if UW-IMAP didn't do it, then I don't use that feature in Dovecot) and have no experience with the Dovecot LDA.
I also don't think I know enough about Dovecot to take it upon myself to document it in its entirety but I know I could help with the topics I do know. In general, I think the wiki can use more "prose" pages that would kind of introduce newcomers to some concepts. Currently many pages seem to get right down to the details, assuming the reader must already know what this is about otherwise why would he be here. And on the other hand, some pages are IMHO actually too terse and should be more detailed. So, my vote is the wiki could improve but there should be some agreement on what form it should take.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 10.11.2013 20:20, schrieb Larry Stone:
I totally agree. I'm fairly new to Dovecot and am already quite cautious. Frequent new versions that always seem to have lots of bugs. Compare that to Postfix which has very infrequent new versions although lots of "snapshots" that are intermediate versions for those who want to test or really, really need a new feature.
thats not a fair game, i agree postfix docs are done hyper well, but dovecot has to handle much more stuff and setups, also there is still need integrate more major features which are need in different config types/places, on postfix there isnt so much pressure for new features, so its by design of new feature integration, that there will be bugs, however i agree testing and release procedure needs to be "upgraded" some kind
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSgJG/AAoJEP8jBObu0LlEIp8IALPbb2st5/cMH6xgGAh+26V/ 9WX+U9KB09QkqtC8SbcspNw+efdzCEr2VYVOjT+O7ORSgnbCP6nwU1qFkxeqJ6GK BUj8wpgKJ6122aKlP21SSxJ+uU7ZV5SiDMwWIZtgtz9T5iyqUHFmgPGkTU2h6Xeq 2sFaHi1D5qrnem9VIJnZ5s0wpipF+CdzW1oyznm9hJCKtc1wPDtdPaxUcH7mm52Q JNS7o5U32+Uk5PHQj9nqbKWyewNv+5j/7VLsxDUIW9SWo5kNC9aUMWo0ew3GJlfS zkBeZJ1bMzPtc7ktb07055MqCxlUix2wDmVQaHMJ/JcS6bLXExkzBif7x3ldGdI= =M3ys -----END PGP SIGNATURE-----
Timo Sirainen skrev den 2013-11-08 14:07:
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
why is users not just change from postfix/dovecot to currier-* ?
its imho much better :)
On 11/10/2013 14:15, Benny Pedersen wrote:
Timo Sirainen skrev den 2013-11-08 14:07:
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
why is users not just change from postfix/dovecot to currier-* ?
its imho much better :)
Shh, don't start a holy war. :)
-- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. It is not logical. Please don't CC me! I'm subscribed to whatever list I just posted on.
On 10 Nov 2013, at 12:15 , Benny Pedersen me@junc.eu wrote:
Timo Sirainen skrev den 2013-11-08 14:07:
So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions?
why is users not just change from postfix/dovecot to currier-* ?
I switched FROM courier for two reasons:
- Dovecot authentication was a lot easier to deal with
and mostly
- Dovecot is soooo much faster.
-- "If you can't do something smart, do something right."
LuKreme skrev den 2013-11-11 11:06:
I switched FROM courier for two reasons:
- Dovecot authentication was a lot easier to deal with
currier authlib was hard ?
one only need to use saslauthd with -r imap, if i remember, or setup cyrus-sasl up with currier authsocket, not a problem on gentoo
and mostly 2) Dovecot is soooo much faster.
breaks faster ?
participants (30)
-
Aleksey Tsvetkov
-
Andrzej A. Filip
-
Arkadiusz Miśkiewicz
-
Benny Pedersen
-
Charles Marcus
-
Christian Felsing
-
Daniel Reinhardt
-
Daniele Nicolodi
-
Darren Pilgrim
-
Edwardo Garcia
-
Gedalya
-
Heiko Schlichting
-
Jan-Frode Myklebust
-
Larry Stone
-
LuKreme
-
Martin Rabl
-
Michael Kliewe
-
Nick Edwards
-
Noel Butler
-
Odhiambo Washington
-
Patrick Ben Koetter
-
Reindl Harald
-
Rob Sterenborg (lists)
-
Robert Schetterer
-
Ron Leach
-
Stan Hoeppner
-
staticsafe
-
Timo Sirainen
-
Tom Hendrikx
-
WJCarpenter