procmail
[Top] [All Lists]

Re: Defining an rc file for a local mailer.

2002-07-16 15:43:25
Ok,

I got this all working so I figured I'd let everyone know how to do it.

First, I resolve every user against virtusertable so that email addresses and usernames don't need to be the same. If you have ever used Netscape Messenging you know what I am talking about. So every email address in the directory is mapped to a user in the directory using this command:

FEATURE(`virtusertable', `ldap:-1 -k (&(objectClass=aptAccount)(aptmailLocalAddress=%0)) -v aptMailDeliver')

Now that we resolve the username I have this rule to make sure that we reject mail addressed to invalid users:

Scheck_validuser
RLDAP < $+ >      $: $(emaillookup $1 $: DENY < $1 > $)
RDENY < $+ >      $: $(emaillookup $1 $: DENY2 < $1 > $)
RDENY2 < $+ > $#error $@ 5.7.1 $: "Mail sent to invalid user" R$+ $: LDAP < $1 >

Notice that I match "RLDAP < $+ >" in the first line? This is because I store a list of all of the domains that are in the directory in another map. When I get an email I first look to see if that is an LDAP stored domain then set the token space to "LDAP < user @ domain . com >".

Email addresses that don't come with LDAP perpended to the user space are not subject to the LDAP rules.

Now that I have invalid users and email->user mappings taken care of I simply store "user+spam" in the aptMailDeliver attribute. Then sendmail processes the username it passes 'spam' to procmail. I then use this procmail recipe to apply my spam filter rules.

ARG = $1

:0
        * ^Subject:\/.*
        {
                SUBJECT = $MATCH
        }


:0
        * ARG ?? ^^spam
        {
                INCLUDERC=$JFDIR/junkfilter
        }


# Deal with mail that junkfilter has flagged.
:0
* JFEXP ?? .
{
        # Check for whitelisted mail
        :0 f
        * JFSTATUS ?? 1
        | formail -i "X-junkfilter: $JFVERSION" \
                -i "X-Spammer: $JFEXP"

        # File as spam
        :0 E f
        | formail -i "X-junkfilter: $JFVERSION" \
                -i "X-Spammer: $JFEXP" \
                -i "X-Is-Spam: YES" \
                -I "Subject: [SPAM] $SUBJECT"
}

So when a user has spam filtering enabled we include the junkfilter recipe and it tags the email as spam.

This solution allows me to define who gets spam filtering in the directory without additional programs and lookups.

Thanks,

schu


Matthew Schumacher wrote:


Philip Guenther wrote:

Matthew Schumacher <matt(_dot_)s(_at_)aptalaska(_dot_)net> writes:

If the recipient don't exist as real UNIX users (i.e., getpwnam(username)
fails) then "procmail -d username" will not work without modifying the
procmail source.  So, do they exist as real UNIX users?


According to your definition of real, yes, they exist. The uid and gid are resolved against nss_ldap and pam_ldap.


Why would procmail be called twice?  Wouldn't you just call ldapsearch
from the /etc/procmailrc and branch inside the rcfile based on the result?


You are correct, I don't know how much of a hit calling ldapseach on every single mail transaction is going to cause. I am assuming it will be easier on the box to do it in sendmail.


The process startup time is almost certainly ignorable. On the otherhand,
depending on how many message/sec you're looking at and whether you're
using TLS, the LDAP connection setup time may or may not be.  Have you
actually tested to see how many invocations per second of ldapsearch your
machine can do?  I'm just curious whether you're leery of this solution
because it really won't perform fast enough or because it's inelegant.
The drive for elegance is a Good Thing, as long as it doesn't become
the main goal.


I haven't benchmarked the ldap transactions on this machine but I have tested emails per minute using postal. My directory indexing/tuning came from it's affect on sendmail performance not so much ldap performace.

That said, when I got ~800 emails a minute I was happy with the performance and put the machine into production.




Would it be "Good Enough"?



I don't know... It would take some testing. I found that kernel versions, quotas, and other variables where making a HUGE difference in the systems overall mail performance. I'm not really game for taking a guess I'll need to benchmark it.

I would, however like to find a streamlined way to make this work before I start the testing phase.


_Anyway_...

One possible solution that does the LDAP work in the sendmail.cf is to
have it put a 'prefix' on the +detail for the recipient based on whether
the user wanted spam filtering on not.  This would have to be done in
ruleset 5, right before it reinvoked the local mailer for the last time.
The /etc/procmailrc file could then examine the $1 value and, based on
it, decide whether to INCLUDERC the spam filtering recipes.  If you're
not using (and don't intend to ever use) +detail addresses, then it can
be done via a normal LOCAL_RULE_0 addition to your the sendmail.mc file.
The details of how to do that part of the job should of course be taken
to the comp.mail.sendmail newgroup, the only procmail bits would be
the stuff at the top of the /etc/procmailrc file, which would look
something like:

    ARG = $1
    :0
    * ARG ?? ^^spamfilter
    {
        INCLUDERC = /path/to/spam/filtering/rcfile
    }



This looks like a great way to do it.... I'll look for some sendmail documentation on how to use +detail addresses. This will also work when I implement per user virus scanning.

Any sample code you have on the sendmail end would be great.

Thanks,

schu

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail


--
_______________________________________________________________________
Matthew Schumacher                              
matt(_dot_)s(_at_)aptalaska(_dot_)net
Alaska Power and Telephone                      desk: 907-563-2199 x223
Systems Administrator                           cell: 907-240-2275

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>