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

[Tony Nelson]

On 16-12-21 21:34:12, Stuart D. Gathman wrote:
  ...
> Development has moved to https://github.com/sdgathman/milter
> (and pymilter).

Yes, I saw.

> 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.

OK.  I have no current plans to use Python3, but I know I will have
to some day.  Soon I will have to migrate two servers from CentOS5.


> What we really need is a framework that plugs in modules.  Or just
> keep making separate milters with common libs like we have now.

One of the servers I have the milter on has some special requirements,
so I subclassed the milter to provide for them.  I had to add a
self.cur_rcpt to expose canon_to to the subclass.  Which is to say, for
at least some applications, a plug-in architecture will be difficult.

> It sounds like the improved "isdynip" is a win.

Yes, I think dynip() can just be used.  As it has lots more patterns,
it returns a number that can be used to assign blame, and can be run
as a script to display the pattern.  I have found it to be reliable.


>> 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.

The (little) servers I maintain don't get (well, accept) bounce spam
(which was your work, I think), and the Spamhaus Zen and DBL work pretty
well (for spam directed at the US).  The other rbls I've tried,  
including
a couple from companies that are trying some sharing among their  
customer
base, were not helpful.  This is hard to do and takes lots of mail
servers.


> 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.

The spam that gets through mostly says it is from the domain it seems to
be from.  The only thing that SPF could do is trip them up if they made
a mistake -- but lots of TBTF email providers aren't to be trusted here
either (can't get rDNS right, can't get HELO right, and so on).


>> 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.  :-)

I get it.  I'll revert my "fix".

I take it that Greylist objects do not contain any connection-
specific data.

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

OK.

-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
       '                              <http://www.georgeanelson.com/>