Re: Dovecot book available again

2016-08-06 Thread Luca Lesinigo
Il giorno 06 ago 2016, alle ore 08:13, Peer Heinlein 
<p.heinl...@heinlein-support.de> ha scritto:
> And in some weeks in every book store by ISBN-13 978-1534895706.
> 
> If you want to support the author and if you help us to make good books you 
> should think about ordering it from Createspace instead of Amazon.
Hi Peer, thanks for sharing the news and the discount code ;-)

I really prefer buying digital versions of books, for ease of consumption.
Is there an ebook version of the book (didn’t see it on Createspace / Amazon), 
and possibly on some vendor that will help support the author?

(I’m asking publicly on the list because I think it could be of interest to 
other people too…)

thanks,
--
Luca Lesinigo

is it possible to run a post-login script in a dovecot proxy with local auth?

2016-07-04 Thread Luca Lesinigo
We’re using dovecot v2.2.22, authenticating on a local database (passdb with 
sql driver), and then proxying the connections to the backend server returned 
by passdb (proxy=y and backend in “host” column). To support some legacy 
clients we should keep POP/IMAP-before-SMTP running for some time, but right 
know I don’t know how to hook up a successful authentication in the dovecot 
proxy.

I did read from http://wiki2.dovecot.org/PostLoginScripting:
“...it's not currently possible to run post-login scripts in proxies, 
because they're not actually logging in to the local Dovecot”
Does that also holds true even if the proxy is authenticating users locally 
before proxying them?

Failing that, any idea on how to get successful logins, other than parsing the 
log file?

thank you,
--
Luca Lesinigo

FTS search used / useful on an IMAP proxy?

2016-06-28 Thread Luca Lesinigo
We are preparing an IMAP proxy based on dovecot-2.2.22, basic proxy 
functionality is already working and I’m trying to understand if having the FTS 
service configured on the dovecot *proxy* would be of any use.

I do suspect it would be useless, I guess dovecot in imap proxy mode just 
forwards any command to the backend and does not bother to do anything about 
it, but I’m failing to find a definitive answer in the documentation. If I am 
guessing correctly, an fts service would only be useful if configured and 
working on the actual backend.

Can anyone clarify my doubts?

thank you,
--
Luca Lesinigo

Re: [Dovecot] Advice for new dovecot / imap proxy? setup

2012-03-23 Thread Luca Lesinigo
Il giorno 23/mar/2012, alle ore 11:50, Timo Sirainen ha scritto:
 Are you thinking about actual dummy proxying (which is normally what 
 Dovecot proxying is about) or about the imapc backend 
 (http://www.dovecot.fi/products/105-dovecot-imap-adaptor.html)? If you're 
 using Dovecot as backend servers, there's really no reason to use imapc 
 proxying.
I actually didn't know about the two different modes. I guess I would need 
imapc to support the older Courier-IMAP server until I migrated everything away 
from it, and that I could use dummy proxying for the newer dovecot backends.
I don't know if the two can be used at the same time (eg. imapc to the older 
backend and dummy to the newer) and/or if there is any drawback in running 
everything on imapc (old and new dovecot server). I'll be investigating this

 We'd like to support all the recent IMAP goodies to make modern users happy 
 (IMAP IDLE, LEMONADE, etc)
 Dovecot doesn't support the full LEMONADE yet, but I don't know if there are 
 any LEMONADE clients either.
Oh well I included it in the list because I read about it somewhere, possibly 
on the dovecot site. But what I really meant was simply support the latest 
goodies :)

Il giorno 23/mar/2012, alle ore 11:38, Miguel Tormo ha scritto:
 - isolate the mailbox servers from direct external access and just run IMAP 
 on them, let other systems run ssl, pop3, smtp, webmail, etc...
 I don't think I understand you here. You will need to run POP3 on the mailbox 
 servers if you want to give POP3 access to the mailboxes.
Don't ask me why, but I was thinking that a dovecot proxy could talk just imap 
to the backends and use that to serve both POP3 and IMAP to clients. And it's 
possibly what happens with the imapc backend, but I need to do some RTFM about 
it.

 However, I can confirm you that IMAP IDLE does work with imap proxy.

That's great, I really want to provide the best possible push-like experience 
to modern clients, and as far as I know IMAP IDLE on the protocol side plus 
some notification mechanism (as opposed to regular polling) on the backend side 
is the way to go.

 You have my comments above, I think it is doable. In my opinion, the IMAP 
 proxy part is the easiest one. MTA configuration to distribute the mails 
 among the different mailbox servers can be trickier.
Actually that part is already there. Mail enters my systems via some MX servers 
(with the usual antispam and so on) and it's finally delivered via SMTP to the 
correct mail server via postfix recipient maps (that's because I already 
receive on my MXes mail for domains not hosted on my mail server, the common 
scenario is where I route a domain's mail to the customer's exchange server). 
But right now the mail server also receives direct SMTP connections from the 
clients in addition to incoming mail from my MXes and I'd really prefer to 
separate the two things.

 You could use dovecot LMTP proxy and make the MTA deliver mails through LMTP, 
 thus the dovecot proxy instance will handle the sharding for delivering and 
 for reading mail.
On the proxy system I plan to run postfix to implement authenticated SMTP (it 
would authenticate on dovecot) and pop/imap-before-smtp (yes we still need to 
support that :| ), but all mail will be reinjected through our MX servers to be 
scanned before final delivery (either local or external).

Thanks people for the suggestions, my next stop is getting to know imapc and 
its details, and how the various other parts will fit with that (eg. giving 
pop3 service to clients).

--
Luca Lesinigo

[Dovecot] Advice for new dovecot / imap proxy? setup

2012-03-21 Thread Luca Lesinigo
Hello list.

I'm planning a new mail servers for our company's customers to replace the 
oldish Courier-IMAP based one, we already started to deploy some mail accounts 
on a dovecot-2.0 server as an early test.
I'd like to implement the new system with dovecot-2 (I'll probably go straight 
to dovecot-2.1.x) and I'd like to get it right from the beginning so I'm here 
asking for some advice.

The issue I'm investigating right now is how to manage a single IMAP / POP / 
SMTP / webmail  entry point for multiple mail servers... in other words an 
IMAP proxy.
It would be desirable for multiple reasons:
- graceful migration from the current system: we'd make the mailserver hostname 
point to the proxy (along with its SSL certificates) and then the proxy would 
route each domain to the correct IMAP non-ssl server on our LAN. No need to 
update customer's systems configuration and we can move one domain at a time 
from the old to the new server, behind the scenes
- be ready for similar migrations in the future (eg. right now we're still 
keeping the imap servers with the qmail MTA, but we'd like to switch to 
postfix+dovecot in the future)
- be ready for sharding mail domains on multiple IMAP servers (if/when current 
hardware reach its capacity or needs to be swapped out for new gear)
- be ready to serve traffic over IPv6 without touching our precious mailbox 
servers
- isolate the mailbox servers from direct external access and just run IMAP on 
them, let other systems run ssl, pop3, smtp, webmail, etc...

Ideally the 'proxy' system would run dovecot imap and pop3 (SSL protected) and 
Roundcube webmail (PHP, on https) and just speak IMAP to the underlying mail 
servers on our internal LAN.
We'd like to support all the recent IMAP goodies to make modern users happy 
(IMAP IDLE, LEMONADE, etc) and possibly implement Maildir quota on the new 
backend mailbox server to improve our operations (currently we just run du in a 
cronjob once a day on the current mailserver, IMAP clients including the 
webmail do not know about quota and thus cannot show amount of free space).

In addition to that, customer's will hit the SMTP server running on that 
'proxy' system and this is good to keep its configuration separated from the 
SMTP server of the actual mail servers (which has a different configuration and 
is restricted to get connections only from our MX systems and not from outside 
sources).

I'd like to know if that plan sounds reasonable or if there's something stupid 
in it.
Also, is the proxy going to support all kind of IMAP stuff of the backend 
server (IDLE, CONDSTORE, Maildir quota, immediate notification of IDLE clients 
thanks to linux inotify, etc...) or will it limit me somehow?

thanks,
--
Luca Lesinigo