<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.mail.spam.tmda.devel">
    <title>gmane.mail.spam.tmda.devel</title>
    <link>http://blog.gmane.org/gmane.mail.spam.tmda.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6861"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6860"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6856"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6852"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6849"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6846"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6844"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6841"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6839"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6832"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6828"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6827"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6825"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6824"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6861">
    <title>Suggestions for 8BITMIME capability</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6861</link>
    <description>&lt;pre&gt;There was a request some time back to get the 8BITMIME capability added
to tmda-ofmipd:

http://sourceforge.net/mailarchive/message.php?msg_id=25325009

As I understand it, this requires possibly re-encoding messages to a
7-bit format when transmitting to a host that doesn't advertise 8BITMIME
support. However, there's an interesting case made for a different
approach here:

http://cr.yp.to/smtp/8bitmime.html

Since this requires virtually no effort to implement, it's appealing to me.

Does anyone have any thoughts what approach to take? Also, I'm wondering
what difference 8BITMIME makes in practice. My mailer seems to send 8
bits without this capability advertised, which makes testing tricky. If
I knew of use-cases that actually fail without 8BITMIME, that might
help.

-Kevin

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-06-10T05:10:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6860">
    <title>IPv6 support now in trunk</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6860</link>
    <description>&lt;pre&gt;I've just pushed several commits, mostly around adding IPv6 support
(plus adding tests, fixing some minor issues).

This primarily adds IPv6 support to tmda-ofmipd (though it also allows
using the tmda-cgi simple-server in IPv6 mode to test tmda-cgi). There
are several areas where IPv6 needed to be addressed:

* Options for the address/port the server listens on.
* Supporting IPv6 URL format for remote authentication (-R option).
* Recognizing ::1 as a loopback address allowing non-TLS authentication
  with --tls=localoptional.
* The ipauthmap file that allows selecting the remote authentication
  host based on the interface the client connected on.

This includes some functional changes:

* In addition to -p/--proxyport, there's a new -6/--ipv6proxyport option
  to specify on IPv6 address. These two options can appear multiple
  times, in any combination, to bind many address/port combinations.

* With the above options, the preferred syntax for binding all available
  addresses is now ":PORT" instead of "0&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-05-21T17:16:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6856">
    <title>Corrupted image files in tmda-cgi</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6856</link>
    <description>&lt;pre&gt;I've found many corrupted .gif files in tmda-cgi, mostly in
tmda-cgi/htdocs/display/ and various places in
tmda-cgi/display/themes/Blue. This *could* be because the files were
checked in with bad svn properties (especially svn:eol-style) which
would cause svn to rewrite the files on checkout (I think), in which
case the originals could still be in the repository. However, as a
test I fixed the properties on the files in tmda-cgi/display/icons and
this did not seem to make any difference for sound.gif, which is still
visibly distorted in those applications which don't simply fail to
open it.

(found on the Sourceforge web site) it appears the 0x0D bytes have all
been changed to 0x0A, so that suggests they were incorrectly processed
as text somewhere along the line, and had their "EOL" markers changed.

I'm concerned that the originals of some of these files may be lost.

The most pressing questions I have right now are:

* Is there a way to make Subversion give me the raw file, as it is in
the repository, wit&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-04-20T02:43:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6852">
    <title>TMDA + Postfix/Procmail + TMDA-CGI</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6852</link>
    <description>&lt;pre&gt;Hi, 

I'm not familiar to mail servers, 
but I have to install TMDA on a 
already working Postfix server.

I read a lot of tutorials, but
 most of them explaining how to 
install TMDA to work with Maildrop. 

I need to make it work with procmail. 
So far I've installed TMDA 1.1.12 ok.  

I was told I need to create a file 
named ~/.procmailrc for each user 's home 
(although I dont't know its content yet... 
gonna find it somewhere...&amp;gt;D ).

Now I'm trying to install tmda-cgi 0.16.4 
but it's not working. 

Does anybody know if this version of tmda-cgi
 need a specific version of python? 

I'm using Python 2.6.

Thanks in advance.

Lívia.


------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.&lt;/pre&gt;</description>
    <dc:creator>Lívia</dc:creator>
    <dc:date>2011-04-13T18:26:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6849">
    <title>Opinions for supported Python versions?</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6849</link>
    <description>&lt;pre&gt;At this point I'm not sure it's exactly clear what Python versions are
supported, and I don't know off the top of my head if there's on
official requirement. I believe my releases have included dependencies
on Python 2.4, and some of my recent commits depend on Python 2.5
features.

Certainly supporting versions up to 2.7.x is desirable (and any future
2.x versions, though I *think* 2.7 is expected to be the last in the
Python 2 line), and supporting 3.x is impractical until some significant
work is put into converting the entire code base.

So the main question is the minimum supported version. Python 2.5 was
released in September of 2006, and is available in Debian's "oldstable"
release (Lenny) from February 2009. Since Debian has a reputation for
old software in its stable releases, something that's available as far
back as it's previous stable release seems more than reasonable.

Python 2.6 seems reasonably widespread at this point, and was released in
October 2008. It's also the default version in the c&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-04-12T18:55:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6846">
    <title>Security fixes for tmda-ofmipd now available</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6846</link>
    <description>&lt;pre&gt;I've pushed two commits out to the Subversion repository as well as my
GitHub fork. On GitHub I've also tagged a new release (tag name
tmda-1.1.12-kg3 or debian-tmda-1.1.12-kg3-1 for the branch that
includes Debian packaging) and uploaded new .deb packages:

https://github.com/KevinGoodsell/tmda-fork

As indicated in the subject line, these changes are to address issues
that I consider security problems for tmda-ofmipd. Two separate issues
are addressed with these changes:

First, tmda-ofmipd allowed the use of SSL version 2, which is an
older, insecure version of the protocol. It also allowed weak 40-bit
and 56-bit ciphers. In all cases these were allowed because that is
the default for the OpenSSL library. One of the changes adds a new
--ciphers option to tmda-ofmipd, which allows the user to control
which ciphersuites are accepted by the server. The default set
excludes weak ciphers and SSL version 2 ciphers (though any user who
really needs to can easily re-enable them).

Second, tmda-ofmipd's error hand&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-04-09T21:57:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6844">
    <title>Latest updates: pythonlib, tmda-cgi</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6844</link>
    <description>&lt;pre&gt;I just pushed a few more changes:

* Remove pythonlib
* Some cleanup and minor fixes for tmda-cgi
* A simple web server for testing tmda-cgi
* A mostly new configure script for tmda-cgi, to support the web server

Most of the actual work here was just to make tmda-cgi testable for
me, without having to install and configure a web server.

One thing I am unable to test is the tmda/contrib/tmda.spec script for
RPM building. This had to be updated for the pythonlib removal, but as
a Debian user I don't have experience building RPMs and I'm not sure
exactly how this is supposed to be used. If anyone can test this and
notify the tmda-workers list of any problems, that would be
appreciated.

Next I plan to do some additional updates to tmda-cgi, mostly to
remove deprecated items.

I'm also keeping a github branch synchronized with the Subversion trunk here:

https://github.com/KevinGoodsell/tmda-fork/tree/svn-trunk

-Kevin

------------------------------------------------------------------------------
Create and p&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-04-02T18:25:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6841">
    <title>Mail rejected for tmda-cvs email address</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6841</link>
    <description>&lt;pre&gt;I'm getting email errors from sourceforge because the email
notifications for checkins are going to an address that appears to no
longer be valid:

   Delay reason: SMTP error from remote mail server after RCPT
TO:&amp;lt;tmda-cvs&amp;lt; at &amp;gt;tmda.net&amp;gt;:
   host a.mx.tmda.net [66.135.48.124]: 450 4.1.1 &amp;lt;tmda-cvs&amp;lt; at &amp;gt;tmda.net&amp;gt;:
   Recipient address rejected: User unknown in local recipient table

For the moment I've removed the hook that sends checkin notifications.
It can of course be restored if the address is fixed.

-Kevin

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
tmda-workers mailing list
tmda-workers&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmda-workers

&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-03-18T17:23:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6839">
    <title>Changes from GitHub branch committed to Subversion</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6839</link>
    <description>&lt;pre&gt;I just finished several commits taken from my GitHub TMDA branch here:

https://github.com/KevinGoodsell/tmda-fork/wiki

This is an almost-complete merge of my changes. The only thing missing
is the removal of the pythonlib directory and the copy of Python's
email library that lives there. There are some tweaks, combining of
commits, and addition of changelog entries, so the history isn't
identical to the GitHub history.

Next I'd like to do some updates to tmda-cgi to remove deprecated
modules (this has already been done in tmda), consider removing
pythonlib (it seems unnecessary and a source of problems), and fix
some incorrect URLs in documentation, help output, etc. After that I
have some work in mind for tmda-ofmipd, mostly based on requests from
users (such as IPv6 support).

The time I have available to work on this is limited, but I'd like to
try to get everything in a good, working state.

-Kevin

------------------------------------------------------------------------------
Colocation vs. Managed H&lt;/pre&gt;</description>
    <dc:creator>Kevin Goodsell</dc:creator>
    <dc:date>2011-03-16T18:29:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6832">
    <title>MS Outlook READ confirmation</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6832</link>
    <description>&lt;pre&gt;------------------------------------------------------------------------------
Download Intel&amp;amp;#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev_______________________________________________
tmda-workers mailing list
tmda-workers&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmda-workers
&lt;/pre&gt;</description>
    <dc:creator>Ricardo Buchalla Auada</dc:creator>
    <dc:date>2010-03-18T21:47:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6828">
    <title>Probable bug in handling message/rfc822</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6828</link>
    <description>&lt;pre&gt;   The _handle_message method in tmda/TMDA/pythonlib/email/generator.py
starts with the following comment:

         # The payload of a message/rfc822 part should be a multipart sequence
         # of length 1.  The zeroth element of the list should be the Message
         # object for the subpart . . .

But I think this is confusing message/* with multipart/digest; I see no
hint in RFC 2046 [1] that message/rfc822 bodies contain any internal
structure (other than whatever may be in the message itself, of course).

   And I have a counterexample:  I forwarded a message to myself using
VM [2], without adding any text in the body, and I got a top-level
Content-Type of "message/rfc822" with no multipart structure [first
attachment].  Passing this message through TMDA fails in the following
way:

    Uncaught Python 2.5.2 Exception (Wed Jan  6 12:33:04 2010):
    -----------------------------------------------------------
    Traceback (most recent call last):
      File "/usr/bin/tmda-filter", line 53, in &amp;lt;modu&lt;/pre&gt;</description>
    <dc:creator>Bob Rogers</dc:creator>
    <dc:date>2010-01-06T20:49:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6827">
    <title>Passive Spam Revocation</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6827</link>
    <description>&lt;pre&gt;Passive Spam Revocation (PSR)

Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam
filter, which can drop good and important messages.

I propose an optional feature for current mail systems. The main idea
is if a message is considered spam, this spam status can be tracked by
the sender (but not sent to him directly, as the From field can be
faked). The message can be re-marked as "not spam" if the sender can
solve a CAPTCHA.

STEP 1: A is going to send B a message. A's mail client generates a
random code and puts it in a custom field in the outgoing message's
header:
    PSR-Code: &amp;lt;random code&amp;gt;
STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
    https://spamstatus.&amp;lt;B's mail domain&amp;gt;/?msgid=&amp;lt;Message-ID&amp;gt;&amp;amp;code=&amp;lt;PSR-Code&amp;gt;
This page displays one of these possible "spam statuses":
    * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
    * MESSAGE CONSIDERED NOT SPAM.
    * PENDING. PLEASE TRY AGAIN LATER.
    * All other responses mean B's mail system &lt;/pre&gt;</description>
    <dc:creator>Yao Ziyuan</dc:creator>
    <dc:date>2009-10-26T04:11:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6825">
    <title>Is deliverquota exit code being ignored?</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6825</link>
    <description>&lt;pre&gt;Hi all!

We are using TMDA with Postfix and configured deliverquota as the final
delivery program:

   DELIVERY = "| /usr/local/bin/deliverquota -w 90 ~/Maildir"

All is well, except when the maildir is full. In this case, it seems TMDA ends
with an exception and the message goes back to the mail queue. The same
happens if we use maildrop instead of deliverquota.

Shouldn't TMDA send back to Postfix the exit status of deliverquota? Or are we
doing something wrong?

Versions of some of our softwares: TMDA/1.1.12 "Macallan" (Python/2.5.2 on
FreeBSD-7.2-RELEASE-p3-i386-32bit-ELF)

Here is a sample of the log files:

Oct 25 17:41:49 XXXXXXX postfix/local[61785]: 7B6863F96D2: to=&amp;lt;XXXXXXX&amp;gt;, 
relay=local, delay=456, delays=456/0/0/0.17, dsn=4.3.0, status=deferred
(temporary failure. Command output: See /XXXXXXX/TMDA_DELIVERY_FAILURE
for traceback )


Uncaught Python 2.5.2 Exception (Sun Oct 25 17:41:49 2009):
-----------------------------------------------------------
Traceback (most recent call last):
  File "/usr&lt;/pre&gt;</description>
    <dc:creator>Ricardo Mendonça Ferreira</dc:creator>
    <dc:date>2009-10-25T21:16:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.mail.spam.tmda.devel/6824">
    <title>Completely replacing 'From:' header...</title>
    <link>http://comments.gmane.org/gmane.mail.spam.tmda.devel/6824</link>
    <description>&lt;pre&gt;
I wanted to completely replace the From: header
so in my outgoing filter file, I added this:

to irl-tmdatest&amp;lt; at &amp;gt;rangat.org tag
   from "Agent Maxwell Smart &amp;lt;max&amp;lt; at &amp;gt;kaos.com&amp;gt;"

But that resulted in 'mangled' From: headers, something like this:
   From: Robert P. Thille &amp;lt;Agent Maxwell Smart &amp;lt;max&amp;lt; at &amp;gt;kaos.com&amp;gt;&amp;gt;

So, I found this section of code:

And removed 'from' from the list of literals exempted from 'custom_headers'

I don't _think_ that breaks anything, as I can still use 'from dated=1w'
and that works, and now my above tag action to change the whole 'From'
header also works.

Can anyone see a reason to not make this change (at least locally, for
my install), or a better way to accomplish the same goal?

BTW, I'm running 1.1.8nb3 (NetBSD pkgsrc, I'm pretty sure the
base-version is 1.1.8)

Thanks,

Robert

&lt;/pre&gt;</description>
    <dc:creator>Robert P. Thille</dc:creator>
    <dc:date>2009-09-15T22:43:07</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.mail.spam.tmda.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.mail.spam.tmda.devel</link>
  </textinput>
</rdf:RDF>
