RE: [Dovecot] triggering multiple actions on pop-3 request
The reason for this is so that the messages retrieved by fetchmail can be filtered via an anti spam service before depositing them into the inbox.
How about just running fetchmail in daemon mode, so it's polling for messages instead of running on demand? Then you don't need to worry about any special integration issues.
Julian.
Julian Melville wrote:
The reason for this is so that the messages retrieved by fetchmail can be filtered via an anti spam service before depositing them into the inbox.
How about just running fetchmail in daemon mode, so it's polling for messages instead of running on demand? Then you don't need to worry about any special integration issues.
I thought of that but I'm also thinking about the user experience. In the daemon mode, users have no control over polling. In the trigger mode, they will have an indirect control. Also, it cuts down on bandwidth usage because there's no sampling around the clock. On the other hand, it does smooth out filter load which is also a good thing.
hmmm. obviously, I will need to experiment and since the daemon mode is "free", it's an easy test.
---eric
If you want to launch fetchmail, you'd probably want to do a fork() after authentication.
In the child, you would execl() fetchmail.
In the parent you would wait() for the exit status of the child.
You probably wouldn't want to do that in dovecot-auth or it might block all other auth while it is executing? I haven't really looked at the design so I don't know. The best place would probably be right before it tries to read the user's Maildir, in its own process.
(assuming login_process_per_connection = yes )
Skye
Word on the street is Eric S. Johansson said:
I thought of that but I'm also thinking about the user experience. In the daemon mode, users have no control over polling. In the trigger mode, they will have an indirect control. Also, it cuts down on bandwidth usage because there's no sampling around the clock. On the other hand, it does smooth out filter load which is also a good thing.
hmmm. obviously, I will need to experiment and since the daemon mode is "free", it's an easy test.
---eric
Skye Poier wrote:
If you want to launch fetchmail, you'd probably want to do a fork() after authentication.
In the child, you would execl() fetchmail.
In the parent you would wait() for the exit status of the child.
I figured a fork and exec would probably be what's called for. Although, I would probably want to cast off the child process and let it run to completion on its own.
You probably wouldn't want to do that in dovecot-auth or it might block all other auth while it is executing? I haven't really looked at the design so I don't know. The best place would probably be right before it tries to read the user's Maildir, in its own process.
the best place would be a place for I have all of the necessary information about the user and is a mainline pass through the code so it will always be executed. If you do this right, it could be a plug-in point for pre access functionality. There is probably some equivalent location for post access. Might be an interesting place to put in plug-in infrastructure so we can do all sorts of things to people's e-mail. For example, I have often thought that it would be interesting to have some sort of filter after read type capability. Where all messages go into your inbox and after you read them, a filtering decision is made and the message is put in the appropriate destination automatically. Probably best client side but server side filtering has many advantages including the ability to change clients and not having to move your 200 filter rules.
in any case. I can see the argument for putting things down in the actual server code.
---eric
Word on the street is Eric S. Johansson said:
I figured a fork and exec would probably be what's called for. Although, I would probably want to cast off the child process and let it run to completion on its own.
But, if you don't wait() then the messages it fetches will not be avaiable in the first POP LIST. Which may not matter in your design :)
the best place would be a place for I have all of the necessary information about the user and is a mainline pass through the code so it will always be executed.
And, after dovecot has changed its UID and chrooted (if the extra security is desired)
Skye
Skye Poier wrote:
Word on the street is Eric S. Johansson said:
I figured a fork and exec would probably be what's called for. Although, I would probably want to cast off the child process and let it run to completion on its own.
But, if you don't wait() then the messages it fetches will not be avaiable in the first POP LIST. Which may not matter in your design :)
probably doesn't matter. I would be concerned about waiting for God knows how long while you download 50 billion pieces of spam and filter them out of the stream before returning the first list to the user. On the other hand, if it's a relatively quick process, it might not be too hideous to wait. Would certainly make things easier.
the best place would be a place for I have all of the necessary information about the user and is a mainline pass through the code so it will always be executed.
And, after dovecot has changed its UID and chrooted (if the extra security is desired)
indeed. Thank you for the reminder.
And as a general note to the conversation. I looked into fetchmail as daemon and found it wouldn't work. I would need to have a fetchmail processor running for every single user on the machine. This could get really nasty if you have a few hundred+++ accounts all going to different pop 3 servers for their source information.
another possibility (assuming I want to use the "make the user wait" model) is to create a simple proxy which only handles the authentication phase. it establishes a connection with the remote server based on given username and password, runs the pop3 fetch and filter, and drops messages into a local maildir. then, pass the connection to a local dovecot, replaying the authentication sequence (or even bypassing given that the system authenticated on a "authoritative" source) but now connecting the users mail client to the dovecot pop3 server.
might work and doesn't require any modifications to dovecot. would need to figure out how to pass control from the new authentication environment/proxy to the dovecot pop3 workhorse.
---eric
Word on the street is Eric S. Johansson said:
another possibility (assuming I want to use the "make the user wait" model) is to create a simple proxy which only handles the authentication phase. it establishes a connection with the remote server based on given username and password, runs the pop3 fetch and filter, and drops messages into a local maildir. then, pass the connection to a local dovecot, replaying the authentication sequence (or even bypassing given that the system authenticated on a "authoritative" source) but now connecting the users mail client to the dovecot pop3 server.
Yet another model, if you don't need the first LIST to block, would be to write a simple script to "tail -f" the dovecot log file, watch for successful auths, and then launch fetchmail for that user. Could be done in Perl in about 20 lines :)
Skye
On Thu, 2004-03-18 at 15:06, Eric S. Johansson wrote:
the best place would be a place for I have all of the necessary information about the user and is a mainline pass through the code so it will always be executed. If you do this right, it could be a plug-in point for pre access functionality. There is probably some equivalent location for post access. Might be an interesting place to put in plug-in infrastructure so we can do all sorts of things to people's e-mail.
It's already possible. Use http://dovecot.org/patches/quota.c as base, but instead of overriding the storage functions, just call fetchmail in quota_mail_storage_created(). Same plugin would work for both POP3 and IMAP.
participants (4)
-
Eric S. Johansson
-
Julian Melville
-
Skye Poier
-
Timo Sirainen