I've had a lot of requests recently for information about Mailman
hosting. As a general rule I don't like to recommend any particular
hosting company. But if you do provide Mailman hosting facilities,
please make sure you've added yourself to the PythonHosting wiki:
http://www.python.org/cgi-bin/moinmoin/PythonHosting
I usually point people here for more information, so please make sure
you're on that list. Now to check the FAQ and see if it points here...
-Barry
On Thu, 27 Nov 2003 10:46:27 -0500
Barry Warsaw <barry(a)python.org> wrote:
> On Thu, 2003-11-27 at 03:47, PieterB wrote:
> For the next version of Mailman, I'd prefer to see something more
> generic if possible.
+1
> That way a site could add SA, SB[1], or some other system. It may be
> too hard to do this since there are no standards here, but even then,
> I'd like to see something pluggable rather than tightly integrated.
First thought:
Discard message on <regex>
Hold message on <regex>
Accept message on <regex>
Where the regex fields are in fact lists of regexes. Given such support
it is fairly simple to define regexes which match SpamAssassin headers
of value X and above/below for the relevant entries, or SpamBayes or
whatever.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
ID 840426
This is different from the 'other' SA handler as it deals with pre-taged
messages. IMHO this is far more likely to be the case in an ISP
enviroment. The general concensious on my MTA's mailing list being that
all mail should be tagged, flagged, and passed on leaving it up to
'something else' to decide what to do with spam (user agents could drop,
or filter it, Mailman qualifies as a UA in this scheme :)
The MailScanner install here might be using non-standard headers, but it
shouldnt be too hard to figgure out what to change.. Thinking about it
now I shold have put the header name and get-the-score RE as options,
but oh well.
Further to my previous message, I've now got it reading config from
mm_cfg.py, verifying the connectivity to the mysql database on the
__init__ call, rather than throwing up(numerous) errors later on,
updated the README to reflect relevant changes, and just generally
cleaned things up a bit. That's RCS revision 1.13.
The only major problem I have is the return types for
{get,set}DeliveryStatus. I can't work out how I'm suppose to return a
tuple of values, and what they should be.
If someone could assist I'd be grateful :-)
K.
Begin forwarded message:
Date: Tue, 4 Nov 2003 15:27:45 +0000
From: Kyrian (List) <kyrian-list(a)ore.org>
To: mailman-developers(a)python.org
Subject: Mysql MemberAdaptor?
Hi All,
I'm presuming this is the appropriate list to post this to...
If anyone cares, I've written a Mysql MemberAdaptor based on the
OldStyleMemberships.py module, which seems to work ok. I've not done
much large scale testing as yet, though.
I've put it up at http://kyrian.ore.org/MailmanMysql/
Although I could use some pointers on the following:
- How to incorporate exception handling in python to trap DB errors, and
stop Mailman choking on them.
- How to incorporate some better configuration (you currently would
have to edit the module file directly to specify the database
parameters)
- How to properly incorporate it into mailman (if nobody minds that ;),
as it currently seems to require modifying MemberAdaptor.py directly
to activate it.
- Whether I've actually done it even half way right?
Either way, if anyone has anything to say about it, please go easy, I
kinda needed this thing, and delved into Python for the first time to do
so.
Oh, and I know the MySQL data structure I'm using is pretty atrocious,
as it was a best-guess, though I can always clean it up later...
I do hope I've not just spent several days reinventing the wheel here,
though... ;*)
Yours,
Kev.
--
Kev Green, aka Kyrian. "Be excellent to each other" -- Bill & Ted.
Email: kyrian@ore.org Web: http://kyrian.ore.org/
ISP/Perl/PHP/Linux/Security Contractor, via http://www.orenet.co.uk/--
Kev Green, aka Kyrian. "Be excellent to each other" -- Bill & Ted.
Email: kyrian@ore.org Web: http://kyrian.ore.org/
ISP/Perl/PHP/Linux/Security Contractor, via http://www.orenet.co.uk/
I thought everything was going great(after I removed all the queue
files, after having fixed mm_cfg.py and permissions), until things
just ground to a halt again. 400+ files in out, mail's extremely
slow- its taking well over 10 minutes from the time postfix calls
bin/mailman to when something's logged in logs/post. The qrunner
processes are running, and taking a few percent of CPU time, but
apparently doing nothing, or next to it.
The only error we're getting is every 15 minutes:
Nov 20 22:02:55 2003 (18412) No such list "[list":
...with one space after the :
I've been unsuccessful in tracking down where that could possibly be
coming from....
Brett
--
----
"They that give up essential liberty to obtain temporary
safety deserve neither liberty nor safety." - Ben Franklin
http://www.users.cloud9.net/~brett/
I have a couple of questions.
First: If I was to submit a (compleate) set of patches that allow at
least some per list configuration for SpamAssassin integration, would
they be accepted?
As a first attempt I would be just concerned with setting the score, and
actions to take. Likely it would be hard coded at 3 possible actions
discard, hold for moderation, or pass through, as I cant think that
anyone would want to bounce spam.
And on doing the actual work: What version should I be working with? CVS
or the 2.1 branch? What would be the closest thing that I could clone as
a starting point? Topics seems like a possible thing to examin. Also, Im
not a Python hacker, though Ive used a lot of different languages. Are
there any paticular gotcha's of either Python or Mailman that I should
be aware of?
Thanks.
On Sat, 29 Nov 2003 19:43:48 +0000
Richard Barrett <r.barrett(a)openinfo.co.uk> wrote:
> On 29 Nov 2003, at 14:55, J C Lawrence wrote:
>> On Sat, 29 Nov 2003 14:40:48 +0000 Richard Barrett
>> <r.barrett(a)openinfo.co.uk> wrote:
> ... I know that Mailman developers are not interested in my input
> about major new releases.
I have no reason to believe that.
>>> However, offering an immediate fix for an arguably valid criticism
>>> of the current stable release that would not have a major
>>> destabilizing effect on that stable release seems worthwhile to me.
>> Fair dinkum, and I've not argued otherwise.
> It was square bunkum when I lived in oz.
I heard and used both in my time there (Qld and NSW, 70's and mid 80's).
> But by pressing on the v3 issues that is precisely what you are
> doing.
No. I've made no comment or assertion regarding v2 impacts. You appear
to consider yourself attacked. You haven't been attacked. Rather I've
stated an undocumented impact of your patch which is significant to
certain deployments.
> You really are too clever for me.
<sigh>
EOT.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On Sat, 29 Nov 2003 14:40:48 +0000
Richard Barrett <r.barrett(a)openinfo.co.uk> wrote:
> On 29 Nov 2003, at 13:32, J C Lawrence wrote:
>> On Sat, 29 Nov 2003 07:12:45 +0000 Richard Barrett
>> <r.barrett(a)openinfo.co.uk> wrote:
>>> On 29 Nov 2003, at 00:48, J C Lawrence wrote:
>> For me, and (possibly) for Mailman v3, critical. I use Message IDs
>> as a primary key for my list archives, indexing and several other
>> bits. Changing them, at any point, breaks that.
> I confess I was not gazing that far into the future and, not being a
> Mailman developer, have no influence or knowledge of the architecture
> of Mailman v3.
This area was discussed on this list extensively a few weeks ago. I
suggest reading the archives.
> However, offering an immediate fix for an arguably valid criticism of
> the current stable release that would not have a major destabilizing
> effect on that stable release seems worthwhile to me.
Fair dinkum, and I've not argued otherwise.
> It seems from what you say that your archiving and indexing solution
> is not standard Mailman internal pipermail archiving so the poor fit
> of the solution offered with your system is unsurprising.
The archiving system I use is also what I've advocated for Mailman v3,
with some level of buy-in.
> Bear in mind that the patch only affects the data delivered in
> response to HTTP requests.
Right, one of the levels I use Message IDs is the user-level, in HTML,
in archives, in URLs, and in raw messages. Users regularly quote
Message IDs in their messages as text strings ala:
Have a look at message
059F1F1D-227A-11D8-89F4-000A957C9A50(a)openinfo.co.uk as it goes into
this area further and explains several of the bits you are asking
about.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
On Sat, 29 Nov 2003 07:12:45 +0000
Richard Barrett <r.barrett(a)openinfo.co.uk> wrote:
> On 29 Nov 2003, at 00:48, J C Lawrence wrote:
>>> [ 850805 ] Aggressive anti email address harvesting measure
>> This patch appears to fail to distinguish between email addresses and
>> Message IDs.
>>
> And ...
> In the interest of simplicity it doesn't attempt to. But how important
> a matter is that?
For me, and (possibly) for Mailman v3, critical. I use Message IDs as a
primary key for my list archives, indexing and several other bits.
Changing them, at any point, breaks that.
> This is a rendering filter which leaves the underlying archived
> material intact in the archive and handles both the archive's html
> pages and the downloadable text version of the period archives. It has
> no impact on any processing undertaken at the server end on the
> archive material, which might depend on the Message IDs, thread
> identification by the archiver for instance.
For me Message IDs are both a systems-level and user-level concern. Raw
Message IDs as well as URLs containing message IDs are quoted by users
as ways to reference specific messages in the archives, additionally
Message IDs are also quoted in URLs which appear in every message, which
point to that message in the archives, etc.
> My mail reader will still identify threads in filtered, downloaded
> text archives when treated as an .mbox, although I grant that the
> chances of Message ID collisions must be increased by the filtering.
I and several others use an NNTP-based backing store (which of course
uses Message ID as a primary key as per NNTP specs) for my archives and
then render directly out of that (see prior traffic on this list wrt
MeoWWW etc). The access key for retrieving a message is its Message ID.
Touch the Message ID and the whole system breaks.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(a)kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.