Re: [Dovecot] Dovecot MTA
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
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
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] Question about folder sharing
Am 08.11.2013 01:25, schrieb Achim Gottinger:
Hi,
I run dovecot (2.1.7) on debian wheezy in conjuniction with postfix,
samba4 (as ldap backend) and sogo. I configured folder sharing but
have an few issues.
With my current config users can share the inbox and other folders. If
the acl allows creatings subfolders this does work for all folders
beside inbox.
What i want to archiev is the following:
If an user shares his inbox, others should be able to create
subfolders and those should inherit the inboxe's acl. All subfolders
of inbox should appear as folders at root level and not as subfolders
of the inbox.
I thought this can be done by setting the prefix of namespace inbox to
INBOX/. I did this and changed the IMAP Server Folder setting in
thunderbird to INBOX (like it was earlier when i used courier). Now
subfolders created at rootlevel or as subfolders of the inbox appear
on rootlevel in thunderbird but they do not inherit the acl's from
inbox. Is there an way to achive this?
doveconf -n
mail_location = maildir:/home/vmail/%u/mail
namespace {
list = children
location =
maildir:/home/vmail/%%u/mail:INDEX=/home/vmail/%u/mail/shared/%%u
prefix = shared/%%u/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location = maildir:/home/vmail/%u/mail
prefix =
separator = /
type = private
}
userdb {
args = /etc/dovecot/dovecot-ldap-userdb.conf.ext
driver = ldap
}
userdb {
args = /etc/dovecot/dovecot-ldap-userdb-groups.conf.ext
driver = ldap
}
I changed the location of the inbox like this
mail_location = maildir:/home/vmail/%u/mail:INBOX=
/home/vmail/%u/mail/.Inbox
namespace {
list = children
location =
maildir:/home/vmail/%%u/mail:INDEX=/home/vmail/%u/mail/shared/%%u:INBOX=
/home/vmail/%%u/mail/.Inbox
prefix = shared/%%u/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location = maildir:/home/vmail/%u/mail:INBOX= /home/vmail/%u/mail/.Inbox
prefix =
separator = /
type = private
}
Also exteded my ldap queries to return the correct mail variable
(=mail=/home/vmail/%u/mail:INBOX=/home/vmail/%u/mail/.Inbox).
Now an dovecot-acl inside /home/vmail/%u/mail gets used for newly
created subfolders, which is very helpful. However if i share an users
inbox now the hierarchie looks like this for an user with access.
shared/user
shared/user/Inbox
shared/user/INBOX
All three folders point to user's inbox. If i set
mail_shared_explicit_inbox=yes "shared/user" is greyed out but the other
two folders remain. Can someone here tell me what i did wrong to have
three verisons of the inbox now?
Thanks in advance
achim~
Re: [Dovecot] Question about folder sharing
Am 09.11.2013 11:48, schrieb Achim Gottinger:
Am 08.11.2013 01:25, schrieb Achim Gottinger:
Hi,
I run dovecot (2.1.7) on debian wheezy in conjuniction with postfix,
samba4 (as ldap backend) and sogo. I configured folder sharing but
have an few issues.
With my current config users can share the inbox and other folders.
If the acl allows creatings subfolders this does work for all folders
beside inbox.
What i want to archiev is the following:
If an user shares his inbox, others should be able to create
subfolders and those should inherit the inboxe's acl. All subfolders
of inbox should appear as folders at root level and not as subfolders
of the inbox.
I thought this can be done by setting the prefix of namespace inbox
to INBOX/. I did this and changed the IMAP Server Folder setting in
thunderbird to INBOX (like it was earlier when i used courier). Now
subfolders created at rootlevel or as subfolders of the inbox appear
on rootlevel in thunderbird but they do not inherit the acl's from
inbox. Is there an way to achive this?
doveconf -n
mail_location = maildir:/home/vmail/%u/mail
namespace {
list = children
location =
maildir:/home/vmail/%%u/mail:INDEX=/home/vmail/%u/mail/shared/%%u
prefix = shared/%%u/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location = maildir:/home/vmail/%u/mail
prefix =
separator = /
type = private
}
userdb {
args = /etc/dovecot/dovecot-ldap-userdb.conf.ext
driver = ldap
}
userdb {
args = /etc/dovecot/dovecot-ldap-userdb-groups.conf.ext
driver = ldap
}
I changed the location of the inbox like this
mail_location = maildir:/home/vmail/%u/mail:INBOX=
/home/vmail/%u/mail/.Inbox
namespace {
list = children
location =
maildir:/home/vmail/%%u/mail:INDEX=/home/vmail/%u/mail/shared/%%u:INBOX=
/home/vmail/%%u/mail/.Inbox
prefix = shared/%%u/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location = maildir:/home/vmail/%u/mail:INBOX=
/home/vmail/%u/mail/.Inbox
prefix =
separator = /
type = private
}
Also exteded my ldap queries to return the correct mail variable
(=mail=/home/vmail/%u/mail:INBOX=/home/vmail/%u/mail/.Inbox).
Now an dovecot-acl inside /home/vmail/%u/mail gets used for newly
created subfolders, which is very helpful. However if i share an users
inbox now the hierarchie looks like this for an user with access.
shared/user
shared/user/Inbox
shared/user/INBOX
All three folders point to user's inbox. If i set
mail_shared_explicit_inbox=yes "shared/user" is greyed out but the
other two folders remain. Can someone here tell me what i did wrong to
have three verisons of the inbox now?
Thanks in advance
achim~
Changed .Inbox to .INBOX now there is only one folder named INBOX
visible. The ACL's from /home/vmail/%u/mail are used for all subfolders
under ../mail no matter if they have an dovecot-acl file inside or not.
Can not find this documented, it's useful in my case but is it supposed
to work like that? Nice thing is i can create root-level folders for
users with an mail_location configured like that in the shared subsections.
Re: [Dovecot] Replication on v2.2.6 - I'm stuck (again)
Hi, Does anyone have any ideas? I need to iron out these few remaining issues before I deploy this into production... -Mark > On 5 Nov 2013, at 10:01 am, IT geek 31 wrote: > > Hi Timo, > > Thanks for the info. I've upgraded to v2.2.7 and made the change. Now I get: > > Nov 5 11:00:00 server1 dovecot: dsync-server(mark): Error: Couldn't lock > /home/mark/.dovecot-sync.lock: Timed out after 30 seconds > Nov 5 11:00:02 server1 dovecot: dsync-local(mark): Error: Couldn't lock > /home/mark/.dovecot-sync.lock: Timed out after 30 seconds > > Also, I get a lot of errors about Dovecot trying to replicate mailboxes for > (system) users that don't have them. Is there any way to exclude users from > replication? > > > -Mark > > > >> On 3 November 2013 21:23, Timo Sirainen wrote: >> 1) Upgrade to v2.2.7 >> >> 2) Use: >> >> mail_replica = tcp:server2.mydomain.com >> >> On 3.11.2013, at 21.53, IT geek 31 wrote: >> >> > Hi Timo, >> > >> > Thanks for your response. >> > >> > Getting it to replicate over TCP is what I'm after. How do I tweak my >> > config to get it to do that? >> > >> > I followed http://wiki2.dovecot.org/Replication, but I've obviously taking >> > a wrong turn... >> > >> > >> > -Mark >> > >> > >> > On 2 November 2013 11:46, Timo Sirainen wrote: >> > On 30.10.2013, at 13.01, IT geek 31 wrote: >> > >> > > I'm trying to get Dovecot replication working between two servers. I >> > > didn't have much luck on v2.1.3, so after receiving advice from the list >> > > I >> > > have upgraded to v2.2.6. >> > > >> > > I now get the error: >> > > >> > > Oct 30 11:50:16 server1 dovecot: doveadm(mark): Error: user mark: Auth >> > > PASS >> > > lookup failed >> > > Oct 30 11:50:16 server2 dovecot: doveadm(mark): Error: sync: >> > > /var/run/dovecot/auth-userdb: passdb lookup failed (to see if user is >> > > proxied, because doveadm_port is set) >> > >> > I don’t think you need to have doveadm_port set, since you’re not >> > replicating over TCP. Remove it and it should just work? Anyway, it still >> > shouldn’t have failed, this fixes it: >> > >> > http://hg.dovecot.org/dovecot-2.2/rev/47848e9fc622 >> > >> > also this gives a bit better error message for the PASS lookup failure: >> > >> > http://hg.dovecot.org/dovecot-2.2/rev/9b45f6d20d9d >> > >> > >
Re: [Dovecot] Can't get sieve/managedsieve working
Hi with modern Thunderbird Versions you will need to use the daily snapshot of the Thunderbird SIEVE extension, since 0.2.2 doesn't work any more. Regards Daniel
Re: [Dovecot] Dovecot MTA
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
[Dovecot] Dovecot replication not redirecting if server is down
Hi everyone,
I'm running a test environment with a proxy in front of working
replication between two backends but redirecting in case of a
backend failure is not working.
Nov 09 21:03:59 imap-login: Error: proxy(m...@example.net):
connect(10.5.29.211, 143) failed: Connection refused (after 0 secs,
local=10.5.29.201:38333)
I appreciate any advice.
Regards
Patrick
Proxy:
# 2.2.7: /usr/local/etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.2
auth_debug = yes
auth_mechanisms = plain login
auth_verbose = yes
default_process_limit = 150
director_mail_servers = 10.5.29.211 10.5.29.212
director_servers = 10.5.29.201
director_user_expire = 5 mins
disable_plaintext_auth = no
lmtp_proxy = yes
log_path = /var/log/dovecot.log
mail_plugins = notify replication
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave
passdb {
args = proxy=y nopassword=y
driver = static
}
protocols = imap pop3 lmtp sieve
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service auth {
unix_listener auth-userdb {
user = dovecot
}
}
service director {
fifo_listener login/proxy-notify {
mode = 0666
}
inet_listener {
address = 10.5.29.201
port = 9090
}
unix_listener director-userdb {
mode = 0600
}
unix_listener login/director {
mode = 0666
}
}
service imap-login {
executable = imap-login director
}
service lmtp {
inet_listener lmtp {
address = 10.5.29.201
port = 24
}
}
service managesieve-login {
executable = managesieve-login director
inet_listener sieve {
port = 4190
}
}
service pop3-login {
executable = pop3-login director
}
service replicator {
unix_listener replicator-doveadm {
mode = 0600
}
}
ssl = no
protocol lmtp {
auth_socket_path = director-userdb
}
Backend 1:
# 2.2.7: /usr/local/etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.2
auth_debug = yes
auth_mechanisms = plain login
auth_verbose = yes
disable_plaintext_auth = no
dotlock_use_excl = no
doveadm_password = secret
doveadm_port = 12345
dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u
hostname = mb01.example.net
listen = 10.5.29.211
log_path = /var/log/dovecot.log
mail_debug = yes
mail_fsync = always
mail_gid = vmail
mail_home = /var/mail/%d/%n
mail_location = maildir:~/Maildir
mail_plugins = quota notify replication
mail_uid = vmail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave
mmap_disable = yes
namespace inbox {
inbox = yes
location =
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox Spamverdacht {
auto = subscribe
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix = INBOX.
separator = .
type = private
}
passdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
plugin {
mail_replica = tcp:10.5.29.212
quota = dict:User quota::file:%h/Maildir/dovecot-quota
quota_rule2 = INBOX.Trash:ignore
quota_warning = storage=90%% quota-warning 90 %u
quota_warning2 = storage=75%% quota-warning 75 %u
sieve = ~/.dovecot.sieve
sieve_after = /usr/local/etc/dovecot/sieve/sieve_after.sieve
sieve_default = /usr/local/etc/dovecot/sieve/default.sieve
sieve_dir = ~/sieve
}
postmaster_address = postmas...@example.net
protocols = imap pop3 lmtp sieve
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service auth {
unix_listener auth-userdb {
mode = 0666
user = vmail
}
}
service doveadm {
inet_listener {
port = 12345
}
}
service lmtp {
inet_listener lmtp {
address = 10.5.29.211
port = 24
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
service quota-warning {
executable = script /usr/local/etc/dovecot/quota_warning.sh
unix_listener quota-warning {
user = vmail
}
user = root
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0600
}
}
ssl = no
submission_host = mf01.example.net
userdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
protocol lmtp {
mail_plugins = quota notify replication sieve
}
protocol imap {
mail_max_userip_connections = 30
mail_plugins = quota notify replication imap_quota
}
Backend 2:
# 2.2.7: /usr/local/etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.2
auth_d
Re: [Dovecot] Dovecot MTA
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 MSA -> MTA
On 11/08/2013 02:07 PM, Timo Sirainen wrote: > [...] > So perhaps something like this could be done in time for Dovecot v2.4. Any > thoughts/ideas/suggestions? Have you considered creating SMTP MSA (port 587) server as "step one"? Making dovecot itself handle SMTP AUTH may help to better integrate dovecot with a few more MTA servers.
Re: [Dovecot] Dovecot MSA -> MTA
Am 10.11.2013 00:48, schrieb Andrzej A. Filip: > On 11/08/2013 02:07 PM, Timo Sirainen wrote: >> [...] >> So perhaps something like this could be done in time for Dovecot v2.4. Any >> thoughts/ideas/suggestions? > > Have you considered creating SMTP MSA (port 587) server as "step one"? > > Making dovecot itself handle SMTP AUTH may help to better integrate > dovecot with a few more MTA servers. hardly - only in very small environments this could work everywhere else you have sender-dependent relay hosts, RCPT dependent relayhosts and all sort of aliases which you *do not* want treated different between incoming mail from outside or a internal server and submission mail the only real difference between submission is that it is authenticated and because the authentication a few restrictions are not applied but in usual there is and must not be any difference in the mail-routing so no - make it complete or not at all signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Dovecot MSA -> Simple MTA -> MTA
On 11/10/2013 12:59 AM, Reindl Harald wrote: > > > Am 10.11.2013 00:48, schrieb Andrzej A. Filip: >> On 11/08/2013 02:07 PM, Timo Sirainen wrote: >>> [...] >>> So perhaps something like this could be done in time for Dovecot v2.4. Any >>> thoughts/ideas/suggestions? >> >> Have you considered creating SMTP MSA (port 587) server as "step one"? >> >> Making dovecot itself handle SMTP AUTH may help to better integrate >> dovecot with a few more MTA servers. > > hardly - only in very small environments this could work > > everywhere else you have sender-dependent relay hosts, RCPT dependent > relayhosts > and all sort of aliases which you *do not* want treated different between > incoming mail from outside or a internal server and submission mail > > the only real difference between submission is that it is authenticated > and because the authentication a few restrictions are not applied > > but in usual there is and must not be any difference in the mail-routing > > so no - make it complete or not at all Would "simple MTA" make more sense to you? * MSA * sending out via smart host * accepting incoming from email gateway It may make sense for organizations with geographically distributed branches.
Re: [Dovecot] Dovecot MSA -> Simple MTA -> MTA
Am 10.11.2013 01:29, schrieb Andrzej A. Filip: > On 11/10/2013 12:59 AM, Reindl Harald wrote: >> >> >> Am 10.11.2013 00:48, schrieb Andrzej A. Filip: >>> On 11/08/2013 02:07 PM, Timo Sirainen wrote: [...] So perhaps something like this could be done in time for Dovecot v2.4. Any thoughts/ideas/suggestions? >>> >>> Have you considered creating SMTP MSA (port 587) server as "step one"? >>> >>> Making dovecot itself handle SMTP AUTH may help to better integrate >>> dovecot with a few more MTA servers. >> >> hardly - only in very small environments this could work >> >> everywhere else you have sender-dependent relay hosts, RCPT dependent >> relayhosts >> and all sort of aliases which you *do not* want treated different between >> incoming mail from outside or a internal server and submission mail >> >> the only real difference between submission is that it is authenticated >> and because the authentication a few restrictions are not applied >> >> but in usual there is and must not be any difference in the mail-routing >> >> so no - make it complete or not at all > > Would "simple MTA" make more sense to you? > * MSA > * sending out via smart host > * accepting incoming from email gateway > > It may make sense for organizations with geographically distributed > branches honestly having a new MTA makes no sense at all for me it is hard to impossible to beat out postfix/exim these days the unix principle is have one tool for one job and let work the tools together signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Dovecot replication not redirecting if server is down
Hi Patrick the director does not check backends for availability. If one backend goes up or down, you need to instruct the director to add/remove this backend from its pool. You might be looking for a script named "poolmon" which does exactly this. Regards Daniel
Re: [Dovecot] Dovecot MTA
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
