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 at 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
Very interesting.. a few questions if I may? On 11/08/2013 08:07 AM, Timo Sirainen 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.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 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? >
-----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-----
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 at 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 11/8/2013 7:07 AM, Timo Sirainen wrote:> I've never really wanted to create my own MTA, because I like PostfixAnd 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
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 at 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:[...]> * 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.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.
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 at 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 STARTTLSA 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 certA 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 316 bytes Desc: Digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20131110/6f795eaf/attachment-0001.bin>
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
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 :) http://www.courier-mta.org/
Timo Sirainen wrote: > 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. :) True ... If I try to make a wish list for features many of them requires fixing the IMAP protocol it self. (Like not having the folder display name being the unique identifier) Which reminds me that the IMAP5 process (if there ever was one) seems to be slowed to a halt. Now, there's a task for a developer looking for something to do ;-) /Peter