Re: [Dovecot] Dovecot MTA

[Reindl Harald]

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.rei...@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 "ab...@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



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

[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




--
Viele Grüße,

  Martin Rabl

Re: [Dovecot] Dovecot MTA

[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



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

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


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

Re: [Dovecot] Dovecot MTA

[Reindl Harald]

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



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

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

> On 2013-11-11 1:28 PM, 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 :)
> 
> 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/*

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-11 1:28 PM, 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 :)


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

Re: [Dovecot] Dovecot MTA

[Benny Pedersen]

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

Re: [Dovecot] Dovecot MTA

[Benny Pedersen]

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 !

Re: [Dovecot] Dovecot MTA

[Benny Pedersen]

LuKreme skrev den 2013-11-11 11:06:


I switched FROM courier for two reasons:
1) 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 s much faster.


breaks faster ?

Re: [Dovecot] Dovecot MTA

[Larry Stone]

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  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
   lston...@stonejongleux.com

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-11 8:17 AM, Tom Hendrikx  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 
' 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/*

Re: [Dovecot] Dovecot MTA

[Rob Sterenborg (lists)]

On 11/10/2013 08:04 PM, Timo Sirainen wrote:

On 10.11.2013, at 20.00, Daniele Nicolodi  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

Re: [Dovecot] Dovecot MTA

[Peter Mogensen]

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

Re: [Dovecot] Dovecot MTA

[Tom Hendrikx]

On 11/11/2013 01:59 PM, Timo Sirainen wrote:
> On 11.11.2013, at 13.29, Charles Marcus 
> wrote:
> 
>> On 2013-11-10 4:46 PM, Reindl Harald 
>> 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
> 
> 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
' 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



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 11.11.2013, at 13.29, Charles Marcus  wrote:

> On 2013-11-10 4:46 PM, Reindl Harald  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

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.

Re: [Dovecot] Dovecot MTA

[Jan-Frode Myklebust]

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

Re: [Dovecot] Dovecot MTA

[Reindl Harald]

Am 11.11.2013 12:42, schrieb Charles Marcus:
> On 2013-11-11 6:35 AM, Reindl Harald  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



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-11 6:35 AM, Reindl Harald  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/*

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-11 5:58 AM, Edwardo Garcia  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/*

Re: [Dovecot] Dovecot MTA

[Reindl Harald]

Am 11.11.2013 12:29, schrieb Charles Marcus:
> On 2013-11-10 4:46 PM, Reindl Harald  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...



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-11 12:24 AM, 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


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

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-10 4:46 PM, Reindl Harald  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/*

Re: [Dovecot] Dovecot MTA

[Edwardo Garcia]

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

Re: [Dovecot] Dovecot MTA

[LuKreme]

On 10 Nov 2013, at 12: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-* ?

I switched FROM courier for two reasons:

1) Dovecot authentication was a lot easier to deal with

and mostly

2) Dovecot is s much faster.

-- 
"If you can't do something smart, do something right."

Re: [Dovecot] Dovecot MTA

[Robert Schetterer]

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

Re: [Dovecot] Dovecot MTA

[Robert Schetterer]

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

Re: [Dovecot] Dovecot MTA

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

Timo pleaz reconsider feature


On Sun, Nov 10, 2013 at 4:21 PM, Nick Edwards wrote:

> On 11/9/13, Timo Sirainen  wrote:
> > On 9.11.2013, at 5.11, Nick Edwards  wrote:
> >
> >> On 11/9/13, Michael Kliewe  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
>

Re: [Dovecot] Dovecot MTA

[Reindl Harald]

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?



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

[Benny Pedersen]

Timo Sirainen skrev den 2013-11-10 21:38:

On 10.11.2013, at 21.24, Benny Pedersen  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

Re: [Dovecot] Dovecot MTA

[Reindl Harald]

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



signature.asc
Description: OpenPGP digital signature

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 10.11.2013, at 21.24, Benny Pedersen  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.

Re: [Dovecot] Dovecot MTA

[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, support postfix more in policy 
services

Re: [Dovecot] Dovecot MTA

[Gedalya]

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.

Re: [Dovecot] Dovecot MTA

[staticsafe]

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 :)
> 
> http://www.courier-mta.org/
> 
> 
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.

Re: [Dovecot] Dovecot MTA

[Larry Stone]

On Nov 10, 2013, at 1:00 PM, Daniele Nicolodi  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
lston...@stonejongleux.com
http://www.stonejongleux.com/





smime.p7s
Description: S/MIME cryptographic signature

Re: [Dovecot] Dovecot MTA

[Benny Pedersen]

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/

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 10.11.2013, at 20.00, Daniele Nicolodi  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.

Re: [Dovecot] Dovecot MTA

[Daniele Nicolodi]

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

Re: [Dovecot] Dovecot MTA

[Patrick Ben Koetter]

Timo,

* 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 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 ? 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 trus

Re: [Dovecot] Dovecot MTA

[Christian Felsing]

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

Re: [Dovecot] Dovecot MTA

[Nick Edwards]

On 11/9/13, Timo Sirainen  wrote:
> On 9.11.2013, at 5.11, Nick Edwards  wrote:
>
>> On 11/9/13, Michael Kliewe  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

Re: [Dovecot] Dovecot MTA

[Darren Pilgrim]

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.

Re: [Dovecot] Dovecot MTA

[Arkadiusz Miśkiewicz]

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

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 9.11.2013, at 5.11, Nick Edwards  wrote:

> On 11/9/13, Michael Kliewe  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.

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 9.11.2013, at 3.57, Stan Hoeppner  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.

Re: [Dovecot] Dovecot MTA

[Odhiambo Washington]

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

Re: [Dovecot] Dovecot MTA

[Nick Edwards]

On 11/9/13, Michael Kliewe  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.

Re: [Dovecot] Dovecot MTA

[Stan Hoeppner]

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

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 8.11.2013, at 21.47, Michael Kliewe  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. :)

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 8.11.2013, at 21.47, Michael Kliewe  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..

Re: [Dovecot] Dovecot MTA

[Michael Kliewe]

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

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-08 2:16 PM, WJCarpenter  wrote:

On 11/08/2013 10:46 AM, Charles Marcus wrote:

On 2013-11-08 1:35 PM, WJCarpenter  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/*

Re: [Dovecot] Dovecot MTA

[WJCarpenter]

On 11/08/2013 10:46 AM, Charles Marcus wrote:

On 2013-11-08 1:35 PM, WJCarpenter  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. :-)

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-08 1:35 PM, WJCarpenter  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/*

Re: [Dovecot] Dovecot MTA

[WJCarpenter]

On 11/08/2013 07:43 AM, Charles Marcus wrote:

On 2013-11-08 10:22 AM, Timo Sirainen  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. :-)

Re: [Dovecot] Dovecot MTA

[Heiko Schlichting]

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 SchlichtingFreie Universität Berlin
heiko.schlicht...@fu-berlin.de   Zentraleinrichtung für Datenverarbeitung
Telefon +49 30 838-54327 Fabeckstraße 32
Telefax +49 30 838454327 14195 Berlin

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-08 10:22 AM, Timo Sirainen  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/*

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 8.11.2013, at 16.15, Ron Leach  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.

Re: [Dovecot] Dovecot MTA

[Ron Leach]

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

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 8.11.2013, at 16.12, Charles Marcus  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.patch

Re: [Dovecot] Dovecot MTA

[Charles Marcus]

On 2013-11-08 9:33 AM, Robert Schetterer  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/*

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 8.11.2013, at 15.33, Robert Schetterer  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.

Re: [Dovecot] Dovecot MTA

[Robert Schetterer]

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

Re: [Dovecot] Dovecot MTA

[Gedalya]

On 11/08/2013 08:39 AM, Timo Sirainen wrote:

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

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

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

Re: [Dovecot] Dovecot MTA

[Timo Sirainen]

On 8.11.2013, at 14.31, Daniel Reinhardt  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.

Re: [Dovecot] Dovecot MTA

[Gedalya]

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.

Re: [Dovecot] Dovecot MTA

[Daniel Reinhardt]

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  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
crypto...@cryptodan.net
http://www.cryptodan.net
301-875-7018(c)
410-455-0488(h)

Re: [Dovecot] Dovecot MTA

[Gedalya]

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 t

Re: [Dovecot] Dovecot MTA

[Aleksey Tsvetkov]

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

[Dovecot] Dovecot MTA

[Timo Sirainen]

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?