[Dovecot] v2.2 status update: IMAP NOTIFY extension and more
v2.2 hg now has support for NOTIFY extension. The only thing missing is support for SubscriptionChange events. Now would be a good time for IMAP clients to start implementing and testing it. :) I remember K9 developers at least said they were just waiting for Dovecot to support it first.
v2.2 implements some other extensions also: BINARY, CATENATE and MOVE. Stephan has also implemented URLAUTH pretty far. Hopefully it gets finished in time for v2.2.0. I'll also try to implement the rest of the LEMONADE extensions: CONVERT, CONTEXT=SORT and URLAUTH=BINARY.
I'm also considering implementing an SMTP submission server, which works only as a proxy to the real SMTP server. The benefits of it would mainly be:
- It could support BURL command and other extensions required by LEMONADE. The real SMTP server would see only regular DATA commands.
- Would make SMTP AUTH easy to implement regardless of what the real SMTP server is.
- Timo Sirainen dovecot@dovecot.org:
I'm also considering implementing an SMTP submission server, which works only as a proxy to the real SMTP server. The benefits of it would mainly be:
- It could support BURL command and other extensions required by LEMONADE. The real SMTP server would see only regular DATA commands.
- Would make SMTP AUTH easy to implement regardless of what the real SMTP server is.
Nice move! Especially since I recall Wietse being not very inclined to implement anything alike.
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
On 2012-08-13 2:27 PM, Patrick Ben Koetter p@state-of-mind.de wrote:
- Timo Sirainendovecot@dovecot.org:
I'm also considering implementing an SMTP submission server, which works only as a proxy to the real SMTP server. The benefits of it would mainly be:
- It could support BURL command and other extensions required by LEMONADE. The real SMTP server would see only regular DATA commands.
- Would make SMTP AUTH easy to implement regardless of what the real SMTP server is.
Nice move! Especially since I recall Wietse being not very inclined to implement anything alike.
Amen to that!
This is a feature request I made a long time ago (I called it the dovecot LSA for Local Submission Agent), and I'm *very* glad that soon I'll be able to tell all my clients they can uncheck the 'Save copy of Sent messages' option for good... :)
Thanks Timo!!
--
Best regards,
Charles
On 13/08/2012 19:27, Patrick Ben Koetter wrote:
- Timo Sirainen dovecot@dovecot.org:
I'm also considering implementing an SMTP submission server, which works only as a proxy to the real SMTP server. The benefits of it would mainly be:
- It could support BURL command and other extensions required by LEMONADE. The real SMTP server would see only regular DATA commands.
- Would make SMTP AUTH easy to implement regardless of what the real SMTP server is. Nice move! Especially since I recall Wietse being not very inclined to implement anything alike.
Annoyingly Apple implemented burl for postfix, submitted the patch, but Wietse declined it (for reasons I would need to remind myself of - I think some implementation concerns, but mainly "who is using it, lets see the clients first")
I would also be very interested to see BURL support appear. It appears to offer bandwidth reductions (my customers are all on slow dialup links), and at least some apple clients (IOS?) support it
Cheers
Ed W
I'm also considering implementing an SMTP submission server, which works only as a proxy to the real SMTP server. The benefits of it would mainly be:
What would be really cool is if you also kept statistics on certain metrics, like how many emails a specific sender has sent. If this is done right, it could become a centralised spam sender back-off system over multiple smtp servers. Maybe something for the future. We now pay $$$$ for a commercial system that implements this.
Cor
On 16/08/2012 08:02, Cor Bosman wrote:
I'm also considering implementing an SMTP submission server, which works only as a proxy to the real SMTP server. The benefits of it would mainly be: What would be really cool is if you also kept statistics on certain metrics, like how many emails a specific sender has sent. If this is done right, it could become a centralised spam sender back-off system over multiple smtp servers. Maybe something for the future. We now pay $$$$ for a commercial system that implements this.
Postfix allows you to write policy agents very simply. I wrote a small perl utility which uses a database to count the number of emails a user has sent in the last 1 and 24 hours. Based on that we throttle users (I have some fudging for recipients per email also). If you like the idea then it's about 10 lines of perl (+ a decent chunk of boiler plate).
Ed
On 16.8.2012, at 10.02, Cor Bosman wrote:
I'm also considering implementing an SMTP submission server, which works only as a proxy to the real SMTP server. The benefits of it would mainly be:
What would be really cool is if you also kept statistics on certain metrics, like how many emails a specific sender has sent. If this is done right, it could become a centralised spam sender back-off system over multiple smtp servers. Maybe something for the future. We now pay $$$$ for a commercial system that implements this.
The submission servers would need to share state with each others to make this reliable. Some nosql database would work for that I guess (memcached?)
Can you describe more fully what you would want it to do and/or what the current system does? Probably not something I'll implement soon, but would be good to know for future :)
What would be really cool is if you also kept statistics on certain metrics, like how many emails a specific sender has sent. If this is done right, it could become a centralised spam sender back-off system over multiple smtp servers. Maybe something for the future. We now pay $$$$ for a commercial system that implements this.
The submission servers would need to share state with each others to make this reliable. Some nosql database would work for that I guess (memcached?)
Can you describe more fully what you would want it to do and/or what the current system does? Probably not something I'll implement soon, but would be good to know for future :)
They would indeed need to share the state, this is what the commercial system does (Cloudmark Gateway). The idea is to prevent senders to send email beyond certain limits that are configurable. Lets say, 200 emails in a minute, or 500 an hour, or whatever. Of course allowing for whitelists. With ever increasing speeds of residential connections (we have hundreds of fiber connections now, growing rapidly), these become very fast spam sources without something to keep them in check. It's easy on 1 server, not so easy if you have dozens of smtp servers.
But yes, something for a distant future :) And CM has other features as well, so it may not be so easy to replace :)
Cor
On 16/08/2012 09:11, Cor Bosman wrote:
What would be really cool is if you also kept statistics on certain metrics, like how many emails a specific sender has sent. If this is done right, it could become a centralised spam sender back-off system over multiple smtp servers. Maybe something for the future. We now pay $$$$ for a commercial system that implements this.
The submission servers would need to share state with each others to make this reliable. Some nosql database would work for that I guess (memcached?)
Can you describe more fully what you would want it to do and/or what the current system does? Probably not something I'll implement soon, but would be good to know for future :) They would indeed need to share the state, this is what the commercial system does (Cloudmark Gateway). The idea is to prevent senders to send email beyond certain limits that are configurable. Lets say, 200 emails in a minute, or 500 an hour, or whatever. Of course allowing for whitelists. With ever increasing speeds of residential connections (we have hundreds of fiber connections now, growing rapidly), these become very fast spam sources without something to keep them in check. It's easy on 1 server, not so easy if you have dozens of smtp servers.
But yes, something for a distant future :) And CM has other features as well, so it may not be so easy to replace :)
My opinion is that this is very easily to implement in at least Postfix and probably other servers, hence I would suggest this is a function for the MTA, not for the Dovecot relay?
What MTA are you using? If Postfix then there are several off the shelf solutions which control sending rates. As I said in a previous email, I wanted the rate to be configurable per user, and so we store the rates in our user database. It's then fairly trivial to write a small "policy server" to enforce whatever policies you wish, eg as well as rate limiting we have some control over whether users can "forge" their FROM address, etc. This all gets implemented in a small Perl based policy server
Effectively Postfix talks to a network socket for every email, passes a bunch of detail about the email and asks for a yes/no answer. Caveat the boiler plate to listen to a network socket the rest is just a couple of lines of code. Distributed, re-entrant, simple.
Give it some consideration. I doubt the time to implement a complete prototype solution would be more than half a day for your IT guy and if that's attractive then perhaps you have grounds to look at replacing CM?
Good luck
Ed W
On 2012-08-16 7:12 AM, Ed W lists@wildgooses.com wrote:
My opinion is that this is very easily to implement in at least Postfix and probably other servers, hence I would suggest this is a function for the MTA, not for the Dovecot relay?
Well, true enough for simpler installations, but integrating something like this in dovecot that can be applied across large dovecot director based farms might be a good thing.
Actually, maybe (and maybe not, I honestly haven't thought this through at all, and this might be a really dumb idea), instead of specific support for this one feature, I wonder if it would make more sense to actually build in support for a policy server (ie, amavisd-new) like postfix has...
--
Best regards,
Charles
On 16/08/2012 12:24, Charles Marcus wrote:
On 2012-08-16 7:12 AM, Ed W lists@wildgooses.com wrote:
My opinion is that this is very easily to implement in at least Postfix and probably other servers, hence I would suggest this is a function for the MTA, not for the Dovecot relay?
Well, true enough for simpler installations, but integrating something like this in dovecot that can be applied across large dovecot director based farms might be a good thing.
Actually, maybe (and maybe not, I honestly haven't thought this through at all, and this might be a really dumb idea), instead of specific support for this one feature, I wonder if it would make more sense to actually build in support for a policy server (ie, amavisd-new) like postfix has...
I'm really missing the key point here?
The proposal was (I think?): Have Dovecot accept emails and feed them to the MTA (eg Postfix)
This means you have access to all the MTA features (hence why I was pointing out these features exist today). Further, by centralising this function you don't need to duplicate the functionality depending on whether an email was sent via Dovecot or SMTP.
So I don't see that policy servers are necessary in Dovecot for this particular requirement - I think most ideas we can come up with would benefit from delegating policy to the MTA so that it's centralised?
I might be missing the point, so see above for my understanding of the problem?
Ed W
On 2012-08-16 7:58 AM, Ed W lists@wildgooses.com wrote:
On 16/08/2012 12:24, Charles Marcus wrote:
Actually, maybe (and maybe not, I honestly haven't thought this through at all, and this might be a really dumb idea), instead of specific support for this one feature, I wonder if it would make more sense to actually build in support for a policy server (ie, amavisd-new) like postfix has...
I'm really missing the key point here?
The proposal was (I think?): Have Dovecot accept emails and feed them to the MTA (eg Postfix)
This means you have access to all the MTA features (hence why I was pointing out these features exist today). Further, by centralising this function you don't need to duplicate the functionality depending on whether an email was sent via Dovecot or SMTP.
So I don't see that policy servers are necessary in Dovecot for this particular requirement - I think most ideas we can come up with would benefit from delegating policy to the MTA so that it's centralised?
But doing it in dovecot would mean that it wouldn't matter what MTA you were using, or even what OS/platform said MTAs were running on, you would handle all said policies for your entire (dovecot-director) infrastructure in one place (dovecot)...
Also, this would only be for *outbound* policies, so would provide a degree of separation with your *inbound* policies... which could be a good or bad thing I guess depending on your needs and requirements.
Like I said, I haven't thought it completely through and it may indeed be a bad idea...
--
Best regards,
Charles
participants (5)
-
Charles Marcus
-
Cor Bosman
-
Ed W
-
Patrick Ben Koetter
-
Timo Sirainen