Hello,
Currently I'm creating an unofficial site of GNU Mailman. It's not
done yet, but the goal is to make the current official site more
accessible and usable. The content is almost the same.
The unofficial site (since Google Page Creator doesn't support
folders, images are not shown and linked docs are not available):
http://gnu.mailman.googlepages.com/index.html
You can download the source tarball here (with linked docs):
Source Tarball (size: 1.1mb)
http://gnu.mailman.googlepages.com/Mailman-Site-Redesign.tar.gz
This site tries to solve the problems that I listed in the following document:
What's wrong with the current Mailman official site?
http://gnu.mailman.googlepages.com/wrong.txt
I'd love to have your feedback. Also, I listed several questions in
the document above, so I'd appreciate if any of you could answer or
comment on them (Some questions are not about the official site per
se).
Best,
- Satoshi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I am happy to announce the next beta release of Mailman 2.1.10.
This is a security and bug fix release and it is highly recommended
that all sites upgrade to this version. Mailman 2.1.10 also adds support
for three new language translations, Galician, Hebrew and Slovak and a
few new features.
Mailman is free software for managing email mailing lists and e-
newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.
For more information, including download links, please see:
http://www.list.orghttp://mailman.sf.nethttp://www.gnu.org/software/mailman
Special thanks are due to Barry Warsaw and Tokio Kikuchi for much coding
and support, Moritz Naumann for help with security issues and Jim Tittsler
for a significant patch.
Here's a list of the major changes.
Security
- - The 2.1.9 fixes for CVE-2006-3636 were not complete. In particular,
some potential cross-site scripting attacks were not detected in
editing templates and updating the list's info attribute via the web
admin interface. This has been assigned CVE-2008-0564 and has been
fixed. Thanks again to Moritz Naumann for assistance with this.
New Features
- - Changed cmd_who.py to list all members if authorization is with the
list's admin or moderator password and to accept the password if the
roster is public. Also changed the web roster to show hidden members
when authorization is by site or list's admin or moderator password
(1587651).
- - Added the ability to put a list name in accept_these_nonmembers
to accept posts from members of that list (1220144).
- - Added a new 'sibling list' feature to exclude members of another list
from receiving a post from this list if the other list is in the To: or
Cc: of the post or to include members of the other list if that list is
not in the To: or Cc: of the post (Patch ID 1347962).
- - Added the admin_member_chunksize attribute to the admin General Options
interface (Bug 1072002, Partial RFE 782436).
Internationalization
- - Added the Hebrew translation from Dov Zamir. This includes addition of
a direction ('ltr', 'rtl') to the LC_DESCRIPTIONS table. The
add_language() function defaults direction to 'ltr' to not break
existing mm_cfg.py files.
- - Added the Slovak translation from Martin Matuska.
- - Added the Galician translation from Frco. Javier Rial Rodríguez.
Changes since 2.1.10b3 include the Galician translation and updates to
the French translation (Vietnamese and Danish translations were updated
in 2.1.10b3). Other changes since 2.1.10b3 include:
- - In 2.1.9, queue runner processing was made
~ more robust by making backups of queue entries when they were dequeued
~ so they could be recovered in the event of a system failure. This
~ opened the possibility that if a message itself caused a runner to
~ crash, a loop could result that would endlessly reprocess the message.
~ This has now been fixed by adding a dequeue count to the entry and
~ moving the entry aside and logging the fact after the third dequeue of
~ the same entry.
- - Fixed the command line scripts add_members, sync_members and
~ clone_member to properly handle banned addresses (1904737).
- - Fixed bin/newlist to add the list's preferred language to the list's
~ available_languages if it is other than the server's default language
~ (1906368).
- - Changed the first URL in the RFC 2369 List-Unsubscribe: header to go
~ to the options login page instead of the listinfo page.
- - Changed the options login page to not issue the "No address given"
~ error when coming from the List-Unsubscribe and other direct links.
~ Also changed to remember the user's language selection when
~ redisplaying the page following an error.
/Mark Sapiro
- --
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFH2eJuVVuXXpU7hpMRAihOAJ4zIREWCWCQt7YDDHp3frDHjzwkCQCfdh7J
W3UKWsTTfStBE4z64oqa36c=
=ZedT
-----END PGP SIGNATURE-----
Hi. There's a fairly simple problem here that needs to be
addressed. And it's mostly a documentation/install problem. I'm
hoping we can get this resolved before the next release.
PROBLEM: Mailman comes out of the box ready to backscatter spam people.
Yes, it's easy enough to fix. But because it comes stock this way,
and is documented to install this way, most people install it to do
this. Those of us who work in abuse departments are tired of hearing
"well that's how Mailman works". We also object to having to teach
people how to fix their mailman installations because it's not
documented in the current manual.
This is *exactly* like Sendmail 14 years ago. We didn't accept it
then, and Sendmail fixed the problem.
RESOLUTION: Mailman default installation should not backscatter in a
default configuration.
1. Don't create backscatter aliases for subscribe/unsubscribe/etc by
default. Nearly everyone uses web based signup.
2. Discard or hold messages from non-subscribers by default.
I would think that it would be perfectly reasonable to have
documentation on how to enable the 1980s-style -request / -subscribe
etc aliases. However this documentation should have a note that this
is against the AUP of nearly every network provider, and enabling it
will likely cause them to get listed in various blacklists as a
backscatter source.
FYI: I know that this goes against the instincts of many old-time
mailing list advocates here. But after dealing with a 10k/hour
backscatter DoS my tolerance for this problem is understandably
limited. Yes, it was a sweet day back in the 1980s. I was running a
mailing list server and several UUCP gateways at the time, so I
remember them well. But those days are past, and we need to deal
with the reality of today.
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I like to participate in Google Summer of Code this year. One possible
Project for me is to implement some Spam Defense in Mailman. I think
development for Mailman should be possible through Python Software
Foundation. Am I right with this?
I administrate a Mailman installation with about 100 lists and thousands
of users and I moderate most of the Lists. I think the biggest Problem
of Mailman is the lack in spam defense. Discard messages from nonmembers
is no option on most lists.
Some time ago I began some modification of Mailman. But I never finished
it. The first action is to integrate support for SpamAssassin in
Mailman. Therefor I wrote a python class spamc which connects to spamd.
This gives the possibility to scan all incoming Mail.
Further ideas for spam defense are:
- - Add the possibility to scan all messages form nonmembers half an
hour later again before mark them as hold. This is because most of the
mails which are not recognized as spam are to new. The servers are not
in any blacklist at time of incoming.
- - Train the bayes filter from Mailman. Forward all accepted Messages
to SpamAssassin to learn them as ham. The autolearn feature of SA
doesn't work for me. It learns to much false negatives.
This are my ideas so far. Is this welcome in Mailman and is it enough
for an GSoC Project? Where would it be best? 2.1.11? 2.2.0? 3.0.0?
Best Wishes
Timo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH67yiakDbqHKnrh8RAhxoAKDYWguLeFxuSAy18sSCXdwWONmdiwCg2YwO
W60FvGTr79tAAXZEndPSFSk=
=iutB
-----END PGP SIGNATURE-----
I've been incredibly tolerant of being abused on this issue for 3 weeks
now, but the now-constant flood of people coming forward to say that I'm
not respecting the mailman community is too funny. It breaks the bounds
of reality.
*I* did one thing. I pointed out an issue that *EVERYONE* knows about,
even the non-technical news media. I asked that something be done soon.
I wrote my post clearly and politely.
http://mail.python.org/pipermail/mailman-developers/2008-March/019804.html
Did I receive a respectful response addressing these issues from anyone
who writes code for the project?
Yes: Mark Sapiro wrote me a respectful reply on March 5.
http://mail.python.org/pipermail/mailman-developers/2008-March/019807.html
But that reply only negated my suggestions, with no solutions proposed.
I attempted to respond to the insults and derision I received in most of
the replies with honest, straightforward answers. Even when the
questions were hopelessly supercilious and rude.
At this time there has been more effort spent writing me back saying
that I'm not respecting the community than it would have taken to write
patches to fix the problem. I've certainly wasted more time here than I
did writing my patches and testing them in the first place.
I respected the community by coming here and trying to address the
issue, rather than simply blacklisting Mailman sites. I respected the
community by replying to everyone who replied to me, rather than
ignoring the posts filled with derision or technical nonsense. Perhaps
that was a mistake.
I had a nice dinner with a number of people last night on this topic,
and not a single person (all of whom witnessed this thread) felt that
trying to address this issue here was producing any results.
So I am done. Keep your derision to yourself, and keep wasting time
telling people how they should respect you rather than solve the problem.
I am right now updating our AUP documentation to mention that Mailman is
explicitly banned unless the person provides documentation of the
configuration/patches they have applied to prevent backscatter. I am
notifying the known mailman sites within our network. We are done with
this issue.
--
Jo Rhett
Net Consonance ... net philanthropy, open source and other randomness
First there was Majordomo...
Once upon a time, Majordomo version one was the leader in its field. So
good was it, that ambitious plans were laid for a succeeding generation:
version two. And at that point it went off the rails and ended up in a
ditch. 'Domo V1 got stuck, because the development went into 'Domo V2.
But V2 got stuck because it never got released and never got used. And so
the once glorious Majordomo sadly faded into the night-time of obscurity.
Move forward a few years...
In another place, at a later time, Mailman v2.1 became the leader in its
field. So good was it, that ambitious plans were laid, not just for one,
but for two, succeeding generations: v2.2 and v3. And at that point...
... well what has happened?
Nearly two years ago, the July 5 2006 "What I did on my summer vacation"
email and wiki entry (http://wiki.list.org/x/vg) outlined a massive amount
of potential progress. But, in reality, what actually have we (the subset
of real-world end-users who could assist development) been able to do?
Has Mailman lost its way? Could it be drifting to the same obscurity and
oblivion as the entire majordomo project?
Could I suggest that serious consideration be given to:
1. Freeze 2.1 now. No new features. The only exception would be security
bug-fixes. Nothing else.
2. Freeze "new idea" development now. Concentrate solely on bugfixing the
already implemented ideas.
3. Decide whether 2.2 or 3.0 is the way of the near future. The reality
is that neither of these has delivered anything to the real-world end-user
during two or more years. Choose only one. Freeze the other for the time
being, until the "chosen one" has been properly post-beta released.
4. Whichever of the above is chosen, aim to start delivering betas fast.
Get something out there that you (the main developers) and we (some
real-world end-users who can help bug-hunt) can get to work on, knowing
that our work will be productive in a foreseeable timescale. Set the
goal. Drive towards it, ignoring distractions.
5. For a few months, change the mindset away from development (yes, I know
we coders love it) and towards a firm, decisively-directed "release
management" (to use ITIL-speak).
Mailman used to be a leading product. But it is slipping behind.
We, the end-users, need some of that new code that's being lying dormant,
and (to an end-user) unuseable, during the last two years or so.
Many of us, the enthusiastic real-world end-users, cannot realistically
commit to developing something for which there is no clear strategy.
Give us a strategy, a roadmap with real, near-future dates on it, then we
can at least make local business cases to our local managements for our
taking part in beta trials.
Let's get some new code out now as beta. There may be a sizeable "TODO";
there may be a sizeable "Known Problems". But let's start releasing betas
soon, and concentrate all our limited efforts on that one common task.
Otherwise, are we not in danger of following Majordomo into oblivion?
(Oh, and #1 on my own list is proper "virtual domains": the Jul/2005 paper
mentioned that the code substantially existed. But sadly it's never come
anywhere near a release schedule. If we have a realistic beta-release
schedule, then I can locally justify actively investing in bug-hunting.)
Sorry if that sounds harsh. It is meant to be constructive. (Honest!)
Best wishes.
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
On Sat, Mar 29, 2008 at 01:12:59PM -0500, Robby Griffin wrote:
>> How/where do I stop that?
>
> How is that backscatter? Looks like plain old spam to me (addressed
> to a -owner address, which forwarded to postmaster
But it shouldn't go to postmaster!
/usr/local/mailman/bin/list_owners cc-co
shows me three addresses, all of which are @gmail.com addresses.
> , which forwarded to you),
postmaster does forward to me, yes.
> and your (three!) SpamAssassins
two. One on malecky (the list machine), and one on garp. The third
machine doesn't come into play here.
> let it through. Though one
> of them did score it high enough to be marked as spam, you don't
> seem to have anything between the world and your inbox that actually
> blocks spam...
Not true. Mail to lists (but apparently not owners) now gets discarded
if it has been tagged as spam.
Furthermore, I have procmail rules in place in two places that drop
mail above a certain threshold and quarantine a middle batch.
> If it helps, I have one setup where I have to discard high-scoring
> spam with procmail on its way into my inbox, and another where I
> modified SA to add a user-configurable threshold for tagging
> "extreme" spam so I could discard it within the MTA.
I don't discard anything at the MTA, but otherwise you've got close to
what I've got. What I'm missing here is the step where the mail went
from going to one of the three list admins (again, all at gmail) to
going to me. Where was the forgery? How did mailman (or was it
postfix?) get duped?
Cheers,
--
Cristóbal Palmer
ibiblio.org systems administrator
Jo Rhett wrote:
>Mark Sapiro wrote:
>> Are you aware that not once in the "before next release:" thread is
>> there any mention that you have patches? Perhaps this has been
>> mentioned before, and I missed it, but I would be interested in seeing
>> them.
>
>I'm not on the mailing list any more. But not only did I say this
>multiple times, but I said this directly in a reply to you:
>
>http://mail.python.org/pipermail/mailman-developers/2008-March/019809.html
What you said in that reply was "I disabled all the backscatter aliases
4 years ago, and haven't heard a single complaint."
You also acknowledged in a subsequent post that "obviously you also
have to patch the headers added to list e-mail to not reference these
names"
This is to me at least, not the same thing as saying you have actual
patches. Close perhaps, but not the same.
>The patches I did were brute-force patches for 2.1.4 or maybe even
>earlier. Any competent programmer could do the same patches in about 15
>minutes.
Maybe so, and maybe even I could, but even a checklist such as the
following, presumably tested, list is of interest.
>* Create only a single alias per list (remove 11-12 lines from the output)
>
>* Change the default to D_DISCARD in two places
>
>* Remove the option to reject message (leave accept/discard) in moderation
>
>* Change the headers to give only http addresses for subscribe/unsubscribe.
>
>I kid you not, it's less text than this message. It's also very
>brute-force and I can understand why people would want something
>supported by the Mailman developers.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
A frequent request on mailing lists without a subject prefix is to add one.
This often leads to long debate threads about the utility of the prefix.
There seems to be two different styles of processing mail that leads to
this conflict. One style (which I use) is to filter mail into many folders,
one per list. No tag is needed in this case. The other style is to dump all
mail into one or a small number of folders, and in this style one needs to
tag to know which list a message belongs to.
This has been captured in this feature request:
<https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1104433&group_…>
There seems to be limited code for customizing messages per-user, but this
setting may want to be treated as some kind of user "class" setting so that
messages can still be batched for the no-prefix class and the add-prefix
class. Perhaps this could be implemented as two distinct queues, similar to
the way digests are treated as a distinct queue.
Hi all,
i am using mailman 2.1.9. I am making some customizations, and i have
a questions about MIME Content-Type.
(I have crawled through the archives...)
If I add a message header (msg_header and msg_footer) mailman sets the
> Content-Type: text/plain; charset="us-ascii"
My Question is, if anyone can please point me to the line of code,
where this is added to a message. I already looked in Decorate.py but
my alterations (e.g. comment out the header addition) did not make any
difference. So the place where i looked might not be correct.
I want to see how these are constructed and maybe alter to fit my
customization.
Any urgent help would be greatly appreciated.
Thanks so far,
L.R.