Re: [Dovecot] how to calculate mail storage/traffic used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 8 Nov 2013, Götz Reinicke - IT Koordinator wrote: We have to setup a server which gets a copy of all messages send and received by our mailserver as a 1:1 copy. Mails send to multiple recipients should be calculated and saved per user. (great if you usually have lost of mails send to groups of people.) So no dedublication should be used here. (e.g. save the message and refer the different recipients to it.) How can I calculate the current traffic in the best way to extrapolate the amount of space to be planed for the new server? I would check your MTA logs, if you get the size of the message and the [number of] recipients. Do you really want to store outgoing mails, too? In mailboxes accessable by IMAP or the like? - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUnyb113r2wJMiz2NAQKSlwf/Z9U211qwC8QFfsweEcP7pOuhB8pJySio TfEZnFZHkr7wpyXNcJ/9o0lTmb2/LTHz1Z6o88l7ejqG8Ni6DZr/45/icX1yKZ/x Mi9Xz0tHgVN1yfDShS9ghJrMFtN87vH/49vG98aY9149m6K1b5m5d5nwBv8ctwWq KwLHk3IlW6nH41T1jrJqA2GKAFvLrLg6qvUDs3SoEoNSyKlrN3RCeiobWTGgbAaC lh3CtUCfzSP3T6qo5ZLeOCffqpl1YdAGuD5/691pGmn6pgFCSCS9LeOuuclH2Itz w+j4MtUmcdThmiOn3IbzD+KTgJCOLt1UA2v89tbS3QGK5JYOEYF4pQ== =jcui -END PGP SIGNATURE-
Re: [Dovecot] how to calculate mail storage/traffic used
Am 08.11.13 09:07, schrieb Steffen Kaiser: On Fri, 8 Nov 2013, Götz Reinicke - IT Koordinator wrote: We have to setup a server which gets a copy of all messages send and received by our mailserver as a 1:1 copy. Mails send to multiple recipients should be calculated and saved per user. (great if you usually have lost of mails send to groups of people.) So no dedublication should be used here. (e.g. save the message and refer the different recipients to it.) How can I calculate the current traffic in the best way to extrapolate the amount of space to be planed for the new server? I would check your MTA logs, if you get the size of the message and the [number of] recipients. Do you really want to store outgoing mails, too? In mailboxes accessable by IMAP or the like? Hi, no, we have to put all messages in ELM / singel file format on to a networkshare to be collected and processed by a document management system. We need in and out mails to be saved. I know there are better/other solutions including good dedublication for mail archiving, but thats how it works. Cheers . Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 82 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzender des Aufsichtsrats: Jürgen Walter MdL Staatssekretär im Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg Geschäftsführer: Prof. Thomas Schadt smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.11.2013 19:30, schrieb Michael Grimm: Timo Sirainen t...@iki.fi wrote: Sorry, but neither my log files starting a week ago ... More interesting would be to know if you see ANY error/warning messages in Dovecot logs (Fatal, Panic, Error, Warning). ... nor ... You’ll also see the last 1000 error messages since dovecot started with “doveadm log errors”. ... show any messages, none. This is 2.2.7 (775b1e025939). Regards, Michael Same here, no errors or any logs. Only since 2.2.7. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSfKnPAAoJENEKhqzzuxPlWb8H/05dv4jQASaIYyKUi5CPRpNO /TXkUKBwqOVgGBo5mxW06ppfao6zICfEYQUS+Xk131CugXkfamCiFaZD/lHaa5ib dOz8wGuJuuZ9VXw4+J4GXpAIcxhV9OFNibehzpeHTmFe/1SmtS3iHoan85hHNqc6 cDcdCet7fF56yYBGcGNCf1uQvCxgVWcvKZ2QkyP6MfoOay8g88J1V+Di9iJTJzXz 9899lcWl8w2I6vUaexaw2o63s19POsjLHVbx7BPvDtF0ohG960yfGxIJ7qDTX3Kn D0AOIUanmsGgdXifUudJlMfh2KKAXuOhgHYa5ODM42g+8QNSKRddmQla5ARoSqw= =RPY6 -END PGP SIGNATURE-
[Dovecot] Problem with master user
Hello.
I have problem as below:
Nov 8 10:41:52 store1 dovecot: auth: Debug:
auth(mas...@example.com,::1,master,/qEuMafqyAAB):
Master user lookup for login: jkr...@example.com
Nov 8 10:41:52 store1 dovecot: auth: Debug:
passwd-file(mas...@example.com,::1,master,/qEuMafqyAAB):
lookup: user=mas...@example.com file=/etc/dovecot/master-use
rs
Nov 8 10:41:52 store1 dovecot: auth: Debug:
password(mas...@example.com,::1,master,/qEuMafqyAAB):
Generating DIGEST-MD5 from user 'master', password 'test'
Nov 8 10:41:52 store1 dovecot: auth:
passdb(mas...@example.com,::1,master,/qEuMafqyAAB): Master
user logging in as jkr...@example.com
Nov 8 10:41:52 store1 dovecot: auth: Debug:
ldap(jkr...@example.com,::1,/qEuMafqyAAB): pass
search: base=dc=example,dc=com scope=subtree filter=((locMailActive=TRUE)(|
(uid=jkr...@example.com)(uid=jkrzyz)(mailRoutingAddress=jkr...@example.com)))
fields=mailRoutingAddress,userPassword
Nov 8 10:41:52 store1 dovecot: auth: Debug:
ldap(jkr...@example.com,::1,/qEuMafqyAAB): result:
mailRoutingAddress=jkr...@example.com userPassword=test2
Nov 8 10:41:52 store1 dovecot: auth: Debug:
password(jkr...@example.com,::1,/qEuMafqyAAB):
Generating DIGEST-MD5 from user 'master', password 'test2'
Nov 8 10:41:52 store1 dovecot: auth: Debug:
password(jkr...@example.com,::1,/qEuMafqyAAB):
Credentials: d64221d543d7c9a809c7d6e424d87be8
Nov 8 10:41:52 store1 dovecot: auth:
digest-md5(jkr...@example.com,::1,/qEuMafqyAAB):
password mismatch
As you can see, password is check against user passdb and not
passwd-file, where master's password is stored.
Test is password of master user, test2 is password of jkrzyz
Setting pass=yes or no makes no difference.
What is wrong with my config?
dovecot --version
2.1.7
dovecot.conf snippet:
passdb {
args = scheme=PLAIN /etc/dovecot/master-users
driver = passwd-file
master = yes
pass = yes
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
userdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
/etc/dovecot/master-users:
master:{PLAIN}test
mas...@example.com:{PLAIN}test
Re: [Dovecot] how to calculate mail storage/traffic used - SOLVED
SendmailAnalyzer http://sareport.darold.net/index.html collects all Messaging flows like total incomming/outgoing and size in sum and average. and it has a graphic web interface ;) /Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 82 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzender des Aufsichtsrats: Jürgen Walter MdL Staatssekretär im Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg Geschäftsführer: Prof. Thomas Schadt smime.p7s Description: S/MIME Cryptographic Signature
[Dovecot] Dovecot MTA
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?
Re: [Dovecot] Dovecot MTA
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 t...@iki.fi 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
Re: [Dovecot] Dovecot MTA
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
Re: [Dovecot] Dovecot MTA
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
On 8.11.2013, at 14.31, Daniel Reinhardt crypto...@gmail.com 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
On 8.11.2013, at 14.29, Gedalya geda...@gedalya.net wrote: * In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections. This is basically what I normally do with exim, and I believe it can be achieved with postfix, so basically your point is a single asynchronous smtpd for multiple connections? But can you (easily) configure them so that pre-queue filtering happens normally, except under heavy load it would automatically switch to post-queue filtering to avoid temporarily rejecting mails? My experience has been that the real problem with SMTP-time decision making is the concurrency of the extremely heavy (e.g.) spamassassin processes, heavy in both memory and CPU, and I/O if you use bayes which you should. Yeah. In cloud(-like) environments the idea is also that Antispam/virus instances could be started and stopped on the automatically on the fly as needed. * Dovecot MTA is a new product, which means we can add some requirements to how it's being used, especially related to securely sending emails between servers. It could do a bunch of checks at startup and fail to even start if everything isn't correct. Here are some things I had in mind - not sure if all of these are good ideas or not: They are all good ideas as long as these requirements can be turned off per site :-) That was kind of the idea, that some of these couldn’t be turned off :) So the idea being that Dovecot MTA would slowly start making email a secure communication method. * Configuration: It would take years to implement all of the settings that Postfix has, but I think it's not going to be necessary. In fact I think the number of new settings to dovecot.conf that Dovecot MTA requires would be very minimal. Instead nearly all of the configuration could be done using Sieve scripts. We'd need to implement some new MTA-specific Sieve extensions and a few core features/configurations/databases that the scripts can use, but after that there wouldn't be really any limits to what could be done with them. It comes to mind that you would want a separate master process for this in case one would run it on the same box with dovecot imap. Or at least a way to restart/reconfigure it separately. You could run two Dovecot instances if you wanted to. But I have also some plans for making it possible to restart/upgrade Dovecot without losing any existing connections.
Re: [Dovecot] Dovecot MTA
On 11/08/2013 08:39 AM, Timo Sirainen wrote: On 8.11.2013, at 14.29, Gedalya geda...@gedalya.net wrote: * In normal load don't queue mails, just continue delivering the mail through different processes/services until it succeeds or fails, and only after that return ok/failure to the SMTP client. So there's no (forced) post-queue filtering, everything would normally happen pre-queue. This is required because in Germany (and EU in general?) you aren't allowed to just drop spams after SMTP server has responsed OK to the client, even if you’re 100% sure it’s a spam. So this would also mean that the SMTP DATA replies will come more slowly, which means that the SMTP server must be able to handle a lot more concurrent SMTP connections, which means that in large installations the smtpd process must be able to asynchronously handle multiple SMTP client connections. This is basically what I normally do with exim, and I believe it can be achieved with postfix, so basically your point is a single asynchronous smtpd for multiple connections? But can you (easily) configure them so that pre-queue filtering happens normally, except under heavy load it would automatically switch to post-queue filtering to avoid temporarily rejecting mails? 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
-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
On 8.11.2013, at 15.33, Robert Schetterer r...@sys4.de 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
On 2013-11-08 9:33 AM, Robert Schetterer r...@sys4.de 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
On 8.11.2013, at 16.12, Charles Marcus cmar...@media-brokers.com 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
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
On 8.11.2013, at 16.15, Ron Leach ronle...@tesco.net 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] Problem with master user
doveconf -n output is ordinarily required
however, at a guess, you have not defined auth_master_user_separator
On 08/11/2013 20:05, Jakub Krzyżewski wrote:
Hello.
I have problem as below:
Nov 8 10:41:52 store1 dovecot: auth: Debug:
auth(mas...@example.com,::1,master,/qEuMafqyAAB):
Master user lookup for login: jkr...@example.com
Nov 8 10:41:52 store1 dovecot: auth: Debug:
passwd-file(mas...@example.com,::1,master,/qEuMafqyAAB):
lookup: user=mas...@example.com file=/etc/dovecot/master-use
rs
Nov 8 10:41:52 store1 dovecot: auth: Debug:
password(mas...@example.com,::1,master,/qEuMafqyAAB):
Generating DIGEST-MD5 from user 'master', password 'test'
Nov 8 10:41:52 store1 dovecot: auth:
passdb(mas...@example.com,::1,master,/qEuMafqyAAB):
Master user logging in as jkr...@example.com
Nov 8 10:41:52 store1 dovecot: auth: Debug:
ldap(jkr...@example.com,::1,/qEuMafqyAAB): pass
search: base=dc=example,dc=com scope=subtree
filter=((locMailActive=TRUE)(|
(uid=jkr...@example.com)(uid=jkrzyz)(mailRoutingAddress=jkr...@example.com)))
fields=mailRoutingAddress,userPassword
Nov 8 10:41:52 store1 dovecot: auth: Debug:
ldap(jkr...@example.com,::1,/qEuMafqyAAB):
result: mailRoutingAddress=jkr...@example.com userPassword=test2
Nov 8 10:41:52 store1 dovecot: auth: Debug:
password(jkr...@example.com,::1,/qEuMafqyAAB):
Generating DIGEST-MD5 from user 'master', password 'test2'
Nov 8 10:41:52 store1 dovecot: auth: Debug:
password(jkr...@example.com,::1,/qEuMafqyAAB):
Credentials: d64221d543d7c9a809c7d6e424d87be8
Nov 8 10:41:52 store1 dovecot: auth:
digest-md5(jkr...@example.com,::1,/qEuMafqyAAB):
password mismatch
As you can see, password is check against user passdb and not
passwd-file, where master's password is stored.
Test is password of master user, test2 is password of jkrzyz
Setting pass=yes or no makes no difference.
What is wrong with my config?
dovecot --version
2.1.7
dovecot.conf snippet:
passdb {
args = scheme=PLAIN /etc/dovecot/master-users
driver = passwd-file
master = yes
pass = yes
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
userdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
/etc/dovecot/master-users:
master:{PLAIN}test
mas...@example.com:{PLAIN}test
Re: [Dovecot] Dovecot MTA
On 2013-11-08 10:22 AM, Timo Sirainen t...@iki.fi 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
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
On 11/08/2013 07:43 AM, Charles Marcus wrote: On 2013-11-08 10:22 AM, Timo Sirainen t...@iki.fi 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
On 2013-11-08 1:35 PM, WJCarpenter bill-dove...@carpenter.org 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
On 11/08/2013 10:46 AM, Charles Marcus wrote: On 2013-11-08 1:35 PM, WJCarpenter bill-dove...@carpenter.org 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
On 2013-11-08 2:16 PM, WJCarpenter bill-dove...@carpenter.org wrote: On 11/08/2013 10:46 AM, Charles Marcus wrote: On 2013-11-08 1:35 PM, WJCarpenter bill-dove...@carpenter.org 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
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
[Dovecot] Can't get sieve/managedsieve working
Hi,
I am running dovecot 2.1.7 for a while, with roundcube webmail frontend
0.9.5 . Now I wanted to add sieve to filter mails. Unfortunately most
tutorials are for dovecot 1.x but I'm running dovecot 2 on debian
wheezy.
I could upload some scripst with sieve-connect, checked and activated
them. When I try to edit filters with thunderbird sieve plugin 0.2.2
nothing happens. If I try to edit filters with roundcube managesieve
plugin nothing happens, too, but I get some errors in logfile:
roundcube: Authentication failed. (3)
roundcube: Not currently in AUTHORISATION stata (1):
Can someone help me, to get it running?
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.6.11+ armv6l Debian 7.2
auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
auth_verbose_passwords = plain
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
listen = *
mail_location = mbox:~/mail:INBOX=/var/mail/%u
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
namespace {
inbox = yes
location =
mailbox {
special_use = \Drafts
name = Drafts
}
mailbox {
special_use = \Junk
name = Junk
}
mailbox {
special_use = \Sent
name = Sent
}
mailbox {
special_use = \Sent
name = Sent Messages
}
mailbox {
special_use = \Trash
name = Trash
}
prefix =
name = inbox
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
postmaster_address = stefan@localhost
protocols = imap sieve
service replication-notify-fifo {
name = aggregator
}
service anvil-auth-penalty {
name = anvil
}
service auth-worker {
name = auth-worker
}
service auth-client {
name = auth
}
service config {
name = config
}
service dict {
name = dict
}
service login/proxy-notify {
name = director
}
service dns-client {
name = dns_client
}
service doveadm-server {
name = doveadm
}
service imap {
name = imap-login
}
service login/imap {
name = imap
}
service indexer-worker {
name = indexer-worker
}
service indexer {
name = indexer
}
service ipc {
name = ipc
}
service lmtp {
name = lmtp
}
service log-errors {
name = log
}
service {
inet_listener {
port = 4190
name = sieve
}
name = managesieve-login
}
service login/sieve {
name = managesieve
}
service pop3 {
name = pop3-login
}
service login/pop3 {
name = pop3
}
service replicator {
name = replicator
}
service login/ssl-params {
name = ssl-params
}
service stats-mail {
name = stats
}
ssl_cert = /etc/ssl/certs/ssl-cert-raspi.pem
ssl_key = /etc/ssl/certs/ssl-cert-raspi.pem
userdb {
driver = passwd
}
protocol lmtp {
service replication-notify-fifo {
name = aggregator
}
service anvil-auth-penalty {
name = anvil
}
service auth-worker {
name = auth-worker
}
service auth-client {
name = auth
}
service config {
name = config
}
service dict {
name = dict
}
service login/proxy-notify {
name = director
}
service dns-client {
name = dns_client
}
service doveadm-server {
name = doveadm
}
service imap {
name = imap-login
}
service login/imap {
name = imap
}
service indexer-worker {
name = indexer-worker
}
service indexer {
name = indexer
}
service ipc {
name = ipc
}
service lmtp {
name = lmtp
}
service log-errors {
name = log
}
service sieve {
name = managesieve-login
}
service login/sieve {
name = managesieve
}
service pop3 {
name = pop3-login
}
service login/pop3 {
name = pop3
}
service replicator {
name = replicator
}
service login/ssl-params {
name = ssl-params
}
service stats-mail {
name = stats
}
}
protocol lda {
mail_plugins = sieve
service replication-notify-fifo {
name = aggregator
}
service anvil-auth-penalty {
name = anvil
}
service auth-worker {
name = auth-worker
}
service auth-client {
name = auth
}
service config {
name = config
}
service dict {
name = dict
}
service login/proxy-notify {
name = director
}
service dns-client {
name = dns_client
}
service doveadm-server {
name = doveadm
}
service imap {
name = imap-login
}
service login/imap {
name = imap
}
service indexer-worker {
name = indexer-worker
}
service indexer {
name = indexer
}
service ipc {
name = ipc
}
service lmtp {
name = lmtp
}
service log-errors {
name = log
}
service sieve {
name = managesieve-login
}
service login/sieve {
name = managesieve
}
service pop3 {
name = pop3-login
}
service login/pop3 {
name = pop3
}
service replicator {
name = replicator
}
service login/ssl-params {
name = ssl-params
}
service stats-mail {
name =
Re: [Dovecot] Can't get sieve/managedsieve working
Am 08.11.2013 22:19, schrieb Alter Depp: Hi, I am running dovecot 2.1.7 for a while, with roundcube webmail frontend 0.9.5 . Now I wanted to add sieve to filter mails. Unfortunately most tutorials are for dovecot 1.x but I'm running dovecot 2 on debian wheezy. I could upload some scripst with sieve-connect, checked and activated them. When I try to edit filters with thunderbird sieve plugin 0.2.2 nothing happens. If I try to edit filters with roundcube managesieve plugin nothing happens, too, but I get some errors in logfile: roundcube: Authentication failed. (3) roundcube: Not currently in AUTHORISATION stata (1): Can someone help me, to get it running? An wild guess but it may help if you define mail_home as well.
Re: [Dovecot] Can't get sieve/managedsieve working
Hi Alter,
On Fri, Nov 8, 2013 at 3:19 PM, Alter Depp alter.d...@gmx.de wrote:
Hi,
I am running dovecot 2.1.7 for a while, with roundcube webmail frontend
0.9.5 . Now I wanted to add sieve to filter mails. Unfortunately most
tutorials are for dovecot 1.x but I'm running dovecot 2 on debian wheezy.
I could upload some scripst with sieve-connect, checked and activated
them. When I try to edit filters with thunderbird sieve plugin 0.2.2
nothing happens. If I try to edit filters with roundcube managesieve plugin
nothing happens, too, but I get some errors in logfile:
roundcube: Authentication failed. (3)
roundcube: Not currently in AUTHORISATION stata (1):
Can someone help me, to get it running?
I've a similar design with Dovecot 2.1.7 and Roundcube 0.9.x. I'm using the
SieveRules plugin from JohnDoh and Pigeonhole in Dovecot.
I followed the wiki and everything worked fine, maybe this can help you:
http://wiki2.dovecot.org/Pigeonhole/
For example, my configs look something like:
#[...]
protocols = imap lmtp sieve
protocol lmtp {
mail_plugins = $mail_plugins sieve
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
service_count = 1
}
#[...]
Regards,
Manuel Delgado
---
*Usuario Linux* *#520940 http://counter.li.org/*
Bach. Computación e Informática
Universidad de Costa Rica
Re: [Dovecot] Dovecot MTA
On 8.11.2013, at 21.47, Michael Kliewe mkli...@gmx.de 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
On 8.11.2013, at 21.47, Michael Kliewe mkli...@gmx.de 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. :)
[Dovecot] Problems with dovecot 2.1.7, spamassassin 3.3.2 and antispam plugin
This might be a fairly long message, but I wanted to be sure to include as much information as possible. I'm having an issue with the dovecot-antispam plugin in that it seems to be unable to successfully run anything from the pipe backend. To qualify that, they run, but they fail ... Running /usr/bin/sa-learn directly always returns with an error code of 1, and the bayes DB isn't actually updated. Running the /usr/local/bin/sa-learn-pipe.sh script from the example will run sa-learn successfully, but sa-learn fails partway through, right on a sql DB access. I have both bayes and FuzzyOcr data stored in mysql, and the error occurs on accessing either one. That is, I've tested with FuzzyOcr enabled, and it fails on the db access to the FuzzyOcr DB, and I've tried it with FuzzyOcr disabled. In that case, it fails on the access to the bayes DB. The error line right there is : libgcc_s.so.1 must be installed for pthread_cancel to work Since sa-learn terminated prematurely, the bayes DB isn't updated at all. Running /usr/bin/sa-learn or the script /usr/local/bin/sa-learn-pipe.sh directly from cmdline works fine though - sa-learn completes correctly and updates the bayes DB properly, I can see the new tokens. $ sa-learn-pipe.sh --spam /usr/share/doc/spamassassin/examples/sample-spam.txt $ sa-learn --spam /usr/share/doc/spamassassin/examples/sample-spam.txt I think it would be great to have a dedicated logfile for antispam, one that would capture both stdout as well as stderr. These tests are being done on a clean Ubuntu 13.04 system. I'm rebuilding the VM repeatedly as I configure the various pieces, and can test any changes or whatever you might suggest very easily. I've fully scripted the install and configuration of Exim4, Dovecot, Spamassassin, Clamav, Percona/Mysql, Roundcube, and can build a full VM under Virtualbox or any VPS in less than 10 minutes. Ubuntu 13.04 Dovecot 2.1.7 dovecot-antispam2.0+20120225-3 Anyone else using the antispam plugin with spamassassin 3.3.2 ? Anything I can check to see what's causing this problem ? $ cat /usr/local/bin/sa-learn-pipe.sh #!/bin/bash echo /usr/bin/sa-learn $* /tmp/sendmail-msg-$$.txt echo $$-start ($*) /var/log/sa-learn-pipe.log cat0 /tmp/sendmail-msg-$$.txt /usr/bin/sa-learn -D $* /tmp/sendmail-msg-$$.txt /tmp/sa-learn-pipe.$$.log 21 echo $$ sa-learn rc=$? id=$(id) HOME=$HOME /var/log/sa-learn-pipe.log while read line; do echo $$-sa-learn $line /var/log/sa-learn-pipe.log done /tmp/sa-learn-pipe.$$.log rm -f /tmp/sendmail-msg-$$.txt echo $$-end /var/log/sa-learn-pipe.log exit 0 With FuzzyOcr DISabled, fails right after Bayes DB access $ cat /var/log/sa-learn-pipe.log 4505-start (--spam) 4505 sa-learn rc=134 id=uid=108(Debian-exim) gid=113(Debian-exim) groups=113(Debian-exim) HOME= 4505-sa-learn Nov 8 09:05:26.134 [4507] dbg: logger: adding facilities: all 4505-sa-learn Nov 8 09:05:26.134 [4507] dbg: logger: logging level is DBG 4505-sa-learn Nov 8 09:05:26.134 [4507] dbg: generic: SpamAssassin version 3.3.2 4505-sa-learn Nov 8 09:05:26.134 [4507] dbg: generic: Perl 5.014002, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin : : 4505-sa-learn Nov 8 09:05:27.131 [4507] dbg: replacetags: done replacing tags 4505-sa-learn Nov 8 09:05:27.131 [4507] dbg: FreeMail: loaded freemail_domains entries: 2470 normal, 29 wildcard 4505-sa-learn Nov 8 09:05:27.132 [4507] dbg: plugin: Mail::SpamAssassin::Plugin::Bayes=HASH(0x3879e88) implements 'learner_new', priority 0 4505-sa-learn Nov 8 09:05:27.132 [4507] dbg: bayes: learner_new self=Mail::SpamAssassin::Plugin::Bayes=HASH(0x3879e88), bayes_store_module=Mail::SpamAssassin::BayesStore::MySQL 4505-sa-learn Nov 8 09:05:27.151 [4507] dbg: bayes: using username: debian-spamd 4505-sa-learn Nov 8 09:05:27.151 [4507] dbg: bayes: learner_new: got store=Mail::SpamAssassin::BayesStore::MySQL=HASH(0x3ec0388) 4505-sa-learn Nov 8 09:05:27.152 [4507] dbg: plugin: Mail::SpamAssassin::Plugin::Bayes=HASH(0x3879e88) implements 'learner_is_scan_available', priority 0 4505-sa-learn libgcc_s.so.1 must be installed for pthread_cancel to work 4505-end 7235-start () With FuzzyOcr ENabled, fails right after FuzzyOcr DB access $ cat /var/log/sa-learn-pipe.log : : 7804-sa-learn Nov 8 09:37:09.612 [7806] info: FuzzyOcr: Using scan ocrad-invert: /usr/bin/ocrad -s5 -i $input 7804-sa-learn Nov 8 09:37:09.612 [7806] info: FuzzyOcr: Using scan ocrad-decolorize-invert: /usr/bin/ocrad -s5 -i $input 7804-sa-learn Nov 8 09:37:09.612 [7806] info: FuzzyOcr: Using scan ocrad-decolorize: /usr/bin/ocrad -s5 $input 7804-sa-learn Nov 8 09:37:09.612 [7806] info: FuzzyOcr: Using scan gocr: /usr/bin/gocr -i $input 7804-sa-learn Nov 8 09:37:09.612
[Dovecot] Dict client unescaping sieve script
I've created a dict service that listens on a unix socket and answers queries for sieve scripts (among other things). As I understand it (from the source code at http://hg.dovecot.org/dovecot-2.2/file/tip/src/lib-dict/dict-client.c), the dict client will unescape \001n, \001t, and \0011 to line feeds, tabs, and the \001 character respectively. In my service I am escaping those three characters in my response (if I don't escape them the line-oriented nature of the protocol causes a failure for multiline sieve scripts) but every time LDA attempts to process a sieve script I get an error in the logs (see below) showing sieve choking on \001 characters. Is there some configuration value I've missed or something? *dovecot log* Nov 8 23:04:54 www dovecot: lmtp(29940, j...@redacted.com): pxg7JxZufVL0dAAAPhZyyg: sieve: failed to compile script dict:proxy:/var/run/dovecot-auth.sock:sieve;name=main script (view user logfile /var/mail/vhosts/redacted.com/josh/.dovecot.sieve.log for more information) *.dovecot.sieve.log* sieve: info: started log at Nov 08 16:14:38. main script: line 1: error: unexpected character(s) starting with 0x01. main script: line 1: error: unexpected unknown characters found at (the presumed) end of file. main script: error: parse failed.
Re: [Dovecot] Dovecot MTA
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
On 11/9/13, Michael Kliewe mkli...@gmx.de 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.
