Exec'ing a script from Cyrus when imapd has a client

[Bron Gondwana]

On Tue, Oct 27, 2009 at 12:15:08AM -0400, Greg A. Woods wrote:
> Too bad, so sad.  Seriously.  If you really want to use e-mail address
> at some antique domain where IMAP access is still not available, and
> where e-mail forwarding is also not available, then you can still just
> set up your MUA so you can easily move messages from those antiquated
> POP folders over to suitable IMAP folders on some other system.
> 
> You do not _need_ fetchmail to do this for you, and you certainly don't
> need yet another IMAP server to do this for you.

Ahh, I've worked with people like this.  It's not an architecturally
"pure" enough idea, so we'll come up with a bunch of client-side hacks
instead of solving the actual problem, which I will state my 
understanding of:

"I want a local IMAP server that I can connect to with multiple different
clients if necessary, back up sanely, etc.  Due to circumstances, I need
it to pull mail in rather than be pushed to.  I would _prefer_ to not
pull all the time, but only when there's a client - any client - connected"

That's a viable problem statement.  That's a REAL WORLD problem statement.
The solutions suggested on this list have basically been "your problem
isn't viable, you should do things differently because our perfect world
doesn't include this architecture".

You know what - I would write a system pretty much just like this if I was
stuck at the far end of a slow link.  I would run a server and run backups
on that, treating the copy on the client as a disposable copy rather than
trying to back that up.

Honestly, please stop shooting down the architecture.  This isn't the place
to ask how to do the whole problem, but it is the place to ask "how can I
get the triggering data from Cyrus that I want".

Here are the answers we have come up with:

1) parse the log file (this can be made reliable, we use it at FastMail
   for some things)

2) scan the $conf/proc/ directory

3) inotify on the meta directory (actually, this is somewhat bogus if you
   don't have atime turned on)

Oh, here's a clever one:

4) write a custom saslauthd and trigger from it.

1 and 4 will get you instant notification (near enough)

2 will be cheap, especially if you do like we do and put $conf/proc on
tmpfs.

3 just sucks.  Most complex and least useful.

Bron.