[Pymilter] other problems being chased

[Eric S. Johansson]

Stuart D. Gathman wrote:

> If you want to remove a specific recipient, call delrcpt() from eom().
> bms.py also has a del_recipient() that can be called earlier.  It just
> accumulates a list to remove in eom().  I have suggested adding
> basic tools like del_recipient() and add_header() (allows headers to
> be added before eom() - just queue 'em up and add later) to Milter.py,
> but have gotten strong resistence.  There seems to be a demand for
> a "bare bones" OO interface to libmilter.  So such features would
> go into an extended class derived from Milter.

that works for me.  I won't know who's to be deleted until I do my 
filtering deep within eom time.

> This system needs to be extended so that screeners can screen a subset
> of all mail users.  Our larger customers have departments whose legit
> mail differs quite a bit from each other - so having a screener screen only
> their own department would increase accuracy.  (Because other peoples mail
> that is not quarantined doesn't affect their dictionary - so it doesn't
> adapt to innocent mail unless they get the same kind of mail they are
> screening.)  However, the addition of SPF has greatly increased accuracy
> already.

I have that code already.  I will gladly share with you the scar tissue 
I've encountered in making it work.  In the "lump in the line" model, it 
was fairly easy to create filter specific IDs and associate them with 
either individual e-mail addresses or domains (or both).  Making milter 
work the right way for message replication appears to be relatively 
difficult.  the next trick is then using something I call delegation and 
merging.  The delegation assigns responsibility for spamtrap filtering 
to another party.  Merging takes delegation one step further and merges 
two or more accounts together making responsibility for sorting etc. the 
responsibility of one account.  they also have different implications 
when it comes to undoing the various bindings.  Merging is impossible to 
undo (think removing the chocolate from chocolate milk).  The best you 
can do is replicate the various filtering data sources into the 
different user accounts.  Delegations easier to undo because it merely 
undoes the spamtrap redirection.  The user still have their own double 
spend, white list and Bayesian databases.

To tell you choose, I'm not entirely happy with how the design/code 
evolved but it does map to how people work so it's probably going to 
take one more pass to make me more comfortable with the design.

As for SPF increasing accuracy I'm glad it is working for you but, I 
have one customer that is not using SPF because too many of the mailing 
lists and forwarding services were being inappropriately marked.  I have 
my doubts about SPF's long-term viability given that some of the bigger 
spammers are already creating SPF records for their zombie owned 
machines.  On the other hand, I know there are people that have doubts 
about what I'm doing.  :-)

---eric


<!DSPAM:FC18D1913E24611885886501>