On Tue, Mar 08, 2005 at 02:54:23PM -0500, Craig Huckabee wrote:
I've just started looking into using the 'reply' delivery mode as a vacation feature for our users with qmail-ldap 20041201.
However, when I set 'deliveryMode' to 'reply' and add an appropriate 'mailReplyText', I get no reply text. I tested this by sending an e-mail from an external account and having co-workers send messages as well.
...
mail:/s/qmail/bin# ./qmail-ldaplookup -u huck
...
qmailDotMode: ldapwithprog
deliveryMode: reply
deliveryMode: local
mailReplyText:
=== begin ===
From: "Craig Huckabee"
Subject:Automated reply - please ignore
Please ignore just testing. === end ===
Can you have two "deliveryMode"s? I'm not sure how that works.
Well, according to the mailing list archive messages I found, "reply" only sends a reply with no local delivery. I found a recommendation to use both "reply" and "local" to implement this.
Anyway I have a similiar setup (not sure what 'ldapwithprog' does) and I put a line like | qmail-reply ./Maildir/ in the user's .qmail file to do the actual reply. There might be a way to do this just in LDAP, but I needed to filter out spam before running this command as I didn't want to reply to spam.
"ldapwithprog" lets me put that line out in ldap vice in a .qmail file.
I got it working with just the ldap entries after cranking up the debug level enough so I could see the query strings used by the qldap_filter calls (deep in the code).
The problem is our e-mail gets routed internally to that mailserver as (user)@(mailserver FQDN). This gets used to create the filter that looks up users in LDAP to decide if they are an LDAP user.
However, our users in LDAP have a "mail" property of (username)@(top level domain). If I had not enabled local delivery for users not found in LDAP (and had not enabled LDAP in /etc/nsswitch.conf for password lookups) my setup would have never worked.
Our quick fix was to hack the filter function to force the use of the @(top level domain) instead of the @(mailserver FQDN) when building the filter. Don't know of a way to achieve this in configuration changes (outside of re-organizing LDAP).
Anyway, it now works as advertised - sorry for the noise.
Thanks, Craig
