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 <[email protected] > 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 <[email protected]> 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 > -- Daniel Reinhardt [email protected] http://www.cryptodan.net 301-875-7018(c) 410-455-0488(h)
