[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sendmail
Subject:    Re: milter protocol
From:       Steph L <mutt () free ! fr>
Date:       2004-06-06 13:55:07
Message-ID: 10467134340.~INN-FEAa00151.comp-news () dl ! ac ! uk
[Download RAW message or body]

"David F. Skoll" <dfs@roaringpenguin.com> wrote in 
news:X6ydnQrfpbFjfCjdRVn-ug@magma.ca:

> Anthony Howe wrote:
> 
>> Certain the latter is very sad. With a milter protocol specification
>> other MTA could integrate libmilter and that all our milters would have
>> a wider audience and distribution.
> 
> Milter is tied fairly heavily into Sendmail's architecture.  Integrating
> milter-like features into Postfix or Qmail would be a huge undertaking.
> 
> Regards,
> 
> David.
> 

[follow-up to some old past thread your news-server may have expired ]

David you're quite right. 

Wietse wrote some interesting comments regarding Milter : 
 
http://groups.google.com/groups?q=wietse+monolithic+milter&hl=fr&lr=&ie=U
TF-8&selm=c69cln%2413el%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1  

Extract from this post (the whole thread is worth reading) : 
<<

FYI, the API is owned by sendmail. It is basically a bunch of
call-backs into userland from the guts of Sendmail's mail processing
engine, and makes several assumptions about the MTA architecture.
Just a few examples:
- The API provides call-backs to the user process for SMTP commands
as well as for message header/body segments. This pretty much
assumes a monolithic MTA; with Postfix and qmail, SMTP commands
are done in a different process than header/body processing.  Having
these different processes calling back into the same user process
becomes an interesting project.
- The API calls back into the user process after the whole message
is received so that one can add/delete recipients, add/delete
headers, or change the body.  This pretty much prohibits the
one-pass, one queue file per message architecture that is the basis
of Postfix's performance and robustness.
This is not how Postfix works.  With Postfix, there are no user
programs jumping little hoops with callbacks from the MTA.
With Postfix, the MTA gives the entire message and envelope to
another program for inspection, and that program gives the message
back to Postfix (or not, if appropriate).  The content inspection
software has access to the entire message and it can make any
modification that it wants to envelope or content, or it can dispose
of the message via other means.
As for the SMTP level stuff, Postfix has a really easy to use
delegation procotol that is capable of all the greylist and SPF
functionality that people might want.
Let me know when someone has done a libmilter for a distributed
MTA such as qmail.
Meanwhile, you know where you can find sendmail.
>>

The only thing possible for the time being is to use a Milter application 
(in binary form) with another MTA through the glue 
Net::Milter  (see http://search.cpan.org/~mglee/Net-Milter-0.05/ ) .

Net::Milter was written based on the milter-protocol.txt done by Todd 
Vierling (Pmilter's author - http://pmilter.sourceforge.net/).
It consists in a perl implementation of the Sendmail end of the milter API.
(PureMessage also comes with a module called Net::Milter but I don't know 
if it is the same as the CPAN one).
 
It has been used so far by the qpsmtpd project(Drop-in replacement for 
qmail-smtpd written in perl) with the Brightmail Milter.  
See the Milter plug-in mentioned on : http://smtpd.develooper.com/


Another comment : The milter protocol description  written by 
Todd Vierling is really KEY as points out Andrzej Adam Filip.

It will need some updates in the future as sendmail 8.13.0 (beta3 so far)
includes some new Milter functions/commands. I guess that Todd will need
some help. 
The SF viewcvs link does not work (SF mess ?)  but you can view it through 
Google :
http://64.233.161.104/search?
q=cache:JBSsVMnvUpcJ:cvs.sourceforge.net/viewcvs.py/pmilter/pmilter/doc/mil
ter-protocol.txt%3Frev%3D1.2+&hl=fr

Testing/improving PMilter could also help a lot to track some issues in 
the documentation of the protocol. 
  
 
Regards, 

SL/
-- 
Contribution to sendmail & Milter (soon based on Docbook XML) : 
Unofficial Milter Introduction & Products List
http://milter.free.fr/intro/ http://milter.free.fr/intro/all.htm








[prev in list] [next in list] [prev in thread] [next in thread]