How to remove X-Confirm-Reading requests from mail headers distributed by Mailman?
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
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
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.
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
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?
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
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
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 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.
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.
At least making this an option would make quite a few people happy, I imagine, although a more configurable strip-these-headers/keep-these-headers might be better.
At 2:24 AM -0500 2004/04/03, Terri Oda wrote:
At least making this an option would make quite a few people happy, I imagine, although a more configurable strip-these-headers/ keep-these-headers might be better.
Okay, add a "strip-these-headers/keep-these-headers" option, but by default select "keep-these-headers", and pre-fill in the minimum.
How's that? ;-)-- 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.
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
At 3:01 PM +0200 2004/04/03, Andrzej Kasperowicz wrote:
He claimed thatlist-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 shouldbe 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.
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.
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
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.
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.
But there is a lot what you could say to change his mind...
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.
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
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.
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.
I don't agree. Those features are needed, which users want. It's not that important what inspired them.
ak
participants (5)
-
Andrzej Kasperowicz -
Brad Knowles -
Fil -
Lloyd F. Tennison -
Terri Oda