[Pymilter] My own version of the bms.py milter

[Stuart D. Gathman]

On Wed, 21 Dec 2016, Tony Nelson wrote:

> I've been using (and modifying) the bms.py milter for almost 10 years
> now, and it seems time to give back.  I have tarballs on my server,
> that build properly with rpmbuild -ta:
>
>   http: //www.georgeanelson.com/milter-0.9.tar.gz
>   http: //www.georgeanelson.com/pymilter-1.0.tar.gz
>
> They were made from the tarballs on Sourceforge (Revision 1.207
> 2016/04/22 16:05:14  customdesigned).  I can put my changes into git
> (with some effort and study), if desired.  Probably the best way to
> see what I've done is with Meld on the directories (well, I use diff
> and vimdiff).

Development has moved to https://github.com/sdgathman/milter
(and pymilter).  The big push is working with python3.  Which it
does - just need to nail down more of the bytes/str decisions in
the libmilter interfaces.

What we really need is a framework that plugs in modules.  Or just
keep making separate milters with common libs like we have now.
It sounds like the improved "isdynip" is a win.

> What I did works pretty well and much of the spam that gets through
> comes from real mailservers at spam companies, so I have not used
> SPF/SRS/SES or Dspam or DKIM or any of the rest.  I don't think I've
> broken any of them, and I may use them someday.

SRS blocks "bounce spam".  SPF and DKIM let you ban authenticated
domains.  All the (competent) spammers have fully authenticated domains -
that they use for a few days and abandon.  I've been focusing on
sharing banned domains with a blacklist.

Furthermore, banning is relative to authentication.  If the connection
gets a SOFTFAIL, then the domain is banned for SOFTFAIL, but not for
PASS.  If the connection got a PASS - then the domain is banned
up front for everything without even bothering to check SPF.

> BTW: according to the Milter docs, each callback during a connection
> can be on a different thread, so threading().local is probably wrong.
> I've fixed that.

The threading().local is only used for a cache to avoid creating
new Greylist objects all the time - and the Greylist objects are
not threadsafe.  In general, it is for global objects that are not
threadsafe - not for connection specific objects.  It is a *good* thing
if the callbacks are on different threads.  :-)

However, that should be explained in the comments.  Obviously, anything
connection specific goes in the FooMilter object.

-- 
 	      Stuart D. Gathman <stuart at gathman.org>
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.