On 8.11.2013, at 14.29, Gedalya <geda...@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.
