[Dovecot] Dovecot MTA

[Patrick Ben Koetter]

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 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 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>