How to remove X-Confirm-Reading requests from mail headers distributed by Mailman?
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
Hi!
Is there any way to setup mailman to stop distributing X-Confirm-Reading- To requests sent by some list users? One user has unsubscribed from my list just because it was distributed over the list.
Regards ak
![](https://secure.gravatar.com/avatar/e8182135be0245df69df7ddf7f70856a.jpg?s=120&d=mm&r=g)
Is there any way to setup mailman to stop distributing X-Confirm-Reading- To requests sent by some list users?
I would do it inside postfix header_checks filters, with a line like /^X-Confirm-Reading-To: / IGNORE
If you're using some other MTA, or want this setting to be only for Mailman, I don't know.
-- Fil
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
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.
-- 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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/00a4fe9d2106166604cc8cb3b24975c9.jpg?s=120&d=mm&r=g)
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.
From: "Andrzej Kasperowicz" <andyk@spunge.org> To: Brad Knowles <brad.knowles@skynet.be>, mailman-users@python.org, mailman-developers@python.org Date sent: Sat, 03 Apr 2004 01:41:34 +0200 Priority: normal Copies to: Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman?
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.
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 6:57 PM -0800 2004/04/02, Lloyd F. Tennison wrote:
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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
the common MUA that recognizes this header, and are not computer savvy-enough to know how to turn this "feature" off. That would tend
The person who complained about it to me, was able to turn it off, but he didn't want to do so, claiming that he needs it sometimes to inform people writing to him in private that he read their e-mails. He is using The Bat, and he set it that way, that it was poping up a window telling him that someone sent an e-mail with x-confirm-reading, and he should either accept it (send a confirming message) or deny it. 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. Well, I couldn't argue much with that. 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
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.
ak
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 3:01 PM +0200 2004/04/03, Andrzej Kasperowicz wrote:
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.
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.
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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
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.
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?
and re-implement that in Mailman. If you want ecartis, then use it. Otherwise, you're welcome to continue using Mailman.
Now, come on Brad! I've just presented to Mailman community 3 interesting IMHO featueres, which ecartis have, and Mailman haven't got, thus suggesting to implement them in Mailman, because I think Mailman would gain having those features implemented. What's wrong with that? If I requested those 3 features not telling you that I've seen them in ecartis, then all would be fine, you would be happy, right? You seem to be jelous of ecartis. Think positive Brad! Don't be angry at them that they have some good features that Mailman haven't got (and don't be angry at me that I ask for some of those features to be added in Mailman), just do something that Mailman have them instead of being jelous (no offence :)). :P
ak
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 1:23 AM +0200 2004/04/04, Andrzej Kasperowicz wrote:
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.
![](https://secure.gravatar.com/avatar/39160ded94f193ee4c4daeab2e91287f.jpg?s=120&d=mm&r=g)
Brad Knowles schrieb:
But asking someone to re-create a commercial product and then give that away for free, well that's quite a different matter.
If you're referring to ecartis - last time I looked at it, it said:
| Ecartis - Modular Mailing List Manager is Copyright ©1998-2002 by | Rachel Blackman, JT Traub and contributors. | | 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.
-thh
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 10:15 AM +0200 2004/04/04, Thomas Hochstein wrote:
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.
![](https://secure.gravatar.com/avatar/3537f9e88306dd8b4a43793b4d22f5d0.jpg?s=120&d=mm&r=g)
On Sun, 4 Apr 2004, Brad Knowles wrote:
To put it politely, I suggest that the condescending tone of your responses scares potential developers, myself included, away.
Brett
![](https://secure.gravatar.com/avatar/00a4fe9d2106166604cc8cb3b24975c9.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
But there is a lot what you could say to change his mind...
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.
But asking someone to re-create a commercial product and then give that away for free, well that's quite a different matter.
I don't understand the above. From what the freelists say on the page: http://www.freelists.org/about.html "FreeLists runs a completely free service on completely Free software. The Linux operating system, the Apache webserver, and the Ecartis mailing manager are responsible for bringing FreeLists to you daily. Mhonarc and ht://dig work in conjunction to bring you the web-based archives. All of this software is Free software and we italicize that word over and over again to emphasize its importance. See the Free Software Foundation's website for more information." it seems that all the software they use is free.
ak
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/e8182135be0245df69df7ddf7f70856a.jpg?s=120&d=mm&r=g)
Is there any way to setup mailman to stop distributing X-Confirm-Reading- To requests sent by some list users?
I would do it inside postfix header_checks filters, with a line like /^X-Confirm-Reading-To: / IGNORE
If you're using some other MTA, or want this setting to be only for Mailman, I don't know.
-- Fil
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
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.
-- 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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/00a4fe9d2106166604cc8cb3b24975c9.jpg?s=120&d=mm&r=g)
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.
From: "Andrzej Kasperowicz" <andyk@spunge.org> To: Brad Knowles <brad.knowles@skynet.be>, mailman-users@python.org, mailman-developers@python.org Date sent: Sat, 03 Apr 2004 01:41:34 +0200 Priority: normal Copies to: Subject: [Mailman-Users] Re: [Mailman-Developers] How to remove X-Confirm-Reading requests from mail headers distributed by Mailman?
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.
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 6:57 PM -0800 2004/04/02, Lloyd F. Tennison wrote:
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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
the common MUA that recognizes this header, and are not computer savvy-enough to know how to turn this "feature" off. That would tend
The person who complained about it to me, was able to turn it off, but he didn't want to do so, claiming that he needs it sometimes to inform people writing to him in private that he read their e-mails. He is using The Bat, and he set it that way, that it was poping up a window telling him that someone sent an e-mail with x-confirm-reading, and he should either accept it (send a confirming message) or deny it. 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. Well, I couldn't argue much with that. 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
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.
ak
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 3:01 PM +0200 2004/04/03, Andrzej Kasperowicz wrote:
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.
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.
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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
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.
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?
and re-implement that in Mailman. If you want ecartis, then use it. Otherwise, you're welcome to continue using Mailman.
Now, come on Brad! I've just presented to Mailman community 3 interesting IMHO featueres, which ecartis have, and Mailman haven't got, thus suggesting to implement them in Mailman, because I think Mailman would gain having those features implemented. What's wrong with that? If I requested those 3 features not telling you that I've seen them in ecartis, then all would be fine, you would be happy, right? You seem to be jelous of ecartis. Think positive Brad! Don't be angry at them that they have some good features that Mailman haven't got (and don't be angry at me that I ask for some of those features to be added in Mailman), just do something that Mailman have them instead of being jelous (no offence :)). :P
ak
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 1:23 AM +0200 2004/04/04, Andrzej Kasperowicz wrote:
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.
![](https://secure.gravatar.com/avatar/39160ded94f193ee4c4daeab2e91287f.jpg?s=120&d=mm&r=g)
Brad Knowles schrieb:
But asking someone to re-create a commercial product and then give that away for free, well that's quite a different matter.
If you're referring to ecartis - last time I looked at it, it said:
| Ecartis - Modular Mailing List Manager is Copyright ©1998-2002 by | Rachel Blackman, JT Traub and contributors. | | 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.
-thh
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
At 10:15 AM +0200 2004/04/04, Thomas Hochstein wrote:
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.
![](https://secure.gravatar.com/avatar/3537f9e88306dd8b4a43793b4d22f5d0.jpg?s=120&d=mm&r=g)
On Sun, 4 Apr 2004, Brad Knowles wrote:
To put it politely, I suggest that the condescending tone of your responses scares potential developers, myself included, away.
Brett
![](https://secure.gravatar.com/avatar/00a4fe9d2106166604cc8cb3b24975c9.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/3eb41e1cf62b91a152384264caf947fa.jpg?s=120&d=mm&r=g)
But there is a lot what you could say to change his mind...
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.
But asking someone to re-create a commercial product and then give that away for free, well that's quite a different matter.
I don't understand the above. From what the freelists say on the page: http://www.freelists.org/about.html "FreeLists runs a completely free service on completely Free software. The Linux operating system, the Apache webserver, and the Ecartis mailing manager are responsible for bringing FreeLists to you daily. Mhonarc and ht://dig work in conjunction to bring you the web-based archives. All of this software is Free software and we italicize that word over and over again to emphasize its importance. See the Free Software Foundation's website for more information." it seems that all the software they use is free.
ak
![](https://secure.gravatar.com/avatar/a148cdd5c639fe49576e590c26f615ef.jpg?s=120&d=mm&r=g)
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.
participants (6)
-
Andrzej Kasperowicz
-
Brad Knowles
-
Brett Delmage
-
Fil
-
Lloyd F. Tennison
-
Thomas Hochstein