I think I've got it now.
Is there a way to trace the "submit" module so that I can see if
maildrop is being called and if so, which file(s) it's looking for?
/var/log/maillog doesn't seem to have any mention of maildrop at all,
and I set TCPDOPTS in /etc/courier/esmtpd to
"-stderr=/var/log/maillog.err
-stderrlogger=/usr/lib/courier/sbin/courierlogger -noidentlookup
-nodnslookup" -- no /var/log/maillog.err file even gets created when the
'cjm' user receives an email. The /var/log/maillog file shows (I subbed
"$" vars for actual names):
I ran "strace -fp <pid_of_couriertcpd_listening_on_port_25>" The "-f"
gives me a trace of the "submit" module after it's forked from
couriertcpd.
I'm thinking that the maildrop command (as passed by courier) might not
be using the "rcptfilter" filename but "rcptfilter-ext" instead. I
tried using "rcptfilter-cjm" which is the system account name, and I'm
addressing the email to "cjm@$HOSTNAME" so there should be no
domain/alias confusion, but it's still not working.
If I could see the exact 'maildrop' command courier is using (if it's
using it at all), I can adjust my ".mailfilters" directory accordingly.
What I saw was that maildrop wasn't even being called. Even though I was
using a system account (cjm@$HOSTNAME), the fact that I had aliases set up
caused courier to ignore the /home/cjm/.mailfilters directory entirely. I
tested this by removing /etc/courier/aliases.dat, and sent a message.
With 'aliases.dat' gone, the embedded maildrop worked just like the man
page describes.
I'm off to look into 'aliasfilteracct' stuff now, since that's the route
"submit" takes when 'aliases.dat' exists.
Thanks for the syntax check and other help, Sam!
CJM
7 messages in net.sourceforge.lists.courier-maildropRe: [maildropl] Re: enable embedded m...
