At 6:53 PM -0600 2004/03/21, Andrzej Kasperowicz wrote:

...

Is there any way to setup mailman to stop distributing X-Confirm-Reading- To requests sent by some list users?

Depending on your MTA, you could configure it to remove various types of headers on incoming messages. However, I'm not aware of any way to do this within Mailman.

Well, that's too bad. I've already given an example that in another mailing list program it is possible to do it: http://mail.python.org/pipermail/mailman-developers/2004-March/016713.html

ak

At 6:57 PM -0800 2004/04/02, Lloyd F. Tennison wrote:

What makes you think it is Mailman? It does not exist on any of my lists, nor does it exist on the lists I receive from others - including this list. (View this source.) Check you MTA. Maybe that is what is doing it. If Mailman is doing it it is somewhere not mentioned in the documentation and does not do it in all setups.

The problem that the OP is complaining about is that some other 

member of the list posted a message containing that header, and Mailman did not strip it out. As a result, this header was passed unchanged to the recipients of the list, which could expose the privacy of the users who received the message but who are not publicly advertised as being members of the list (you can control whether or not your subscription is publicly visible).

If the recipient MUA supported this header, then the original 

poster to the list could get responses back from a wide variety of people, with potentially damaging consequences.

Imagine if the list were an online rape support group, and the 

person posting was a serial rapist, perhaps posing as someone else. They could easily get a list of potentially vulnerable targets which they could then go after, at least of the people who would be running the common MUA that recognizes this header, and are not computer savvy-enough to know how to turn this "feature" off. That would tend to make them even better potential targets, and those are the only ones a potential serial rapist would be likely to be interested in anyway.

It was probably just a spammer going out of their way to gather 

more mailing addresses for the mill, but I think you must concede the potential security weakness here.

In this case, the weakness is not the fault of Mailman.  The 

weakness is the fault of the damn bloody stupid MUA and the criminally incompetent company that wrote it.

However, since this is something that Mailman could potentially 

have protected against, people will expect that Mailman *must* do so, because we all know damn good and well that the unnamed company will never do anything useful when it comes to computer security.

Myself, I can see this becoming a slippery slope, and I'm not 

sure we'd want to go down that route. On the other hand, I can understand why some mailing list admins might insist on this feature.

I'm beginning to think that Mailman should strip all incoming 

headers down to the bare minimum (leave "From:", "Subject:", "Cc:", "Received:", and that's about it), at least by default.

-- Brad Knowles, brad.knowles@skynet.be

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.

SAGE member since 1995. See http://www.sage.org/ for more info.

At 3:01 PM +0200 2004/04/03, Andrzej Kasperowicz wrote:

                                                       He claimed that

list-owners should configure their mailing list programs to remove that kind of headers, that it should be within their basic tasks to do when configuring a list.

I disagree.  I've been running mailing lists for more than ten 

years. This is not a basic task for any mailing list administrator. This is an advanced issue that very few mailing list administrators (should) need to have to deal with. This is part of why very few mailing lists have the built-in ability to strip arbitrary headers.

                  Well, I couldn't argue much with that.

I can.

                                                         There should

be indeed such a feature in Mailman like it is in ecartis: a form where could be set colon separated headers to be removed from outgoing messages: http://znik.wbc.lublin.pl/~ak/rozne/ecartis/freelists_config.gif

We are not going to take every single bloody feature of ecartis 

and re-implement that in Mailman. If you want ecartis, then use it. Otherwise, you're welcome to continue using Mailman.

Regerding MTA. I'm not the admin of the server, and I have no acccess to it. Besides, I don't think it would be a good thing to do it on MTA level (other people could complain...), it should be possible to do within Mailman by list-owners.

Indeed, many MTAs don't have this ability, either.  This just 

isn't a standard feature that you will find in mail or mailing list systems.

-- Brad Knowles, brad.knowles@skynet.be

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.

SAGE member since 1995. See http://www.sage.org/ for more info.

At 1:23 AM +0200 2004/04/04, Andrzej Kasperowicz wrote:

I'd be glad if you could explain it to him, as he apparently was offended, because I didn't do it, and he's not a newbe in internet, I've seen him on-line for about 9-10 years.

As I told you in private e-mail, I'm not interested in whatever 

he might have to say. I've been in this business long enough to know what the capabilities are of the various types of programs, and there's nothing he could possibly say that could change my mind.

These are facts we're dealing with, and regardless of whatever 

his personal opinions are as to what he feels should be done to protect him from his own stupidity, he's not going to change the facts.

...

We are not going to take every single bloody feature of ecartis

Of course not, but what is wrong in taking every good, useful feature?

We can take input from many sources, when it comes to ideas to 

incorporate into Mailman. I'm sure that Barry would be happy to accept any useful input you may have. However, keep in mind that Barry can always decide not to implement a particular recommended feature, and even those features that he does decide to implement will have to be prioritized.

Moreover, the development effort that is available is extremely 

limited -- there are a whole host of compromises that have to be continually made, and no one ever gets everything they want, and most people probably don't even get many of the things they want.

But asking someone to re-create a commercial product and then 

give that away for free, well that's quite a different matter.

-- Brad Knowles, brad.knowles@skynet.be

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.

SAGE member since 1995. See http://www.sage.org/ for more info.

At 10:15 AM +0200 2004/04/04, Thomas Hochstein wrote:

| This program is free software; you can redistribute it and/or modify | it under the terms of the GNU General Public License as published by | the Free Software Foundation; either version 2 of the License, or (at | your option) any later version.

Interesting.  At ecartis.org, I find the following:

| Official web site for the Ecartis (formerly Listar) Modular | Listserver/Mailing List Manager | | Welcome to the official homepage for the Ecartis Listserver / Mailing | List Manager. Ecartis is a open-source (GNU License) software package | that administers mailing lists (similar to Majordomo and Listserv). | Take a look at Ecartis' feature list , and see the advantages it has | over other similar Listserver packages. (anti-spam hooks, ability to | strip down MIME messages and remove their attachments, virtual hosts, | just to name a few). Go to the download page to give Ecartis a try!

So, I stand corrected.


That said, ecartis (formerly Listar) appears to have a much 

larger development team than Mailman, and has certainly been around a lot longer (I remember Listar being a pretty full-featured MLM back in the late 90s).

Give Mailman the same kind of development resources, and maybe we 

can reasonably hope to take over all their best features, at some point in the hopefully not-too-distant future.

Until then, Mailman has had a different development focus than 

ecartis, and unless something fairly radical changes, it will probably always have a different feature set that does not completely overlap. You will need to decide which features are most important to you, and then make your choice of MLM based on that decision.

-- Brad Knowles, brad.knowles@skynet.be

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.

SAGE member since 1995. See http://www.sage.org/ for more info.

I know this might be simplistic, and I cannot get it to work, but the Defaults.py say the following:

# These variables controls how headers must be cleansed in order to be # accepted by your NNTP server. Some servers like INN reject messages # containing prohibited headers, or duplicate headers. The NNTP server may # reject the message for other reasons, but there's little that can be # programmatically done about that. See Mailman/Queue/NewsRunner.py # # First, these headers (case ignored) are removed from the original message. NNTP_REMOVE_HEADERS = ['nntp-posting-host', 'nntp-posting-date', 'x- trace', 'x-complaints-to', 'xref', 'date-received', 'posted', 'posting-version', 'relay-version', 'received']

# Next, these headers are left alone, unless there are duplicates in the # original message. Any second and subsequent headers are rewritten to the # second named header (case preserved). NNTP_REWRITE_DUPLICATE_HEADERS = [ ('to', 'X-Original-To'), ('cc', 'X-Original-Cc'), ('content-transfer-encoding', 'X-Original-Content-Transfer-Encoding'), ('mime-version', 'X-MIME-Version'), ]

I was trying to use it to remove X-Mailer and X-Url codes, but as I read it this should also remove the original received header - which would be great for announce only lists. Since my IP is in the header my attacks on my personal machine get out of hand by pop-up spammers.

Thanks.

Lloyd F. Tennison lloyd_tennison@whoever.com

No trees were harmed in the transmission of this message. However, a rather large number of electrons were temporarily inconvenienced.

At 2:41 PM +0200 2004/04/04, Andrzej Kasperowicz wrote:

I know, but I shouldn't be condemned for recommending such features. And it seems that I was just for daring to compare it to ecarits.

As I said, this is a slippery slope.  Once you start down the 

path of "But program XYZZY does this, why can't you?!?", it becomes very difficult to get back to the real issue of what features truly are needed, for what reason, and what size of community would best be served by focusing on what work.

-- Brad Knowles, brad.knowles@skynet.be

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.

SAGE member since 1995. See http://www.sage.org/ for more info.