Re: Excluding users from the milter

[Cassandra Lynette Brockett]

Well, on a feasibility note - there is even another way this should be
handled - spamassassin should include a rule that if noted for a user
spamassassin halts processing - and does not do anything more than
start->checkruleexists->exit.

This is something the spamassassin team is working on making available -
same as they are working on whitelists and blacklists that when the message
triggers one of them spam processing is halted immediately.

Yes, sendmail should have details for handling who/when the milter runs,
however the milter concept is still new as far as the development of
sendmail is concerned - and most of us who use spamass-milter don't run
bleeding edge sendmails, in fact when it comes to the mailserver's stability
I can handle it mis-tagging some emails as spam or not, but I can't handle
it not delivering email... So I want a "known stable" version of sendmail -
which means I run a few versions behind the current release of sendmail -
and quite definately a few versions behind the CVS tree of sendmail.   Your
concept of how sendmail should handle milters is something best discussed in
the Sendmail milter mailing lists (not sure where they exist - but there
must be some... maybe www.milter.org has some details...).

There are many things we consider should be handled by this package or that
package, and most of us disagree.  I've mentioned on an occassion or two a
particular modification I would like spamass-milter to have, but due to
terrible C++ skills of my own I can't submit a patch for that - the Author
knows what I mean there, and I don't want to bug him about it - I'm sure it
will happen when he gets some time to work on it, or it will get done when I
get around to figuring out why my C++ code patch doesn't work :-)

Just wanted to say something to this message as it seemed off-topic for a
discussion of the milter - but on topic for a discussion of how milters in
general operate.

Regards,
    Cassandra

----- Original Message ----- 
From: "Chuck Yerkes" <address@hidden>
To: <address@hidden>
Sent: Monday, June 30, 2003 11:04 AM
Subject: Re: Excluding users from the milter


>
> Quoting Cassandra Lynette Brockett (address@hidden):
> > Just a simple question - do you need to exclude them from the milter
running
> > for them, or just exclude the milter from changing/modifying their
messages?
> >
> > If the former - no such luck without hacking the milter.  If the later,
then
> > all you need to do is tell the milter to not modify the emails, and/or
set
>
> Ideally, (IMHO), the right answer would be this:
> When sendmail starts up, it gathers the input filter names.
> It would make sense, and be consistent with other sendmail "ways"
> to have sendmail invoke a rule per milter.  So if I have:
> O InputMailFilters=SpamAssassinFilter,
>
> the rule "check_SpamAssassinFilter" would be invoked before sending
> data to the milter.
>
> Sendmail would look at the return value to decide (ok = "send
> through milter" and error = "don't send through milter).
>
> Bumps include mail to several people, some of whom get it, some
> don't.  Sendmail splits mail already and could do that here.
>
>
> An alternernative would be to have the milter use the access map
> (access.db) to decide who gets miltered or not.
>
> The access map is used as a single point to manage various
> access points to mail.
>
>
> Again, ideally, the map lookup routines would be in a library
> from sendmail and not buried in the single binary.  This way
> the library can deal with the access map being a db file,
> an LDAP entry, a HESIOD map, or a NIS map.
>
>   Sendmail folks have run into this as a problem over and over
> and over. (I've been doing SNMP things where I have to hand
> parse the sendmail.cf file and that's just wrong - I should
> be able to say something like:
>
>    char **imf;
>    imf=sm_getOption("InputMailFilters")
>
>
> Chuck
>
>
> _______________________________________________
> Spamass-milt-list mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/spamass-milt-list
>