New webpage design based on ht2html.
This commit is contained in:
Stuart Gathman
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 1.6 KiB |
+157
@@ -0,0 +1,157 @@
|
|||||||
|
<h2> Recent Changes </h2>
|
||||||
|
|
||||||
|
Python milter has been moved to
|
||||||
|
<a href="http://sourceforge.net/projects/pymilter/">pymilter Sourceforge
|
||||||
|
project</a> for development and release downloads.
|
||||||
|
|
||||||
|
<h3> New website design </h3>
|
||||||
|
|
||||||
|
Hey, I'm no artist, so I just used the
|
||||||
|
<a href="http://ht2html.sourceforge.net/"ht2html</a> package
|
||||||
|
by <a href="http://barry.wooz.org/">Barry Warsaw</a>. The mascot
|
||||||
|
is by <a href="http://alphard.ethz.ch/hafner/lebl.htm">Christian Hafner</a>,
|
||||||
|
or maybe his wife. I chose Maxwell's daemon because it tirelessly
|
||||||
|
and invisibly sorts molecules, just as milters sort mail.
|
||||||
|
Cristian has also provided a fun
|
||||||
|
<a href="http://alphard.ethz.ch/hafner/PPS/PPS2002/Maxwell/simulation.htm">
|
||||||
|
simulation</a> that lets you try your hand at sorting molecules.
|
||||||
|
|
||||||
|
<h3> 0.8.4 </h3>
|
||||||
|
|
||||||
|
Release 0.8.4 makes configuring SPF policy via access.db actually work.
|
||||||
|
The honeypot idea is enhanced by auto-whitelisting recipients of
|
||||||
|
email sent from selected domains. Whitelisted messages are then used
|
||||||
|
to train the honeypot. This makes the honeypot screener entirely self
|
||||||
|
training. The smfi_progress() API is now automatically supported when present.
|
||||||
|
An optional idx parameter to milter.addheader() invokes smfi_insheader().
|
||||||
|
|
||||||
|
<h3> 0.8.3 </h3>
|
||||||
|
|
||||||
|
Release 0.8.3 uses the standard logging module, and supports configuring
|
||||||
|
more detailed SPF policy via the sendmail access map. SMTP AUTH connections
|
||||||
|
are considered INTERNAL. Preventing forgery between internal domains is
|
||||||
|
just a matter of specifying the user-domain map - I'll define something
|
||||||
|
for the next version. We now send DSNs when mail is quarantined (rejecting
|
||||||
|
if DSN fails) and for SPF syntax errors (PermError). There is an
|
||||||
|
experimental option to add a Sender header when it is missing and the From
|
||||||
|
domain doesn't match the MAIL FROM domain. Next release, we may start
|
||||||
|
renaming and replacing an existing Sender header when neither it nor the
|
||||||
|
From domain matches MAIL FROM. Since bogus MAIL FROMs are rejected
|
||||||
|
(to varying degrees depending on the configured SPF policy), and
|
||||||
|
both Sender and From and displayed by default in many email clients,
|
||||||
|
this provides some phishing protection without rejecting mail based
|
||||||
|
on headers.
|
||||||
|
|
||||||
|
<h3> 0.8.2 </h3>
|
||||||
|
|
||||||
|
Release 0.8.2 has changes to <a href="http://openspf.net">SPF</a> to bring it
|
||||||
|
in line with the newly official RFC. It adds
|
||||||
|
<a href="http://ses.codeshare.ca/">SES</a>
|
||||||
|
support (the original SES without body hash) for pysrs-0.30.10, and honeypot
|
||||||
|
support for pydspam-1.1.9. There is a new method in the base milter module.
|
||||||
|
milter.set_exception_policy(i) lets you choose a policy of CONTINUE, REJECT, or
|
||||||
|
TEMPFAIL (default) for untrapped exceptions encountered in a milter callback.
|
||||||
|
|
||||||
|
<h3> 0.8.0 </h3>
|
||||||
|
|
||||||
|
Release 0.8.0 is the first <a href="http://sourceforge.net/">Sourceforge</a>
|
||||||
|
release. It supports Python-2.4, and provides an option to accept mail
|
||||||
|
that gets an SPF softfail or fails the 3 strikes rule, provided the
|
||||||
|
alleged sender accepts a DSN explaining the problem. Python-2.3 is
|
||||||
|
no longer supported by the reworked mime.py module, although API changes
|
||||||
|
could be backported. There are too many incompatible changes to the
|
||||||
|
python email package.
|
||||||
|
|
||||||
|
<h3> Older Releases </h3>
|
||||||
|
|
||||||
|
Release 0.7.2 tightens the authentication screws with a "3 strikes and
|
||||||
|
you're out" policy. A sender must have a valid PTR, HELO, or SPF record
|
||||||
|
to send email. Specific senders can be whitelisted using the
|
||||||
|
"delegate" option in the spf configuration section by adding a
|
||||||
|
default SPF record for them. The PTR and HELO are required
|
||||||
|
by RFC anyway, so this is not an unreasonable requirement.
|
||||||
|
There is now a coherent policy for an SPF softfail result. A softfail
|
||||||
|
is accepted if there is a valid PTR or HELO, or if the domain
|
||||||
|
is listed in the "accept_softfail" option of the spf configuration section.
|
||||||
|
A neutral result is accepted by default if there is a valid PTR or
|
||||||
|
HELO, (and the SPF record was not guessed), unless the domain is listed in the
|
||||||
|
"reject_neutral" option. Common forms of PTR records for dynamic IPs are
|
||||||
|
recognized, and do not count as a valid PTR. This does not prevent anyone
|
||||||
|
from sending mail from a dynamic IP - they just need to configure a
|
||||||
|
valid HELO name or publish an SPF record.
|
||||||
|
<p>
|
||||||
|
As SPF adoption continues to rise, forged spam is not getting through. So
|
||||||
|
spammers are publishing their SPF records as predicted. The 0.7.2 RPM
|
||||||
|
now provides the <code>rhsbl</code> sendmail hack so that spammer domains
|
||||||
|
can be blacklisted. With the RPM installed, add a line like the following
|
||||||
|
to your <code>sendmail.mc</code>.
|
||||||
|
<pre>
|
||||||
|
HACK(rhsbl,`blackholes.example.com',"550 Rejected: " $&{RHS} " has been spamming our customers.")dnl
|
||||||
|
</pre>
|
||||||
|
<p>
|
||||||
|
Of course, spammers are now starting to register
|
||||||
|
throwaway domains. The next thing we need is a custom DNS server,
|
||||||
|
in Python, that
|
||||||
|
can recognize patterns. For instance, one spammer registers ded304.com,
|
||||||
|
ded305.com, ded306.com, etc. We also need the custom DNS server to
|
||||||
|
let SPF classic clients check SES (which will be part of pysrs).
|
||||||
|
The <a href="http://twistedmatrix.com/products/twisted">Twisted Python</a>
|
||||||
|
framework provides a custom DNS server - but I
|
||||||
|
would like a smaller implementation for our use.
|
||||||
|
<p>
|
||||||
|
The RPM for release 0.7.0 moves the config file and socket locations to
|
||||||
|
/etc/mail and /var/run/milter respectively. We now parse Microsoft CID records
|
||||||
|
- but only hotmail.com uses them. They seem to have applied for a patent on
|
||||||
|
the brilliant idea of examining the mail headers to see who the message is
|
||||||
|
from. We aren't doing that here, so not to worry - but I am not a lawyer, so
|
||||||
|
if you are worried, change spf.py around line 626 to return None instead of
|
||||||
|
calling CIDParser(). There is a new option to reject mail with no PTR
|
||||||
|
and no SPF.
|
||||||
|
<p>
|
||||||
|
Microsoft is pushing an anti-opensource license for their pending patent
|
||||||
|
along with their sender-ID proposal before the IETF.
|
||||||
|
It is royalty free - but requires anyone distributing a binary they've
|
||||||
|
compiled from source to sign a license agreement. The Apache Software
|
||||||
|
Foundation <a
|
||||||
|
href="http://www.apache.org/foundation/docs/sender-id-position.html"> explains
|
||||||
|
the problem with sender-ID</a>, and Debian <a
|
||||||
|
href="http://www.debian.org/News/2004/20040904">concurs</a>. Since
|
||||||
|
the <a href="http://download.microsoft.com/download/4/3/9/439b024b-09fd-44ee-8ff0-10e834004c36/senderid_FAQ.PDF">Microsoft license</a> is
|
||||||
|
<a href="http://www.circleid.com/article/732_0_1_0_C/">incompatible with free
|
||||||
|
software in general</a> and the <a
|
||||||
|
href="http://www.imc.org/ietf-mxcomp/mail-archive/msg03678.html">GPL in
|
||||||
|
particular</a>, Python milter will not be able to implement sender-ID in its
|
||||||
|
current form. This was, no doubt, Microsoft's intent all along.
|
||||||
|
<p>
|
||||||
|
Sender-ID attempts to do for RFC2822 headers what SPF does for RFC2821 headers.
|
||||||
|
Unlike SPF, it has never been tried, and is encumbered by a stupid patent. I
|
||||||
|
recommend ignoring it and continuing to implement and improve SPF until a
|
||||||
|
working and unencumbered proposal for RFC2822 headers surfaces.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
<a href="http://openspf.com">
|
||||||
|
<img src="SPF.gif" align=left alt="SPF logo"></a>
|
||||||
|
Release 0.6.6 adds support for <a href="http://openspf.com/">SPF</a>,
|
||||||
|
a protocol to prevent forging of the envelope from address.
|
||||||
|
SPF support requires <a href="http://pydns.sourceforge.net/">pydns</a>.
|
||||||
|
The included spf.py module is an updated version of the original 1.6
|
||||||
|
version at <a href="http://www.wayforward.net/spf/">wayforward.net</a>.
|
||||||
|
The updated version tracks the draft RFC and test suite.
|
||||||
|
<p>
|
||||||
|
The FAQ addresses <a href="faq.html#spf">how to get started with SPF</a>.
|
||||||
|
<p>
|
||||||
|
Release 0.6.1 adds a full milter based dspam application.
|
||||||
|
<p>
|
||||||
|
I have selected the <a href="http://www.nuclearelephant.com/projects/dspam/">
|
||||||
|
dspam bayes filter project</a> and <a href="dspam.html">
|
||||||
|
packaged it for python</a>.
|
||||||
|
Release 0.6.0 offers a simple application of dspam I call "header triage",
|
||||||
|
which rejects messages with spammy headers.
|
||||||
|
To use header triage, you must have <a href="dspam.html">DSPAM</a> installed,
|
||||||
|
and select a dictionary that is well moderated by someone who gets
|
||||||
|
lots of spam. That dictionary can be used to block spam that is
|
||||||
|
obvious from the headers (e.g. X-Mailer and Subject) before it ties
|
||||||
|
up any more resources. I have yet to see any false positives from this
|
||||||
|
approach (check the milter log), but if there are, the sender will
|
||||||
|
get a REJECT with the message "Your message looks spammy."
|
||||||
|
|
||||||
@@ -0,0 +1,49 @@
|
|||||||
|
<h1> CREDITS </h1>
|
||||||
|
|
||||||
|
<a href="mailto:Jim Niemira <urmane@urmane.org>">Jim Niemira</a>
|
||||||
|
wrote the original C module and some quick
|
||||||
|
and dirty python to use it.
|
||||||
|
<a href="mailto:Stuart Gathman <stuart@bmsi.com>">Stuart D. Gathman</a>
|
||||||
|
took that kludge and added threading and context objects to it, wrote a proper
|
||||||
|
OO wrapper (Milter.py) that handles attachments, did lots of testing, packaged
|
||||||
|
it with distutils, and generally transformed it from a quick hack to a
|
||||||
|
real, usable Python extension.
|
||||||
|
|
||||||
|
<h2>Other contributors (in random order):</h2>
|
||||||
|
|
||||||
|
<dl>
|
||||||
|
<dt> <a href="http://alphard.ethz.ch/hafner/lebl.htm">Christian Hafner</a>
|
||||||
|
<dd>for the pymilter mascot image of
|
||||||
|
<a href="http://maxwelld.netfirms.com/">
|
||||||
|
Maxwell's daemon</a>
|
||||||
|
<dt>Dave MacQuigg
|
||||||
|
<dd>for noticing that smfi_insheader wasn't supported, and creating
|
||||||
|
a template to help first time pymilter users create their own milter.
|
||||||
|
<dt>Terence Way
|
||||||
|
<dd>for providing a Python port of SPF
|
||||||
|
<dt>Scott Kitterman
|
||||||
|
<dd>for doing lots of testing and debugging of SPF against draft standard,
|
||||||
|
and for putting up a web page that validates SPF records using spf.py
|
||||||
|
<dt>Alexander Kourakos
|
||||||
|
<dd>for plugging several memory leaks
|
||||||
|
<dt>George Graf at Vienna University of Economics and Business Administration
|
||||||
|
<dd>for handling None passed to setreply and chgheader.
|
||||||
|
<dt>Deron Meranda
|
||||||
|
<dd>for IPv6 patches
|
||||||
|
<dt>Jason Erikson
|
||||||
|
<dd>for handling NULL hostaddr in connect callback.
|
||||||
|
<dt>John Draper
|
||||||
|
<dd>for porting Python milter to OpenBSD, and starting to work on tutorials
|
||||||
|
then pointing out that it would be easier to just write the MTA in Python.
|
||||||
|
<dt>Eric S. Johansson
|
||||||
|
<dd>for helpful design discussions while working on camram
|
||||||
|
<dt>Alex Savguira
|
||||||
|
<dd>for finding bugs with international headers and
|
||||||
|
suggesting the scan_zip option.
|
||||||
|
<dt><a href="http://www.bmsi.com">Business Management Systems</a>
|
||||||
|
<dd>for hosting the website, and providing paying clients who need milter
|
||||||
|
service so I can work on it as part of my day job.
|
||||||
|
</dl>
|
||||||
|
|
||||||
|
If I have left anybody out, send me a reminder:
|
||||||
|
<a href="mailto:Stuart Gathman <stuart@bmsi.com>">stuart@bmsi.com</a>
|
||||||
@@ -22,7 +22,7 @@ shows you how to install libmilter with a separate invocation of make.
|
|||||||
<li> Q. Why is mfapi.h not found when I try to compile Python milter on
|
<li> Q. Why is mfapi.h not found when I try to compile Python milter on
|
||||||
RedHat 7.2?
|
RedHat 7.2?
|
||||||
<p> A. RedHat forgot to include the header in the RPM. See the
|
<p> A. RedHat forgot to include the header in the RPM. See the
|
||||||
<a href="milter.html#rh72">RedHat 7.2 requirements</a>.
|
<a href="requirements.html#rh72">RedHat 7.2 requirements</a>.
|
||||||
<p>
|
<p>
|
||||||
|
|
||||||
<h3> Running Python Milter </h3>
|
<h3> Running Python Milter </h3>
|
||||||
+49
-281
@@ -1,33 +1,28 @@
|
|||||||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
||||||
<html>
|
|
||||||
<head>
|
|
||||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
|
||||||
<title>Python Milters</title>
|
|
||||||
</head><body>
|
|
||||||
|
|
||||||
<P ALIGN="CENTER"><A HREF="http://www.anybrowser.org/campaign/">
|
<P ALIGN="CENTER"><A HREF="http://www.anybrowser.org/campaign/">
|
||||||
<IMG SRC="/art/brain1.gif"
|
<IMG SRC="http://bmsi.com/art/brain1.gif"
|
||||||
ALT="Viewable With Any Browser" BORDER="0"></A>
|
ALT="Viewable With Any Browser" BORDER="0"></A>
|
||||||
|
|
||||||
<img src="/art/banner_4.gif" width="468" height="60" border="0"
|
<img src="http://bmsi.com/art/banner_4.gif" width="468" height="60" border="0"
|
||||||
usemap="#banner_4" alt="Your vote?">
|
usemap="#banner_4" alt="Your vote?">
|
||||||
<map name="banner_4">
|
<map name="banner_4">
|
||||||
<area shape="rect" coords="330,25,426,59"
|
<area shape="rect" coords="330,25,426,59"
|
||||||
href="http://education-survey.org/" alt="I Disagree">
|
href="http://education-survey.org/" alt="I Disagree">
|
||||||
<area shape="rect" coords="234,28,304,57" href="http://www.honestEd.com/" alt="I Agree">
|
<area shape="rect" coords="234,28,304,57" href="http://www.honestEd.com/" alt="I Agree">
|
||||||
</map>
|
</map>
|
||||||
|
|
||||||
</P>
|
</P>
|
||||||
|
|
||||||
|
<img src="Maxwells.gif" alt="Maxwell's Daemon: pymilter mascot" align=left>
|
||||||
<h1 align=center>Sendmail Milters in Python</h1>
|
<h1 align=center>Sendmail Milters in Python</h1>
|
||||||
<h4 align=center>by <a href="mailto:%75%72%6D%61%6E%65%40%6E%65%75%72%61l%61%63%63%65%73%73%2E%63%6F%6D">Jim Niemira</a>
|
<h4 align=center>by <a href="mailto:%75%72%6D%61%6E%65%40%6E%65%75%72%61l%61%63%63%65%73%73%2E%63%6F%6D">Jim Niemira</a>
|
||||||
and <a href="mailto:%73%74%75%61%72%74%40%62%6D%73%69%2E%63%6F%6D">
|
and <a href="mailto:%73%74%75%61%72%74%40%62%6D%73%69%2E%63%6F%6D">
|
||||||
Stuart D. Gathman</a><br>
|
Stuart D. Gathman</a><br>
|
||||||
This web page is written by Stuart D. Gathman<br>and<br>sponsored by
|
This web page is written by Stuart D. Gathman<br>and<br>sponsored by
|
||||||
<a href="http://www.bmsi.com">Business Management Systems, Inc.</a> <br>
|
<a href="http://www.bmsi.com">Business Management Systems, Inc.</a> <br>
|
||||||
Last updated Oct 20, 2005</h4>
|
Last updated Oct 25, 2005</h4>
|
||||||
|
|
||||||
See the <a href="faq.html">FAQ</a> | <a href="http://sourceforge.net/project/showfiles.php?group_id=139894">Download now</a> |
|
See the <a href="faq.html">FAQ</a> | <a href="http://sourceforge.net/project/showfiles.php?group_id=139894">Download now</a> |
|
||||||
<a href="/mailman/listinfo/pymilter">Subscribe to mailing list</a> |
|
<a href="http://bmsi.com/mailman/listinfo/pymilter">Subscribe to mailing list</a> |
|
||||||
<a href="#overview">Overview</a> |
|
<a href="#overview">Overview</a> |
|
||||||
<a href="/python/dspam.html">pydspam</a> |
|
<a href="/python/dspam.html">pydspam</a> |
|
||||||
<a href="/libdspam/dspam.html">libdspam</a>
|
<a href="/libdspam/dspam.html">libdspam</a>
|
||||||
@@ -45,181 +40,6 @@ separation features to enhance security. Even better, sendmail 8.13
|
|||||||
supports socket maps, which makes <a href="pysrs.html">pysrs</a> much more
|
supports socket maps, which makes <a href="pysrs.html">pysrs</a> much more
|
||||||
efficient and secure. I recommend upgrading.
|
efficient and secure. I recommend upgrading.
|
||||||
|
|
||||||
<h2> Recent Changes </h2>
|
|
||||||
|
|
||||||
Python milter has been moved to
|
|
||||||
<a href="http://sourceforge.net/projects/pymilter/">pymilter Sourceforge
|
|
||||||
project</a> for development and release downloads.
|
|
||||||
<p>
|
|
||||||
Release 0.8.4 makes configuring SPF policy via access.db actually work.
|
|
||||||
The honeypot idea is enhanced by auto-whitelisting recipients of
|
|
||||||
email sent from selected domains. Whitelisted messages are then used
|
|
||||||
to train the honeypot. This makes the honeypot screener entirely self
|
|
||||||
training. The smfi_progress() API is now automatically supported when present.
|
|
||||||
An optional idx parameter to milter.addheader() invokes smfi_insheader().
|
|
||||||
<p>
|
|
||||||
Release 0.8.3 uses the standard logging module, and supports configuring
|
|
||||||
more detailed SPF policy via the sendmail access map. SMTP AUTH connections
|
|
||||||
are considered INTERNAL. Preventing forgery between internal domains is
|
|
||||||
just a matter of specifying the user-domain map - I'll define something
|
|
||||||
for the next version. We now send DSNs when mail is quarantined (rejecting
|
|
||||||
if DSN fails) and for SPF syntax errors (PermError). There is an
|
|
||||||
experimental option to add a Sender header when it is missing and the From
|
|
||||||
domain doesn't match the MAIL FROM domain. Next release, we may start
|
|
||||||
renaming and replacing an existing Sender header when neither it nor the
|
|
||||||
From domain matches MAIL FROM. Since bogus MAIL FROMs are rejected
|
|
||||||
(to varying degrees depending on the configured SPF policy), and
|
|
||||||
both Sender and From and displayed by default in many email clients,
|
|
||||||
this provides some phishing protection without rejecting mail based
|
|
||||||
on headers.
|
|
||||||
<p>
|
|
||||||
Release 0.8.2 has changes to <a href="http://openspf.net">SPF</a> to bring it
|
|
||||||
in line with the newly official RFC. It adds
|
|
||||||
<a href="http://ses.codeshare.ca/">SES</a>
|
|
||||||
support (the original SES without body hash) for pysrs-0.30.10, and honeypot
|
|
||||||
support for pydspam-1.1.9. There is a new method in the base milter module.
|
|
||||||
milter.set_exception_policy(i) lets you choose a policy of CONTINUE, REJECT, or
|
|
||||||
TEMPFAIL (default) for untrapped exceptions encountered in a milter callback.
|
|
||||||
<p>
|
|
||||||
Release 0.8.0 is the first <a href="http://sourceforge.net/">Sourceforge</a>
|
|
||||||
release. It supports Python-2.4, and provides an option to accept mail
|
|
||||||
that gets an SPF softfail or fails the 3 strikes rule, provided the
|
|
||||||
alleged sender accepts a DSN explaining the problem. Python-2.3 is
|
|
||||||
no longer supported by the reworked mime.py module, although API changes
|
|
||||||
could be backported. There are too many incompatible changes to the
|
|
||||||
python email package.
|
|
||||||
<p>
|
|
||||||
Release 0.7.2 tightens the authentication screws with a "3 strikes and
|
|
||||||
you're out" policy. A sender must have a valid PTR, HELO, or SPF record
|
|
||||||
to send email. Specific senders can be whitelisted using the
|
|
||||||
"delegate" option in the spf configuration section by adding a
|
|
||||||
default SPF record for them. The PTR and HELO are required
|
|
||||||
by RFC anyway, so this is not an unreasonable requirement.
|
|
||||||
There is now a coherent policy for an SPF softfail result. A softfail
|
|
||||||
is accepted if there is a valid PTR or HELO, or if the domain
|
|
||||||
is listed in the "accept_softfail" option of the spf configuration section.
|
|
||||||
A neutral result is accepted by default if there is a valid PTR or
|
|
||||||
HELO, (and the SPF record was not guessed), unless the domain is listed in the
|
|
||||||
"reject_neutral" option. Common forms of PTR records for dynamic IPs are
|
|
||||||
recognized, and do not count as a valid PTR. This does not prevent anyone
|
|
||||||
from sending mail from a dynamic IP - they just need to configure a
|
|
||||||
valid HELO name or publish an SPF record.
|
|
||||||
<p>
|
|
||||||
As SPF adoption continues to rise, forged spam is not getting through. So
|
|
||||||
spammers are publishing their SPF records as predicted. The 0.7.2 RPM
|
|
||||||
now provides the <code>rhsbl</code> sendmail hack so that spammer domains
|
|
||||||
can be blacklisted. With the RPM installed, add a line like the following
|
|
||||||
to your <code>sendmail.mc</code>.
|
|
||||||
<pre>
|
|
||||||
HACK(rhsbl,`blackholes.example.com',"550 Rejected: " $&{RHS} " has been spamming our customers.")dnl
|
|
||||||
</pre>
|
|
||||||
<p>
|
|
||||||
Of course, spammers are now starting to register
|
|
||||||
throwaway domains. The next thing we need is a custom DNS server,
|
|
||||||
in Python, that
|
|
||||||
can recognize patterns. For instance, one spammer registers ded304.com,
|
|
||||||
ded305.com, ded306.com, etc. We also need the custom DNS server to
|
|
||||||
let SPF classic clients check SES (which will be part of pysrs).
|
|
||||||
The <a href="http://twistedmatrix.com/products/twisted">Twisted Python</a>
|
|
||||||
framework provides a custom DNS server - but I
|
|
||||||
would like a smaller implementation for our use.
|
|
||||||
<p>
|
|
||||||
The RPM for release 0.7.0 moves the config file and socket locations to
|
|
||||||
/etc/mail and /var/run/milter respectively. We now parse Microsoft CID records
|
|
||||||
- but only hotmail.com uses them. They seem to have applied for a patent on
|
|
||||||
the brilliant idea of examining the mail headers to see who the message is
|
|
||||||
from. We aren't doing that here, so not to worry - but I am not a lawyer, so
|
|
||||||
if you are worried, change spf.py around line 626 to return None instead of
|
|
||||||
calling CIDParser(). There is a new option to reject mail with no PTR
|
|
||||||
and no SPF.
|
|
||||||
<p>
|
|
||||||
Microsoft is pushing an anti-opensource license for their pending patent
|
|
||||||
along with their sender-ID proposal before the IETF.
|
|
||||||
It is royalty free - but requires anyone distributing a binary they've
|
|
||||||
compiled from source to sign a license agreement. The Apache Software
|
|
||||||
Foundation <a
|
|
||||||
href="http://www.apache.org/foundation/docs/sender-id-position.html"> explains
|
|
||||||
the problem with sender-ID</a>, and Debian <a
|
|
||||||
href="http://www.debian.org/News/2004/20040904">concurs</a>. Since
|
|
||||||
the <a href="http://download.microsoft.com/download/4/3/9/439b024b-09fd-44ee-8ff0-10e834004c36/senderid_FAQ.PDF">Microsoft license</a> is
|
|
||||||
<a href="http://www.circleid.com/article/732_0_1_0_C/">incompatible with free
|
|
||||||
software in general</a> and the <a
|
|
||||||
href="http://www.imc.org/ietf-mxcomp/mail-archive/msg03678.html">GPL in
|
|
||||||
particular</a>, Python milter will not be able to implement sender-ID in its
|
|
||||||
current form. This was, no doubt, Microsoft's intent all along.
|
|
||||||
<p>
|
|
||||||
Sender-ID attempts to do for RFC2822 headers what SPF does for RFC2821 headers.
|
|
||||||
Unlike SPF, it has never been tried, and is encumbered by a stupid patent. I
|
|
||||||
recommend ignoring it and continuing to implement and improve SPF until a
|
|
||||||
working and unencumbered proposal for RFC2822 headers surfaces.
|
|
||||||
|
|
||||||
<p>
|
|
||||||
<a href="http://openspf.com">
|
|
||||||
<img src="SPF.gif" align=left alt="SPF logo"></a>
|
|
||||||
Release 0.6.6 adds support for <a href="http://openspf.com/">SPF</a>,
|
|
||||||
a protocol to prevent forging of the envelope from address.
|
|
||||||
SPF support requires <a href="http://pydns.sourceforge.net/">pydns</a>.
|
|
||||||
The included spf.py module is an updated version of the original 1.6
|
|
||||||
version at <a href="http://www.wayforward.net/spf/">wayforward.net</a>.
|
|
||||||
The updated version tracks the draft RFC and test suite.
|
|
||||||
<p>
|
|
||||||
The FAQ addresses <a href="faq.html#spf">how to get started with SPF</a>.
|
|
||||||
<p>
|
|
||||||
Release 0.6.1 adds a full milter based dspam application.
|
|
||||||
<p>
|
|
||||||
I have selected the <a href="http://www.nuclearelephant.com/projects/dspam/">
|
|
||||||
dspam bayes filter project</a> and <a href="dspam.html">
|
|
||||||
packaged it for python</a>.
|
|
||||||
Release 0.6.0 offers a simple application of dspam I call "header triage",
|
|
||||||
which rejects messages with spammy headers.
|
|
||||||
To use header triage, you must have <a href="dspam.html">DSPAM</a> installed,
|
|
||||||
and select a dictionary that is well moderated by someone who gets
|
|
||||||
lots of spam. That dictionary can be used to block spam that is
|
|
||||||
obvious from the headers (e.g. X-Mailer and Subject) before it ties
|
|
||||||
up any more resources. I have yet to see any false positives from this
|
|
||||||
approach (check the milter log), but if there are, the sender will
|
|
||||||
get a REJECT with the message "Your message looks spammy."
|
|
||||||
|
|
||||||
<h2> Enough Already! </h2>
|
|
||||||
|
|
||||||
Nearly a dozen people have emailed me begging for a feature to copy
|
|
||||||
outgoing and/or incoming mail to a backup directory by user. Ok, it
|
|
||||||
looks like this is a most requested feature for 0.5.6. In the meantime,
|
|
||||||
here are some things to consider:
|
|
||||||
<ul>
|
|
||||||
<li> If you want to equivalent of a Bcc added to each message, this
|
|
||||||
is very easy to do in the python code for bms.py. See below.
|
|
||||||
<li> If you want to copy to a file in a directory (thus avoiding having to
|
|
||||||
set up aliases), this is slightly more involved. The bms.py milter already
|
|
||||||
copies the message to a temporary file for use in replacing the message body
|
|
||||||
when banned attachments are found. You have to open a file, and copy the
|
|
||||||
Mesage object to it in eom().
|
|
||||||
<li> Finally, you are probably aware that most email clients already
|
|
||||||
keep a copy of outgoing mail? Presumably there is a good reason for
|
|
||||||
keeping another copy on the server.
|
|
||||||
</ul>
|
|
||||||
<p>
|
|
||||||
To Bcc a message, call <code>self.add_recipient(rcpt)</code> in envfrom after
|
|
||||||
determining whether you want to copy (e.g. whether the sender is local). For
|
|
||||||
example,
|
|
||||||
<pre>
|
|
||||||
def envfrom(...
|
|
||||||
...
|
|
||||||
if len(t) == 2:
|
|
||||||
self.rejectvirus = t[1] in reject_virus_from
|
|
||||||
if t[0] in wiretap_users.get(t[1],()):
|
|
||||||
self.add_recipient(wiretap_dest)
|
|
||||||
if t[1] == 'mydomain.com':
|
|
||||||
self.add_recipient('<copy-%s>' % t[0])
|
|
||||||
...
|
|
||||||
</pre>
|
|
||||||
<p>
|
|
||||||
To make this a generic feature requires thinking about how the configuration
|
|
||||||
would look. Feel free to make specific suggestions about config file
|
|
||||||
entries. Be sure to handle both Bcc and file copies, and designating what
|
|
||||||
mail should be copied. How should "outgoing" be defined? Implementing it is
|
|
||||||
easy once the configuration is designed.
|
|
||||||
|
|
||||||
<h3><a name=overview>Overview</a></h3>
|
<h3><a name=overview>Overview</a></h3>
|
||||||
|
|
||||||
This package provides a robust toolkit for Python <a
|
This package provides a robust toolkit for Python <a
|
||||||
@@ -400,6 +220,8 @@ me if you successfully install milter on a system not mentioned below.
|
|||||||
<td>0.5.5</td><tr>
|
<td>0.5.5</td><tr>
|
||||||
<td>RedHat 7.3</td><td>gcc-2.96</td><td>2.3.3</td><td>8.13.1</td>
|
<td>RedHat 7.3</td><td>gcc-2.96</td><td>2.3.3</td><td>8.13.1</td>
|
||||||
<td>0.7.2</td><tr>
|
<td>0.7.2</td><tr>
|
||||||
|
<td>RedHat 7.3</td><td>gcc-2.96</td><td>2.4.1</td><td>8.13.5</td>
|
||||||
|
<td>0.8.4</td><tr>
|
||||||
<td>RedHat 8.0</td><td>gcc-3.2</td><td>2.2.1</td><td>8.12.6</td>
|
<td>RedHat 8.0</td><td>gcc-3.2</td><td>2.2.1</td><td>8.12.6</td>
|
||||||
<td>0.5.2</td><tr>
|
<td>0.5.2</td><tr>
|
||||||
<td>Debian Linux</td><td>gcc-2.95.2</td><td>2.1.1</td><td>8.12.0</td>
|
<td>Debian Linux</td><td>gcc-2.95.2</td><td>2.1.1</td><td>8.12.0</td>
|
||||||
@@ -412,8 +234,8 @@ me if you successfully install milter on a system not mentioned below.
|
|||||||
<td>0.3.4</td><tr>
|
<td>0.3.4</td><tr>
|
||||||
<td>AIX-4.1.5</td><td>gcc-2.95.2</td><td>2.1.3</td><td>8.12.3</td>
|
<td>AIX-4.1.5</td><td>gcc-2.95.2</td><td>2.1.3</td><td>8.12.3</td>
|
||||||
<td>0.4.2</td><tr>
|
<td>0.4.2</td><tr>
|
||||||
<td>AIX-4.1.5</td><td>gcc-2.95.2</td><td>2.2.3</td><td>8.13.1</td>
|
<td>AIX-4.1.5</td><td>gcc-2.95.2</td><td>2.4.1</td><td>8.13.1</td>
|
||||||
<td>0.7.1</td><tr>
|
<td>0.8.4</td><tr>
|
||||||
<td>Slackware 7.1</td><td>?</td><td>?</td><td>8.12.1</td>
|
<td>Slackware 7.1</td><td>?</td><td>?</td><td>8.12.1</td>
|
||||||
<td>0.3.8</td><tr>
|
<td>0.3.8</td><tr>
|
||||||
<td>Slackware 9.0</td><td>gcc-3.2.2</td><td>2.2.3</td><td>8.12.9</td>
|
<td>Slackware 9.0</td><td>gcc-3.2.2</td><td>2.2.3</td><td>8.12.9</td>
|
||||||
@@ -427,108 +249,54 @@ me if you successfully install milter on a system not mentioned below.
|
|||||||
<td>FreeBSD</td><td>gcc-2.95.3</td><td>2.2.2</td><td>?</td>
|
<td>FreeBSD</td><td>gcc-2.95.3</td><td>2.2.2</td><td>?</td>
|
||||||
<td>0.5.5</td><tr>
|
<td>0.5.5</td><tr>
|
||||||
<td>FreeBSD 4.4</td><td>gcc-2.95.3</td><td>?</td><td>8.12.10</td>
|
<td>FreeBSD 4.4</td><td>gcc-2.95.3</td><td>?</td><td>8.12.10</td>
|
||||||
<td>0.6.6</td><tr>
|
<td>0.6.6</td>
|
||||||
|
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
<h3> Requirements </h3>
|
<h2> Enough Already! </h2>
|
||||||
|
|
||||||
<menu>
|
Nearly a dozen people have emailed me begging for a feature to copy
|
||||||
<li> While the miltermodule will work with python 1.5, you probably
|
outgoing and/or incoming mail to a backup directory by user. Ok, it
|
||||||
want to use python 2.0 or better. The python code uses a number of
|
looks like this is a most requested feature for 0.5.6. In the meantime,
|
||||||
python 2 features.
|
here are some things to consider:
|
||||||
<li> Python must be configured with thread support. This is because
|
<ul>
|
||||||
sendmail's libmilter requires thread support.
|
<li> If you want to equivalent of a Bcc added to each message, this
|
||||||
<li> You must compile sendmail with libmilter enabled. In versions of
|
is very easy to do in the python code for bms.py. See below.
|
||||||
sendmail prior to 8.12 libmilter is marked FFR (For Future Release) and
|
<li> If you want to copy to a file in a directory (thus avoiding having to
|
||||||
is not installed by default.
|
set up aliases), this is slightly more involved. The bms.py milter already
|
||||||
Sendmail 8.12 still does not enable libmilter by default. You must
|
copies the message to a temporary file for use in replacing the message body
|
||||||
explicitly select the "MILTER" option when compiling.
|
when banned attachments are found. You have to open a file, and copy the
|
||||||
<li> Python milter has been tested against sendmail-8.11 and sendmail-8.12.
|
Mesage object to it in eom().
|
||||||
<li> Python milter must be compiled for the specific version of sendmail
|
<li> Finally, you are probably aware that most email clients already
|
||||||
it will run with. (Since the result is dynamically loaded, there could
|
keep a copy of outgoing mail? Presumably there is a good reason for
|
||||||
conceivably be multiple versions available and selected at startup - but
|
keeping another copy on the server.
|
||||||
that will have to wait.) This situation may only exist for sendmail
|
</ul>
|
||||||
versions prior to 8.12. The protocol seems designed for backward
|
|
||||||
compatibility - and 8.12 is the first official milter release.
|
|
||||||
<li> Mea Culpa! After reading the Python Style guide, I realize that
|
|
||||||
my Python code is not up to snuff. Apparently mixed tabs and spaces
|
|
||||||
are anathema to those using Windows editors, where tabs can be expanded using
|
|
||||||
any arbitrary algorithm. Other than that, my
|
|
||||||
intuition matched Guido's pretty well - although I like to indent by 2
|
|
||||||
rather than 4. I will arrange to have tabs expanded to spaces when
|
|
||||||
exporting new versions. Until then, beware!
|
|
||||||
</menu>
|
|
||||||
|
|
||||||
<h3> <a name="aix4"> AIX 4.1.5 Requirements </a> </h3>
|
|
||||||
To create sendmail RPMs for AIX, you can download my AIX 4.1.5 spec files
|
|
||||||
for <a href="/aix/sendmail.spec">sendmail-8.11.5</a>
|
|
||||||
or <a href="/aix/sendmail12.spec">sendmail-8.12.3</a>. If you have
|
|
||||||
not already set it up, I use a <a href="/aix/aix.spec">dummy RPM package</a>
|
|
||||||
to represent the stuff that comes with AIX. You might also want
|
|
||||||
my <a href="/aix/python.spec">python-2.1.1</a> spec file for AIX. It
|
|
||||||
does not include Tk or curses modules, sorry. If y'all trust me, you can
|
|
||||||
download rpms for AIX 4.x from my <a href="/aix">AIX RPM directory</a>.
|
|
||||||
<p>
|
<p>
|
||||||
Sendmail-8.12 renames
|
To Bcc a message, call <code>self.add_recipient(rcpt)</code> in envfrom after
|
||||||
libsmutil.a to libsm.a. Unfortunately, libsm.a is an important AIX system
|
determining whether you want to copy (e.g. whether the sender is local). For
|
||||||
shared library. Therefore, I rename libsm.a back to libsmutil.a for
|
example,
|
||||||
AIX. This presents a problem for setup.py.
|
<pre>
|
||||||
|
def envfrom(...
|
||||||
<h3> <a name="rh72"> RedHat 7.2 Requirements </a> </h3>
|
...
|
||||||
|
if len(t) == 2:
|
||||||
If you are running Redhat 7.2, the distributed version of sendmail
|
self.rejectvirus = t[1] in reject_virus_from
|
||||||
now enables libmilter by default. RedHat 7.2 bundles
|
if t[0] in wiretap_users.get(t[1],()):
|
||||||
the development libraries with the main sendmail package, so
|
self.add_recipient(wiretap_dest)
|
||||||
there is no sendmail-devel package. However, they forgot to include the
|
if t[1] == 'mydomain.com':
|
||||||
headers! So you'll have to get the SRPM and modify it. I suggest
|
self.add_recipient('<copy-%s>' % t[0])
|
||||||
moving the static libs to a devel package and adding the headers. If
|
...
|
||||||
this is too much trouble, you can get the <a href="mfapi.h">mfapi.h</a>
|
</pre>
|
||||||
header for sendmail-8.6.11 from here and manually install it as
|
|
||||||
<code>/usr/include/libmilter/mfapi.h</code>.
|
|
||||||
<p>
|
<p>
|
||||||
If you do modify the SRPM, I suggest renaming libsmutil.a
|
To make this a generic feature requires thinking about how the configuration
|
||||||
to libsm.a - just like sendmail-8.12 will. If you manually install
|
would look. Feel free to make specific suggestions about config file
|
||||||
mfapi.h or don't rename libsmutil.a, you'll
|
entries. Be sure to handle both Bcc and file copies, and designating what
|
||||||
need to force <code>libs = ["milter", "smutil"]</code> in setup.py.
|
mail should be copied. How should "outgoing" be defined? Implementing it is
|
||||||
<p>
|
easy once the configuration is designed.
|
||||||
If you have installed python2, and want
|
|
||||||
python-milter to use python2, add <code>python=python2</code> to setup.cfg
|
|
||||||
and build with <code>python2 setup.py bdist_rpm</code>.
|
|
||||||
|
|
||||||
<h3> <a name="rh62"> Redhat 6.2 Requirements </a> </h3>
|
|
||||||
|
|
||||||
If you are running Redhat 6.2, the distributed version of sendmail
|
|
||||||
does not enable libmilter. You can download the Redhat 7.2 sendmail.spec
|
|
||||||
modified to compile on RedHat 6.2:
|
|
||||||
<a href="http://www.bmsi.com/linux/rh62/sendmail-rhmilter.spec">
|
|
||||||
sendmail-rhmilter.spec</a>. The <a
|
|
||||||
href="ftp://updates.redhat.com/7.0/en/os/SRPMS/sendmail-8.11.6-1.7.0.src.rpm">
|
|
||||||
SRPM for sendmail-8.11.6</a> is available from
|
|
||||||
<a href="http://www.redhat.com">Redhat</a> under
|
|
||||||
<a href="http://www.redhat.com/support/errata/RHSA-2001-106.html">
|
|
||||||
Errata for RH6.2</a>. But that doesn't include the latest security
|
|
||||||
patches since RH6.2 is no longer supported.
|
|
||||||
<p>
|
|
||||||
If y'all trust me, you can pick up source and binary sendmail RPMs for RH6.2
|
|
||||||
from my <a href="http://www.bmsi.com/linux/rh62">linux downloads</a> directory.
|
|
||||||
The lastest RPMs were built by taking a RH7.2 SRPMS and removing some
|
|
||||||
RPM features from the spec file that RH6.2 doesn't support, then
|
|
||||||
recompiling on RH6.2. You can check this by installing the RH7.2 SRPM,
|
|
||||||
then diffing my sendmail.spec with theirs. Then run
|
|
||||||
"rpm -bb sendmail-rhmilter.spec" when you are satisfied.
|
|
||||||
<p>
|
|
||||||
If you have installed python2, and want
|
|
||||||
python-milter to use python2, add <code>python=python2</code> to setup.cfg
|
|
||||||
and build with <code>python2 setup.py bdist_rpm</code>.
|
|
||||||
You'll need to install the sendmail-devel package to compile milter.
|
|
||||||
|
|
||||||
<hr>
|
<hr>
|
||||||
<p>
|
<p>
|
||||||
<a href="http://validator.w3.org/check/referer">
|
<a href="http://validator.w3.org/check/referer">
|
||||||
<img border=0 src="/vh32.png" alt=" [ Valid HTML 3.2! ] " height=31 width=88></a>
|
<img border=0 src="http://bmsi.com/vh32.png" alt=" [ Valid HTML 3.2! ] " height=31 width=88></a>
|
||||||
<a href="http://www.redhat.com">
|
<a href="http://www.redhat.com">
|
||||||
<img src="/art/powered_by.gif" width="88" height="31" alt=" [ Powered By Red Hat Linux ] " border="0"></a>
|
<img src="http://bmsi.com/art/powered_by.gif" width="88" height="31" alt=" [ Powered By Red Hat Linux ] " border="0"></a>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
</body></html>
|
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 2.7 KiB |
@@ -0,0 +1,92 @@
|
|||||||
|
<h2> Requirements </h2>
|
||||||
|
|
||||||
|
<menu>
|
||||||
|
<li> While the miltermodule will work with python 1.5, you probably
|
||||||
|
want to use python 2.0 or better. The python code uses a number of
|
||||||
|
python 2 features. The email support requires python 2.4.
|
||||||
|
<li> Python must be configured with thread support. This is because
|
||||||
|
sendmail's libmilter requires thread support.
|
||||||
|
<li> You must compile sendmail with libmilter enabled. In versions of
|
||||||
|
sendmail prior to 8.12 libmilter is marked FFR (For Future Release) and
|
||||||
|
is not installed by default.
|
||||||
|
Sendmail 8.12 still does not enable libmilter by default. You must
|
||||||
|
explicitly select the "MILTER" option when compiling.
|
||||||
|
<li> Python milter has been tested against sendmail-8.11 and sendmail-8.12.
|
||||||
|
<li> Python milter must be compiled for the specific version of sendmail
|
||||||
|
it will run with. (Since the result is dynamically loaded, there could
|
||||||
|
conceivably be multiple versions available and selected at startup - but
|
||||||
|
that will have to wait.) This situation may only exist for sendmail
|
||||||
|
versions prior to 8.12. The protocol seems designed for backward
|
||||||
|
compatibility - and 8.12 is the first official milter release.
|
||||||
|
<li> Mea Culpa! After reading the Python Style guide, I realize that
|
||||||
|
my Python code is not up to snuff. Apparently mixed tabs and spaces
|
||||||
|
are anathema to those using Windows editors, where tabs can be expanded using
|
||||||
|
any arbitrary algorithm. Other than that, my
|
||||||
|
intuition matched Guido's pretty well - although I like to indent by 2
|
||||||
|
rather than 4. I will arrange to have tabs expanded to spaces when
|
||||||
|
exporting new versions. Until then, beware!
|
||||||
|
</menu>
|
||||||
|
|
||||||
|
<h3> <a name="aix4"> AIX 4.1.5 Requirements </a> </h3>
|
||||||
|
To create sendmail RPMs for AIX, you can download my AIX 4.1.5 spec files
|
||||||
|
for <a href="/aix/sendmail.spec">sendmail-8.11.5</a>
|
||||||
|
or <a href="/aix/sendmail12.spec">sendmail-8.12.3</a>. If you have
|
||||||
|
not already set it up, I use a <a href="/aix/aix.spec">dummy RPM package</a>
|
||||||
|
to represent the stuff that comes with AIX. You might also want
|
||||||
|
my <a href="/aix/python.spec">python-2.1.1</a> spec file for AIX. It
|
||||||
|
does not include Tk or curses modules, sorry. If y'all trust me, you can
|
||||||
|
download rpms for AIX 4.x from my <a href="/aix">AIX RPM directory</a>.
|
||||||
|
<p>
|
||||||
|
Sendmail-8.12 renames
|
||||||
|
libsmutil.a to libsm.a. Unfortunately, libsm.a is an important AIX system
|
||||||
|
shared library. Therefore, I rename libsm.a back to libsmutil.a for
|
||||||
|
AIX. This presents a problem for setup.py.
|
||||||
|
|
||||||
|
<h3> <a name="rh72"> RedHat 7.2 Requirements </a> </h3>
|
||||||
|
|
||||||
|
If you are running Redhat 7.2, the distributed version of sendmail
|
||||||
|
now enables libmilter by default. RedHat 7.2 bundles
|
||||||
|
the development libraries with the main sendmail package, so
|
||||||
|
there is no sendmail-devel package. However, they forgot to include the
|
||||||
|
headers! So you'll have to get the SRPM and modify it. I suggest
|
||||||
|
moving the static libs to a devel package and adding the headers. If
|
||||||
|
this is too much trouble, you can get the <a href="mfapi.h">mfapi.h</a>
|
||||||
|
header for sendmail-8.6.11 from here and manually install it as
|
||||||
|
<code>/usr/include/libmilter/mfapi.h</code>.
|
||||||
|
<p>
|
||||||
|
If you do modify the SRPM, I suggest renaming libsmutil.a
|
||||||
|
to libsm.a - just like sendmail-8.12 will. If you manually install
|
||||||
|
mfapi.h or don't rename libsmutil.a, you'll
|
||||||
|
need to force <code>libs = ["milter", "smutil"]</code> in setup.py.
|
||||||
|
<p>
|
||||||
|
If you have installed python2, and want
|
||||||
|
python-milter to use python2, add <code>python=python2</code> to setup.cfg
|
||||||
|
and build with <code>python2 setup.py bdist_rpm</code>.
|
||||||
|
|
||||||
|
<h3> <a name="rh62"> Redhat 6.2 Requirements </a> </h3>
|
||||||
|
|
||||||
|
If you are running Redhat 6.2, the distributed version of sendmail
|
||||||
|
does not enable libmilter. You can download the Redhat 7.2 sendmail.spec
|
||||||
|
modified to compile on RedHat 6.2:
|
||||||
|
<a href="http://www.bmsi.com/linux/rh62/sendmail-rhmilter.spec">
|
||||||
|
sendmail-rhmilter.spec</a>. The <a
|
||||||
|
href="ftp://updates.redhat.com/7.0/en/os/SRPMS/sendmail-8.11.6-1.7.0.src.rpm">
|
||||||
|
SRPM for sendmail-8.11.6</a> is available from
|
||||||
|
<a href="http://www.redhat.com">Redhat</a> under
|
||||||
|
<a href="http://www.redhat.com/support/errata/RHSA-2001-106.html">
|
||||||
|
Errata for RH6.2</a>. But that doesn't include the latest security
|
||||||
|
patches since RH6.2 is no longer supported.
|
||||||
|
<p>
|
||||||
|
If y'all trust me, you can pick up source and binary sendmail RPMs for RH6.2
|
||||||
|
from my <a href="http://www.bmsi.com/linux/rh62">linux downloads</a> directory.
|
||||||
|
The lastest RPMs were built by taking a RH7.2 SRPMS and removing some
|
||||||
|
RPM features from the spec file that RH6.2 doesn't support, then
|
||||||
|
recompiling on RH6.2. You can check this by installing the RH7.2 SRPM,
|
||||||
|
then diffing my sendmail.spec with theirs. Then run
|
||||||
|
"rpm -bb sendmail-rhmilter.spec" when you are satisfied.
|
||||||
|
<p>
|
||||||
|
If you have installed python2, and want
|
||||||
|
python-milter to use python2, add <code>python=python2</code> to setup.cfg
|
||||||
|
and build with <code>python2 setup.py bdist_rpm</code>.
|
||||||
|
You'll need to install the sendmail-devel package to compile milter.
|
||||||
|
|
||||||
Reference in New Issue
Block a user