diff --git a/doc/Maxwells.gif b/doc/Maxwells.gif new file mode 100644 index 0000000..3175fe9 Binary files /dev/null and b/doc/Maxwells.gif differ diff --git a/doc/SPF.gif b/doc/SPF.gif new file mode 100644 index 0000000..8810647 Binary files /dev/null and b/doc/SPF.gif differ diff --git a/doc/changes.ht b/doc/changes.ht new file mode 100644 index 0000000..3d2820b --- /dev/null +++ b/doc/changes.ht @@ -0,0 +1,157 @@ +

Recent Changes

+ +Python milter has been moved to +pymilter Sourceforge +project for development and release downloads. + +

New website design

+ +Hey, I'm no artist, so I just used the + package +by Barry Warsaw. The mascot +is by Christian Hafner, +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 + +simulation that lets you try your hand at sorting molecules. + +

0.8.4

+ +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(). + +

0.8.3

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

0.8.2

+ +Release 0.8.2 has changes to SPF to bring it +in line with the newly official RFC. It adds +SES +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. + +

0.8.0

+ +Release 0.8.0 is the first Sourceforge +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. + +

Older Releases

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

+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 rhsbl sendmail hack so that spammer domains +can be blacklisted. With the RPM installed, add a line like the following +to your sendmail.mc. +

+HACK(rhsbl,`blackholes.example.com',"550 Rejected: " $&{RHS} " has been spamming our customers.")dnl
+
+

+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 Twisted Python +framework provides a custom DNS server - but I +would like a smaller implementation for our use. +

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

+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 explains +the problem with sender-ID, and Debian concurs. Since +the Microsoft license is +incompatible with free +software in general and the GPL in +particular, Python milter will not be able to implement sender-ID in its +current form. This was, no doubt, Microsoft's intent all along. +

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

+ +SPF logo +Release 0.6.6 adds support for SPF, +a protocol to prevent forging of the envelope from address. +SPF support requires pydns. +The included spf.py module is an updated version of the original 1.6 +version at wayforward.net. +The updated version tracks the draft RFC and test suite. +

+The FAQ addresses how to get started with SPF. +

+Release 0.6.1 adds a full milter based dspam application. +

+I have selected the +dspam bayes filter project and +packaged it for python. +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 DSPAM 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." + diff --git a/doc/credits.ht b/doc/credits.ht new file mode 100644 index 0000000..30b0e60 --- /dev/null +++ b/doc/credits.ht @@ -0,0 +1,49 @@ +

CREDITS

+ +Jim Niemira +wrote the original C module and some quick +and dirty python to use it. +Stuart D. Gathman +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. + +

Other contributors (in random order):

+ +
+
Christian Hafner +
for the pymilter mascot image of + + Maxwell's daemon +
Dave MacQuigg +
for noticing that smfi_insheader wasn't supported, and creating + a template to help first time pymilter users create their own milter. +
Terence Way +
for providing a Python port of SPF +
Scott Kitterman +
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 +
Alexander Kourakos +
for plugging several memory leaks +
George Graf at Vienna University of Economics and Business Administration +
for handling None passed to setreply and chgheader. +
Deron Meranda +
for IPv6 patches +
Jason Erikson +
for handling NULL hostaddr in connect callback. +
John Draper +
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. +
Eric S. Johansson +
for helpful design discussions while working on camram +
Alex Savguira +
for finding bugs with international headers and + suggesting the scan_zip option. +
Business Management Systems +
for hosting the website, and providing paying clients who need milter + service so I can work on it as part of my day job. +
+ +If I have left anybody out, send me a reminder: +stuart@bmsi.com diff --git a/faq.html b/doc/faq.ht similarity index 99% rename from faq.html rename to doc/faq.ht index 6838ed7..206df0a 100644 --- a/faq.html +++ b/doc/faq.ht @@ -22,7 +22,7 @@ shows you how to install libmilter with a separate invocation of make.
  • Q. Why is mfapi.h not found when I try to compile Python milter on RedHat 7.2?

    A. RedHat forgot to include the header in the RPM. See the -RedHat 7.2 requirements. +RedHat 7.2 requirements.

    Running Python Milter

    diff --git a/logmsgs.html b/doc/logmsgs.ht similarity index 100% rename from logmsgs.html rename to doc/logmsgs.ht diff --git a/milter.html b/doc/milter.ht similarity index 50% rename from milter.html rename to doc/milter.ht index d2298c2..5a465e1 100644 --- a/milter.html +++ b/doc/milter.ht @@ -1,33 +1,28 @@ - - - - -Python Milters -

    -Viewable With Any Browser -Your vote? I Disagree I Agree -

    + +Maxwell's Daemon: pymilter mascot

    Sendmail Milters in Python

    by Jim Niemira and Stuart D. Gathman
    This web page is written by Stuart D. Gathman
    and
    sponsored by Business Management Systems, Inc.
    -Last updated Oct 20, 2005

    +Last updated Oct 25, 2005 See the FAQ | Download now | -Subscribe to mailing list | +Subscribe to mailing list | Overview | pydspam | libdspam @@ -45,181 +40,6 @@ separation features to enhance security. Even better, sendmail 8.13 supports socket maps, which makes pysrs much more efficient and secure. I recommend upgrading. -

    Recent Changes

    - -Python milter has been moved to -pymilter Sourceforge -project for development and release downloads. -

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

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

    -Release 0.8.2 has changes to SPF to bring it -in line with the newly official RFC. It adds -SES -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. -

    -Release 0.8.0 is the first Sourceforge -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. -

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

    -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 rhsbl sendmail hack so that spammer domains -can be blacklisted. With the RPM installed, add a line like the following -to your sendmail.mc. -

    -HACK(rhsbl,`blackholes.example.com',"550 Rejected: " $&{RHS} " has been spamming our customers.")dnl
-
    -

    -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 Twisted Python -framework provides a custom DNS server - but I -would like a smaller implementation for our use. -

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

    -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 explains -the problem with sender-ID, and Debian concurs. Since -the Microsoft license is -incompatible with free -software in general and the GPL in -particular, Python milter will not be able to implement sender-ID in its -current form. This was, no doubt, Microsoft's intent all along. -

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

    - -SPF logo -Release 0.6.6 adds support for SPF, -a protocol to prevent forging of the envelope from address. -SPF support requires pydns. -The included spf.py module is an updated version of the original 1.6 -version at wayforward.net. -The updated version tracks the draft RFC and test suite. -

    -The FAQ addresses how to get started with SPF. -

    -Release 0.6.1 adds a full milter based dspam application. -

    -I have selected the -dspam bayes filter project and -packaged it for python. -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 DSPAM 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." - -

    Enough Already!

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

    -To Bcc a message, call self.add_recipient(rcpt) in envfrom after -determining whether you want to copy (e.g. whether the sender is local). For -example, -

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

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

    Overview

    This package provides a robust toolkit for Python 0.5.5 RedHat 7.3gcc-2.962.3.38.13.1 0.7.2 +RedHat 7.3gcc-2.962.4.18.13.5 +0.8.4 RedHat 8.0gcc-3.22.2.18.12.6 0.5.2 Debian Linuxgcc-2.95.22.1.18.12.0 @@ -412,8 +234,8 @@ me if you successfully install milter on a system not mentioned below. 0.3.4 AIX-4.1.5gcc-2.95.22.1.38.12.3 0.4.2 -AIX-4.1.5gcc-2.95.22.2.38.13.1 -0.7.1 +AIX-4.1.5gcc-2.95.22.4.18.13.1 +0.8.4 Slackware 7.1??8.12.1 0.3.8 Slackware 9.0gcc-3.2.22.2.38.12.9 @@ -427,108 +249,54 @@ me if you successfully install milter on a system not mentioned below. FreeBSDgcc-2.95.32.2.2? 0.5.5 FreeBSD 4.4gcc-2.95.3?8.12.10 -0.6.6 - +0.6.6 -

    Requirements

    +

    Enough Already!

    - -
  • 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. -
  • Python must be configured with thread support. This is because -sendmail's libmilter requires thread support. -
  • 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. -
  • Python milter has been tested against sendmail-8.11 and sendmail-8.12. -
  • 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. -
  • 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! -
    •  - -

    AIX 4.1.5 Requirements

    -To create sendmail RPMs for AIX, you can download my AIX 4.1.5 spec files -for sendmail-8.11.5 -or sendmail-8.12.3. If you have -not already set it up, I use a dummy RPM package -to represent the stuff that comes with AIX. You might also want -my python-2.1.1 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 AIX RPM directory. +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: +

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

    RedHat 7.2 Requirements

    - -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 mfapi.h -header for sendmail-8.6.11 from here and manually install it as -/usr/include/libmilter/mfapi.h. +To Bcc a message, call self.add_recipient(rcpt) in envfrom after +determining whether you want to copy (e.g. whether the sender is local). For +example, +
    +  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])
+      ...
+

    -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 libs = ["milter", "smutil"] in setup.py. -

    -If you have installed python2, and want -python-milter to use python2, add python=python2 to setup.cfg -and build with python2 setup.py bdist_rpm. +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. -

    Redhat 6.2 Requirements

    - -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: - -sendmail-rhmilter.spec. The -SRPM for sendmail-8.11.6 is available from -Redhat under - -Errata for RH6.2. But that doesn't include the latest security -patches since RH6.2 is no longer supported. -

    -If y'all trust me, you can pick up source and binary sendmail RPMs for RH6.2 -from my linux downloads 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. -

    -If you have installed python2, and want -python-milter to use python2, add python=python2 to setup.cfg -and build with python2 setup.py bdist_rpm. -You'll need to install the sendmail-devel package to compile milter.

    - [ Valid HTML 3.2! ] + [ Valid HTML 3.2! ] - [ Powered By Red Hat Linux ] + [ Powered By Red Hat Linux ]

    - - diff --git a/policy.html b/doc/policy.ht similarity index 100% rename from policy.html rename to doc/policy.ht diff --git a/doc/python55.gif b/doc/python55.gif new file mode 100644 index 0000000..b7c0b9d Binary files /dev/null and b/doc/python55.gif differ diff --git a/doc/requirements.ht b/doc/requirements.ht new file mode 100644 index 0000000..d590f6b --- /dev/null +++ b/doc/requirements.ht @@ -0,0 +1,92 @@ +

    Requirements

    + + +
  • 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. +
  • Python must be configured with thread support. This is because +sendmail's libmilter requires thread support. +
  • 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. +
  • Python milter has been tested against sendmail-8.11 and sendmail-8.12. +
  • 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. +
  • 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! +
    •  + +

    AIX 4.1.5 Requirements

    +To create sendmail RPMs for AIX, you can download my AIX 4.1.5 spec files +for sendmail-8.11.5 +or sendmail-8.12.3. If you have +not already set it up, I use a dummy RPM package +to represent the stuff that comes with AIX. You might also want +my python-2.1.1 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 AIX RPM directory. +

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

    RedHat 7.2 Requirements

    + +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 mfapi.h +header for sendmail-8.6.11 from here and manually install it as +/usr/include/libmilter/mfapi.h. +

    +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 libs = ["milter", "smutil"] in setup.py. +

    +If you have installed python2, and want +python-milter to use python2, add python=python2 to setup.cfg +and build with python2 setup.py bdist_rpm. + +

    Redhat 6.2 Requirements

    + +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: + +sendmail-rhmilter.spec. The +SRPM for sendmail-8.11.6 is available from +Redhat under + +Errata for RH6.2. But that doesn't include the latest security +patches since RH6.2 is no longer supported. +

    +If y'all trust me, you can pick up source and binary sendmail RPMs for RH6.2 +from my linux downloads 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. +

    +If you have installed python2, and want +python-milter to use python2, add python=python2 to setup.cfg +and build with python2 setup.py bdist_rpm. +You'll need to install the sendmail-devel package to compile milter. +