[Pymilter] simple milter design needed

[Eric S. Johansson]

Stuart D. Gathman wrote:

> On Sat, 3 Apr 2004, Eric S. Johansson wrote:
> 
> 
>>(www.camram.org) into a milter.  What I need at invocation is a list of 
>>all recipients and the sender, and the message  passing through the 
>>milter either the form of a string or a email.message object.  It would 
>>be wonderful if I could find out what interface the message came in on 
>>but I have a backup plan in case that's not possible.
> 
> 
> import Milter
...
goodness.  that is very generous of you.

> # The connect callback tells you connecting IP.  Furthermore, the connect
> # interface is available as a "macro".

If I'm interpreting this correctly, it is presenting the address of the 
  host initiating the smtp transaction.  I need to know something 
different which is which interface the message arrives on not where it 
came from.  reason being that I perform asymectric operation on the mail 
stream.  in one direction, I filter for spam, in another I stamp and log 
outbound messages ( I guard this interface heavely :-).  it is no biggie 
  if it is not possible, I will just run two copies of sendmail with 
separate queues.

> 
>   def connect(self,hostname,unused,hostaddr):
>     self.receiver = self.getsymval('j')
>     self.if_name = self.getsymval('if_name')
>     self.if_addr = self.getsymval('if_addr')
>     if hostaddr and len(hostaddr) > 0:
>       ipaddr = hostaddr[0]
...

> # The envfrom callback tells you who the message is (purportedly) from.
> # multiple messages can be received on a single connection
> # envfrom (MAIL FROM in the SMTP protocol) marks the start
> # of each message.
>   def envfrom(self,f,*str):
>     self.log("mail from",f,str)
>     self.fp = StringIO.StringIO()	# file to save message in
>     self.mailfrom = f
>     self.recipients = []

is class instance preserved between callbacks making self a safe place 
to accumulate data?  missed the docs on that.  also occurs to me to 
wonder how/if you transion between C threads and python threads.  also 
wonder about mem leaks and how to detect/recover.  camram usually is 
spawned by procmail and never lives for more than 1 process lifetime.
hmm I clearly have some work to do.

  >   def eoh(self):
>     # possibly camram would know by this time whether to discard the
>     # message

in future maybe. I should have enough info at this time for stamp, fast 
whitelist, slow white list and leave the heavyweight content filter to 
later..

 >
 >   Hope the quick tutorial helped.
 >

yes indeed.  I am really learning a lot from this example, things that 
would take many hours of skull sweat.  after 2 years of working out how 
to make a user friendly hybrid sender-pays system, I can not thank you 
enough for the help.  many thanks

> This really brings home the need to create a plugin structure for Python milter
> addons.  Sendmail can, of course, run several milters in series.  And that is
> the best approach for C milters.  However, with Python it would be better to
> handle lots of optional features within the same VM.

that is a point of some debate.  many threads or many processes.  I 
prefer a mixture.  in some cases plugins work.  camram has a filtering 
framework and logic structure for interpreting the results of many 
filters.  could it be broken down into a series of plug in modules?  yes 
it could and be the better for it.  it may take me some time to do so as 
the project would need a patron.  but small steps first.  let me get the 
basic filter working.

first gentoo now this.  fun things to work with.

more tomorrow.

--- eric

<!DSPAM:FBB3B2B584159352454862785>