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..