[Dovecot] qmail-secretary plugin for dovecot deliver
Hi,
I have been using qmail-ldap for quite some time and now moved to postfix/dovecot. One feature that I miss is that provided by qmail-secretary. qmail-secretary basically is a mail list manager with following features:
1 no limit, just explode to all members 2 members only, as the name says; only members are allowed (based on envelope sender, so not very secure, everybody can fake that) 3 sender confirm, sender has to confirm submission and return address like DJBs qmail-secretary 4 moderated, moderator(s) have to accept every message; there are DN and RFC822 moderators
All configuration (name, members, moderated etc...) are taken from LDAP.
I had gone through the code and from what I understand for each 4 delivery types it works as follows:
Just deliver to all recipients (say, inject it via sendmail).
verify if envelope sender is in allowed list and proceed as above.
- create a random hash
- save the mail in new/ with hash as filename
- create a new mail with listname-confirm-hash@domain.com and send
- If that mail comes back, deliver the mail to all recipients.
- as above but using listname-approve-hash and list-name-reject-hash
- move the msg to cur/
- if appropriate reply comes retrieve the mail from cur/ and send to all recipient.
qmail-secretary is invoked by qmail-local and thus this is a nice candidate for a deliver plugin. Before I start coding I just want to check if there is any gotchas that I am missing? I assume all these operations can be performed as a deliver plugin and that deliver plugin is the correct place for such functionality.
It goes without saying that I would be contributing this plugin back to dovecot.
with regards,
raj
hi,
maybe look into mlmmj. (http://mlmmj.org/)
darix-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On Thu, Feb 25, 2010 at 9:37 PM, Marcus Rueckert <darix@opensu.se> wrote:
hi,
maybe look into mlmmj. (http://mlmmj.org/)
qmail-secretary just works, no configuration is needed, all you have to do is add appropriate entry in ldap. No mess with MTA configs and fully controllable via web interface (via ldap)
That's what I am trying to recreate for dovecot!
raj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 25 Feb 2010, Rajkumar S wrote:
maybe look into mlmmj. (http://mlmmj.org/)
qmail-secretary just works, no configuration is needed, all you have to do is add appropriate entry in ldap. No mess with MTA configs and fully controllable via web interface (via ldap)
That's what I am trying to recreate for dovecot!
Er, "qmail-secretary" looks like a part of "qmail", hence, the analogy would be postfix in your new setup, or am I mistaken?
Anyway, there are plenty of mailing list managers out there.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS4eCAb+Vh58GPL/cAQLf8QgAjKS1Re4HmHFbzK2waQ0TDuyrUUlqzIyU A+Lf67EX71cah2lsPqjKlBX5A4ZbKLHHAvF2BezxOg4sBmvTQH2PUezcM+zkOu9v x2WZbQ4Rl6jeVTYyJbr+2vRlSkyQpD5uwIbd8JWGTj7hrv+jPfqQ8uOvnogRoczX LHMVhlwzWy/VnpfjDAnTl9P8TStfi2ck2B/97IIn9n4sRwUr22V2dGmZWZEBOuLS Vh4K2ya6nH+tXOrvRaJb7ol4kx74mSCMkxdxxOlvvo9DgoPxe+GGRwqrjMWbYZHv zEc+yLiQxC9/TNisQeffO6uP9lmQnrzyckg8DDDkHp5ev3tljN7lQA== =IQ17 -----END PGP SIGNATURE-----
On Fri, Feb 26, 2010 at 1:40 PM, Steffen Kaiser <skdovecot@smail.inf.fh-brs.de> wrote:
Er, "qmail-secretary" looks like a part of "qmail", hence, the analogy would be postfix in your new setup, or am I mistaken?
it's a part of qmail-local which is responsible for delivering mails to local users, analogous to dovecot deliver.
See the following big picture for details: http://www.nrg4u.com/qmail/the-big-qmail-ldap-picture-20031112.pdf
Anyway, there are plenty of mailing list managers out there.
I would be happy to use any which can take configs from LDAP and has sender confirm feature.
with regards,
raj
Hello,
I have a rough draft of group mail plugin. It's working here but requires lot's more polishing work. I would be happy if this can be a part of dovecot after all problems are ironed out.
The plugin uses the algorithm of qmail-secretary as mentioned in my initial mail. To create a group qmailGroup object class has to be present along with other object classes in ldap. Once qmailGroup object class is present, the plugin will check for sender confirm, members only, rfc822member, rfc822moderator and rfc822sender attributes.
if it's a members only list, the envolop sender is checked to see if it's not in rfc822sender or in moderator attributes, then the mail is rejected with an error.
For sender confirmation and moderation requests a unique hash created which is used to identify sender confirmations and moderator requests mails when they come back.
else if sender confirmation is present a confirm mail is sent with the format groupid-confirm-hash@domain.com as reply to address to the envelope sender for confirmation. The original mail is saved in the home directory with the name hash_c in group's home directory.
I had a problem when a reply from such a mail arrives. Since a mail address in this format is not present in ldap, this mail is dropped. So I patched userdb-ldap.c to remove the hash and action part before lookup and restore it after ldap look up if the mail id format is like groupid-action-hash@domain.com.
For example: "auth_request->user" contains the mail-id which is to be looked up in ldap. If the mail-id to be looked up is group01-confirm-1234567890@demo.com "auth_request->user" is cut short to group01@demo.com. After lookup the original mail-id is restored. i.e auth_request->user" is set back to group01-confirm-1234567890@demo.com .
When a sender confirmation request arrives if the group is moderated a moderator request mail is sent to all moderators with same format as sender confirmation mails with action name as moderate, and the mail in home directory is renamed from hash_c to hash_m.
When moderator reply also comes back the mail is sent to all members of the list and is removed from group home directory.
Now the ugly (?) parts are:
I could not find out a way to read ldap credentials from conf file, so right now it's hard coded in to the sources :( I am also doing a direct ldap lookup from plugin, I am not sure if that is appropriate. I would like to be able to use dovecot mechanisms to read conf and values from conf file in a backend neutral way.
Also is it okay to create files like hash_c and hash_m to save temporary mails in home directory? Any "proper"/"better" way to save a file in mail box with a particular file name. (the file name is important for retrieving the corresponding mail when a confirmation arrives) The file also needs to be removed later if a confirmation does not arrive in a specified time.
with regards,
raj
On Thu, Feb 25, 2010 at 9:32 PM, Rajkumar S <rajkumars@gmail.com> wrote:
Hi,
I have been using qmail-ldap for quite some time and now moved to postfix/dovecot. One feature that I miss is that provided by qmail-secretary. qmail-secretary basically is a mail list manager with following features:
1 no limit, just explode to all members 2 members only, as the name says; only members are allowed (based on envelope sender, so not very secure, everybody can fake that) 3 sender confirm, sender has to confirm submission and return address like DJBs qmail-secretary 4 moderated, moderator(s) have to accept every message; there are DN and RFC822 moderators
All configuration (name, members, moderated etc...) are taken from LDAP.
I had gone through the code and from what I understand for each 4 delivery types it works as follows:
Just deliver to all recipients (say, inject it via sendmail).
verify if envelope sender is in allowed list and proceed as above.
- create a random hash 2. save the mail in new/ with hash as filename 3. create a new mail with listname-confirm-hash@domain.com and send 4. If that mail comes back, deliver the mail to all recipients.
- as above but using listname-approve-hash and list-name-reject-hash 2. move the msg to cur/ 3. if appropriate reply comes retrieve the mail from cur/ and send to all recipient.
qmail-secretary is invoked by qmail-local and thus this is a nice candidate for a deliver plugin. Before I start coding I just want to check if there is any gotchas that I am missing? I assume all these operations can be performed as a deliver plugin and that deliver plugin is the correct place for such functionality.
It goes without saying that I would be contributing this plugin back to dovecot.
with regards,
raj
On Tue, 2010-03-16 at 12:07 +0530, Rajkumar S wrote:
I have a rough draft of group mail plugin. It's working here but requires lot's more polishing work. I would be happy if this can be a part of dovecot after all problems are ironed out.
That seems like a feature that's unlikely to be used by many people, even more so because it requires LDAP. It's fine if it's listed in http://wiki.dovecot.org/Plugins, but I don't think I'll add it to Dovecot distribution itself.
I had a problem when a reply from such a mail arrives. Since a mail address in this format is not present in ldap, this mail is dropped. So I patched userdb-ldap.c to remove the hash and action part before lookup and restore it after ldap look up if the mail id format is like groupid-action-hash@domain.com.
Could you do all this work before even calling deliver? Like:
deliver -a user-action-hash@domain.com -d user@domain.com
So the lookup is done for user, but the full address is still available.
Now the ugly (?) parts are:
I could not find out a way to read ldap credentials from conf file, so right now it's hard coded in to the sources :( I am also doing a direct ldap lookup from plugin, I am not sure if that is appropriate. I would like to be able to use dovecot mechanisms to read conf and values from conf file in a backend neutral way.
Currently the only LDAP config for Dovecot is for authentication. I don't think other stuff should necessarily read that same config. The whole LDAP stuff should be more abstracted out, so that e.g. dict-ldap could also be created, but that's a bigger job..
Also is it okay to create files like hash_c and hash_m to save temporary mails in home directory? Any "proper"/"better" way to save a file in mail box with a particular file name. (the file name is important for retrieving the corresponding mail when a confirmation arrives) The file also needs to be removed later if a confirmation does not arrive in a specified time.
mail_user_get_temp_prefix() returns a path/prefix for a temporary file you can create.
But anyway, most importantly: get rid of those ugly insecure C string handling functions! Dovecot has tons of different ways to handle strings in an easier way: http://wiki.dovecot.org/Design/Strings I'd probably change most of them to t_strdup_printf() and maybe some string builders to string_t.
chomp() also seems unnecessary. There shouldn't be LFs in any of those strings. And if there are, they probably shouldn't be removed..
On Tue, Mar 16, 2010 at 5:50 PM, Timo Sirainen <tss@iki.fi> wrote:
That seems like a feature that's unlikely to be used by many people, even more so because it requires LDAP. It's fine if it's listed in http://wiki.dovecot.org/Plugins, but I don't think I'll add it to Dovecot distribution itself.
That's fine, I am willing to maintain and update the plugin as required.
Could you do all this work before even calling deliver? Like: deliver -a user-action-hash@domain.com -d user@domain.com So the lookup is done for user, but the full address is still available.
Okay. I am not sure I fully understand this statement, but let me try again before coming back to the list.
Currently the only LDAP config for Dovecot is for authentication. I don't think other stuff should necessarily read that same config. The whole LDAP stuff should be more abstracted out, so that e.g. dict-ldap could also be created, but that's a bigger job.
If you could elaborate on the ldap-dict I can try and code that up.
mail_user_get_temp_prefix() returns a path/prefix for a temporary file you can create.
Okay.
But anyway, most importantly: get rid of those ugly insecure C string handling functions! Dovecot has tons of different ways to handle strings in an easier way: http://wiki.dovecot.org/Design/Strings I'd probably change most of them to t_strdup_printf() and maybe some string builders to string_t.
chomp() also seems unnecessary. There shouldn't be LFs in any of those strings. And if there are, they probably shouldn't be removed..
Sure.
Thanks for your review, I shall address these and post the updated plugin.
with regards,
raj
On Tue, 2010-03-16 at 20:41 +0530, Rajkumar S wrote:
Could you do all this work before even calling deliver? Like: deliver -a user-action-hash@domain.com -d user@domain.com So the lookup is done for user, but the full address is still available.
Okay. I am not sure I fully understand this statement, but let me try again before coming back to the list.
I haven't tried to really understand what your plugin does, but looks like it does most of its work in mail_alloc(). deliver does the mail delivery via:
typedef int deliver_mail_func_t(struct mail_namespace *namespaces, struct mail_storage **storage_r, struct mail *mail, const char *destaddr, const char *mailbox); extern deliver_mail_func_t *deliver_mail;
Can your plugin use that instead? the -a address is in destaddr parameter.
Currently the only LDAP config for Dovecot is for authentication. I don't think other stuff should necessarily read that same config. The whole LDAP stuff should be more abstracted out, so that e.g. dict-ldap could also be created, but that's a bigger job.
If you could elaborate on the ldap-dict I can try and code that up.
Actually there already is a patch for that already. I added it now to http://dovecot.org/patches/1.2/ldap/
The lib-ldap part is what would help you as well. But its API seems too much of wrapper to ldap.h API. It could most likely be simplified so that auth/db-ldap.c could become almost as simple as auth/db-sql.c.
Also I really don't like the libldap_ prefix :) But I can't really think of any other great alternatives either..
I guess I mainly just haven't wanted to spend too much time thinking about this yet.
On Tue, Mar 16, 2010 at 9:14 PM, Timo Sirainen <tss@iki.fi> wrote:
I haven't tried to really understand what your plugin does, but looks like it does most of its work in mail_alloc(). deliver does the mail delivery via:
typedef int deliver_mail_func_t(struct mail_namespace *namespaces, struct mail_storage **storage_r, struct mail *mail, const char *destaddr, const char *mailbox); extern deliver_mail_func_t *deliver_mail;
Can your plugin use that instead? the -a address is in destaddr parameter.
Actually I tried to use this first, as follows:
static int lda_group_deliver_mail (struct mail_namespace *namespaces, struct mail_storage **storage_r, struct mail *mail, const char *destaddr, const char *mailbox) { i_info("ping"); }
void lda_group_plugin_init(void) { i_info("INIT"); n_deliver_mail = deliver_mail; deliver_mail = lda_group_deliver_mail; }
void lda_group_plugin_deinit(void) { deliver_mail = n_deliver_mail; }
This works when I am not using sieve plugin, but fails when sieve plugin is also used.
I guess I mainly just haven't wanted to spend too much time thinking about this yet.
I shall go with using a separate conf for plugin and query ldap when plugin is called.
with regards,
raj
participants (4)
-
Marcus Rueckert
-
Rajkumar S
-
Steffen Kaiser
-
Timo Sirainen