Automated Subscription Bots Inundating List Owners With Subscription Requests
For the past couple days my Mailman server has been hammered with automated subscription requests. I've always seen a few here and there but nothing like this. Thousands of them, exploiting the web interface and replying to confirmation email messages. Many of our lists were open subscription and so some got through. Not a lot though. What's most annoying is that list owners are being inundated with confirmation request messages, and you cannot delete them all at once on the "Tend to pending moderator requests" screen. You have to select "Discard" for each of them individually. I don't know if this has been changed yet. I am running 2.1.9 because that is the latest version available from Redhat as a package. I had to block access to the web interface from off site at our router to stop the deluge of messages. I have seen this starting to occur at some other Mailman sites as well. Anyone else seeing this or have any ideas about how best to handle this? I have it under control for now but it is changing the way we use our lists.
-- Gary Kalbfleisch -- Director of Technology Support Services -- Shoreline Community College -- (206) 546-5813 -- (206) 546-6943 Fax
Kalbfleisch, Gary writes:
inundated with confirmation request messages, and you cannot delete them all at once on the "Tend to pending moderator requests" screen. You have to select "Discard" for each of them individually. I don't know if this has been changed yet.
As far as I can see, these are batchable (you only need to click "Submit" once -- version 2.1.15, but I doubt this has changed in many years).
Is your issue that the moderator has to tick each box? I really don't think that should change; otherwise you would lose valid subscription requests when being attacked in this way.
Is the issue that lists get so many requests that it overflows the screen, and you can only do (say) 20 at once?
I had to block access to the web interface from off site at our router to stop the deluge of messages.
I think this is the best way to handle it.
There really ought to be a way for a host to request that a service be firewalled programmatically, although it would have to be designed *very* carefully.
I have seen this starting to occur at some other Mailman sites as well. Anyone else seeing this or have any ideas about how best to handle this? I have it under control for now but it is changing the way we use our lists.
Sadly, I don't see how that can be avoided. The problem is the SMTP and HTTP protocols themselves, which have no easily used provision for authentication or authorization of clients. (How many students do you know who walk around with a personal X.509 certificate?)
If you have suggestions for the admin interface, that would be very helpful. Even if you don't have a lot of confidence in them, this is a hard problem that requires wild ideas.
Hi Stephen,
Thank you for your reply. My responses are below
-----Original Message----- From: Stephen J. Turnbull [mailto:stephen@xemacs.org] Sent: Friday, October 19, 2012 9:20 PM To: Kalbfleisch, Gary Cc: mailman-users@python.org Subject: [Mailman-Users] Automated Subscription Bots Inundating List Owners With Subscription Requests
Kalbfleisch, Gary originally writes:
inundated with confirmation request messages, and you cannot delete them all at once on the "Tend to pending moderator requests" screen. You have to select "Discard" for each of them individually. I don't know if this has been changed yet.
Stephen J. Turnbull writes:
As far as I can see, these are batchable (you only need to click "Submit" once -- version 2.1.15, but I doubt this has changed in many years).
Is your issue that the moderator has to tick each box? I really don't think that should change; otherwise you would lose valid subscription requests when being attacked in this way.
Is the issue that lists get so many requests that it overflows the screen, and you can only do (say) 20 at once?
Kalbfleisch, Gary responds:
Messages are batchable, but administrative tasks are not. As you noted you must tick each box, and yes I'm talking pages and pages of bogus subscription requests. Quite tedious. I think these too should be batchable but perhaps separately. What I would like to be able to do is to change all administrative messages to discard (or whatever) with one click, then go back and change the legitimate subscription requests back to accept.
I had to block access to the web interface from off site at our router to stop the deluge of messages.
I think this is the best way to handle it.
There really ought to be a way for a host to request that a service be firewalled programmatically, although it would have to be designed *very* carefully.
After analyzing the httpd logs I have identified three primary sources of the bogus subscription requests, the most predominant being associated with http://mailbait.info. If you list admins out there are not familiar with mailbait.info you should check it out. It is a service (I use that term loosely here) for filling up your inbox. People submit hosts that send out email messages via web forms which are exploited for this purpose. If you run it (and you can do this without filling in the email address field so you can see how it works) you will see that it skips from one Mailman site to another submitting bogus subscription requests. As per the Mailbait FAQ, "MailBait does not condone using other people's email address with this service.", however they make no efforts to prevent it.
You cannot filter on IP addresses because the source address is that of the person that runs it, not Mailbait itself. I created an iptables filter that looks for the string "mailbait.info", which appears in the Referer field of most of the packets. I investigated creating a filter utilizing the iptables "recent" directive, which filters on the number of consecutive hits per time period, but the hits are spread out between each host sufficiently to make this ineffective. This is true for the other two sources (not associated with Mailbait) I identified as well, which I traced to ISP DHCP ranges.
I have seen this starting to occur at some other Mailman sites as well. Anyone else seeing this or have any ideas about how best to handle this? I have it under control for now but it is changing the way we use our lists.
Sadly, I don't see how that can be avoided. The problem is the SMTP and HTTP protocols themselves, which have no easily used provision for authentication or authorization of clients. (How many students do you know who walk around with a personal X.509 certificate?)
If you have suggestions for the admin interface, that would be very helpful. Even if you don't have a lot of confidence in them, this is a hard problem that requires wild ideas.
CAPTCHA for subscription requests would go a long way in preventing this type of exploitation.
Thank you,
-- Gary Kalbfleisch -- Director of Technology Support Services -- Shoreline Community College -- (206) 546-5813 -- (206) 546-6943 Fax
Kalbfleisch, Gary writes:
Kalbfleisch, Gary responds:
Messages are batchable, but administrative tasks are not. As you noted you must tick each box, and yes I'm talking pages and pages of bogus subscription requests. Quite tedious.
This would be a bigger problem than losing valid requests if it was frequent.
I think these too should be batchable but perhaps separately. What I would like to be able to do is to change all administrative messages to discard (or whatever) with one click, then go back and change the legitimate subscription requests back to accept.
I regularly lose posts to mailing lists because of this way of doing things.
After analyzing the httpd logs I have identified three primary sources of the bogus subscription requests, the most predominant being associated with http://mailbait.info.
Wonderful. Not much Mailman can do about the network-level DoS, but I suppose the web interface could filter on referrers. If mailbait.info is in the Referrer header, return a 404. ;-)
If you have suggestions for the admin interface, that would be very helpful. Even if you don't have a lot of confidence in them, this is a hard problem that requires wild ideas.
CAPTCHA for subscription requests would go a long way in preventing this type of exploitation.
I'm pretty sure there are third-party extensions for this.
I'm dubious about the net value of CAPTCHAs. Personally, I generally take a CAPTCHA as a "NO TRESPASSING -- THIS MEANS YOU!" sign, and don't go back.
On Oct 22, 2012, at 5:40 PM, Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
I'm dubious about the net value of CAPTCHAs. Personally, I generally take a CAPTCHA as a "NO TRESPASSING -- THIS MEANS YOU!" sign, and don't go back.
CAPTCHAs are already at the point where advanced code can apply statistical methods and solve them faster and better than many humans.
Moreover, they have been problematic for a long time -- see <http://www.tkachenko.com/blog/archives/000537.html>, <http://ezinearticles.com/?Captchas-Considered-Harmful---Why-Captchas-Are-Bad-And-How-You-Can-Do-Better&id=1104207>, and <http://coding.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captc...>, among others.
IMO, CAPTCHAs have already jumped the shark.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
I personally don't care for CAPTCHA but it exists for a reason. If anyone can suggest a better solution I would love to here it. Right now Mailman is being exploited to email bomb individuals and DOS email systems. This cannot continue.
Gary Kalbfleisch
Sent from my iPod
On Oct 22, 2012, at 6:08 PM, "Brad Knowles" <brad@shub-internet.org> wrote:
On Oct 22, 2012, at 5:40 PM, Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
I'm dubious about the net value of CAPTCHAs. Personally, I generally take a CAPTCHA as a "NO TRESPASSING -- THIS MEANS YOU!" sign, and don't go back.
CAPTCHAs are already at the point where advanced code can apply statistical methods and solve them faster and better than many humans.
Moreover, they have been problematic for a long time -- see <http://www.tkachenko.com/blog/archives/000537.html>, <http://ezinearticles.com/?Captchas-Considered-Harmful---Why-Captchas-Are-Bad-And-How-You-Can-Do-Better&id=1104207>, and <http://coding.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captc...>, among others.
IMO, CAPTCHAs have already jumped the shark.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Kalbfleisch, Gary writes:
I personally don't care for CAPTCHA but it exists for a reason.
Sure, the eternal search for easy solutions to difficult problems.
If anyone can suggest a better solution I would love to here it. Right now Mailman is being exploited to email bomb individuals and DOS email systems. This cannot continue.
It's not obvious there are better solutions. It's pretty obvious that CAPTCHA is at a stage where serious miscreants won't be slowed much by it (there are canned solutions, and even in 2009 they were good enough for automated mischief-making), while it does bother legitimate users.
You're right that it can't continue, but I don't really know if there's a way out. It may just not be possible to advertise open- subscription lists without attracting such abuse.
One thing we could try is to encourage use of OpenID (which Mailman doesn't support AFAIK, but there may be third-party patches, and I bet Mark (2.1 series) and Barry (Next Generation) would both be happy to see it. I guess mailbomb.com could just automate creation of GMail or Hotmail accounts, so it wouldn't be a permanent solution. But it would be transparent to most users, and some would be actively pleased by it.
On Tue, 2012-10-23 at 01:31 +0000, Kalbfleisch, Gary wrote:
I personally don't care for CAPTCHA but it exists for a reason. If anyone can suggest a better solution I would love to here it. Right now Mailman is being exploited to email bomb individuals and DOS email systems. This cannot continue.
Take a look at <http://areyouahuman.com/>. While this technology may not solve all the problems presented by CAPTCHAs, this is certainly a promising direction in which to look for alternatives.
-- Lindsay Haisley | "Behold! Our way lies through a FMP Computer Services | dark wood whence in which 512-259-1190 | weirdness may wallow!” http://www.fmp.com | --Beauregard
Lindsay Haisley writes:
Take a look at <http://areyouahuman.com/>.
I just tried their sample. I'd rather face a CAPTCHA! And their twitter feed reads like spam -- same comments, same apparent author, different avatar. Not a great start if they want to captcha my lists! ;-)
Seriously, I can see how it would work if they got the human factors right. Also seriously, do they have an accessible alternative? (No less than three of the people who currently aren't on my list that I wish were on it are somewhere between totally blind and "visually challenged".) And of course nothing visual works if you use a text browser.
In general, it's still a stopgap. Requiring a test is offensive to real people. If you want to live only in meatspace (and be untrackable in the virtual world), I guess that's unavoidable. But for the vast majority of people, they just want to have an ID they can use to sign up anywhere, without being treated like the spamming equivalent of HIV.
On Wed, 2012-10-24 at 11:57 +0900, Stephen J. Turnbull wrote:
Lindsay Haisley writes:
Take a look at <http://areyouahuman.com/>.
I just tried their sample. I'd rather face a CAPTCHA! And their twitter feed reads like spam -- same comments, same apparent author, different avatar. Not a great start if they want to captcha my lists! ;-)
Well that's understandable. Their enterprise has a bit of the flavor of a small-time hustle; nonetheless, my point is that they seem to have focused on a simple paradigm that would be very hard to crack short of some sort of advanced AI technology. It's this aspect that bears exploring.
Seriously, I can see how it would work if they got the human factors right. Also seriously, do they have an accessible alternative? (No less than three of the people who currently aren't on my list that I wish were on it are somewhere between totally blind and "visually challenged".) And of course nothing visual works if you use a text browser.
It's not hard to imagine an audio equivalent - a simple puzzle, such as "Press 1 when you hear the sound of a duck". This example would be culturally constrained (people with no experience with ducks would be puzzled!) but this is a direction to consider. All captchas are by their very nature culturally constrained to a greater or lesser degree.
In general, it's still a stopgap. Requiring a test is offensive to real people. If you want to live only in meatspace (and be untrackable in the virtual world), I guess that's unavoidable. But for the vast majority of people, they just want to have an ID they can use to sign up anywhere, without being treated like the spamming equivalent of HIV.
Any solution to the problem is going to have to be anchored in meatspace. This is the bottom line on detecting the difference between bots and people.
Life is a study in tradeoffs. The tradeoff of having "an ID they can use to sign up anywhere, without being treated like the spamming equivalent of HIV" would probably be a gross loss of anonymity, the digital equivalent of having a passport which could be verified through a government's department of state. This might be just as onerous to some people as a captcha or a puzzle.
Yes, some people consider a captcha to be offensive, and I've had colleagues who won't use them for sites where they really don't want to communicate the slightest hint of suspicion to visitors, such as political organizations that are eager to sign up volunteers or supporters. A captcha becomes kind of like passing muster with a bouncer who's making sure that a club's dress code is observed.
On the other hand, most people get spam, and hate it, and can appreciate that their own interests are served by having to jump through a hoop or two to make sure that they're entering a bot-free zone. I think a lot of the acceptability of such schemes hinges on how they're presented and introduced in the context of their usage.
-- Lindsay Haisley | "Friends are like potatoes. FMP Computer Services | If you eat them, they die" 512-259-1190 | http://www.fmp.com | - Aaron Edmund
Lindsay Haisley writes:
On the other hand, most people get spam, and hate it, and can appreciate that their own interests are served by having to jump through a hoop or two to make sure that they're entering a bot-free zone.
Sure, all of that is true, except for the implication that CAPTCHAs and other complicated reverse Turing tests actually are effective enough to be worth it. As several people have pointed out, all you really need to do is to make up your own trivial test that requires actually understanding English.
It will keep 'bots out, but if somebody really wants you, they'll do it themselves or pay somebody to do it.[1] CAPTCHAs and PlayThru work only because nobody really wants access to your piddly little list anyway.
Footnotes: [1] In fact, I bet a sufficiently smart ripoff artist could simply VNC the Playthru to some other site that lots of people (speaking loosely here) want to access (porn, gambling), and then relay the solution back to the site they want access to.
- Brad Knowles <brad@shub-internet.org>:
On Oct 22, 2012, at 5:40 PM, Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
I'm dubious about the net value of CAPTCHAs. Personally, I generally take a CAPTCHA as a "NO TRESPASSING -- THIS MEANS YOU!" sign, and don't go back.
CAPTCHAs are already at the point where advanced code can apply statistical methods and solve them faster and better than many humans.
I recently got 30 new comments on my blog, all of which were spam. And of course I'm using a CAPTCHA there. So Brad's point is probably valid.
-- Ralf Hildebrandt Charite Universitätsmedizin Berlin ralf.hildebrandt@charite.de Campus Benjamin Franklin http://www.charite.de Hindenburgdamm 30, 12203 Berlin Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
On 10/22/2012 11:55 PM, Ralf Hildebrandt wrote:
I recently got 30 new comments on my blog, all of which were spam. And of course I'm using a CAPTCHA there. So Brad's point is probably valid.
I don't like captcha's either, and one of their problems is that they're so easy to see programatically.
I've seen an interesting method in use: Right above the form, the page text says "Enter the word blue below", it's in body text. In the form, there's a box named whatsthecolor (or maybe just 'fred'). User enters "blue" and everything goes on. I think it unlikely that anyone will code their bot to parse the correct word out of the body text and enter it in the right form field.
I've used a similar method for help email to places like yahoo. At the bottom of the text I ask "Please tell me your favorite color so I know I'm working with a real person." Seems to work.
z!
Le 23/10/2012 17:17, Carl Zwanzig a écrit :
I've used a similar method for help email to places like yahoo. At the bottom of the text I ask "Please tell me your favorite color so I know I'm working with a real person." Seems to work.
yes I also have "public" passwd on a wiki. By the way the pas is not on the wiki page but on the mail I send to user.
that said there are some real human paid to catch web site, and against that no luck :-(
jdd
-- http://www.dodin.org http://jddtube.dodin.org/20120616-52-highway_v1115
Note that for the majority of what I have seen in this attack it is the return email messages that the exploiters desire. I have seen some subscriptions actually get through but I have not seen them exploited in any way other than to add to the flood of emails to the subscriber. I have seen some evidence that these accounts may have been used in an attempt to harvest email address. I have of course deleted all of these accounts so I won't have the opportunity to observe how else they might be used.
As a result of this activity I have changed all lists so that confirmation is required for all subscriptions, and only list owners can view the list of subscribers. The confirmations don't actually solve the email bombing problem but it will keep bogus subscriptions to a minimum. I have implemented some iptables filters as noted previously but I have not yet opened up the web interface externally. I have been monitoring traffic directed to port 80 on my Mailman server and it has gone down significantly since I put up the block. I may open it up again next week to see how my iptables filters work.
-- Gary Kalbfleisch -- Director of Technology Support Services -- Shoreline Community College -- (206) 546-5813 -- (206) 546-6943 Fax
-----Original Message----- From: Mailman-Users [mailto:mailman-users- bounces+garyk=shoreline.edu@python.org] On Behalf Of jdd Sent: Tuesday, October 23, 2012 8:42 AM To: mailman-users@python.org Subject: Re: [Mailman-Users] Automated Subscription Bots Inundating List Owners With Subscription Requests
Le 23/10/2012 17:17, Carl Zwanzig a écrit :
I've used a similar method for help email to places like yahoo. At the bottom of the text I ask "Please tell me your favorite color so I know I'm working with a real person." Seems to work.
yes I also have "public" passwd on a wiki. By the way the pas is not on the wiki page but on the mail I send to user.
that said there are some real human paid to catch web site, and against that no luck :-(
jdd
-- http://www.dodin.org http://jddtube.dodin.org/20120616-52-highway_v1115
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail- archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman- users/garyk%40shoreline.edu
On Oct 23, 2012, at 9:28 AM, "Kalbfleisch, Gary" <GaryK@shoreline.edu> wrote:
As a result of this activity I have changed all lists so that confirmation is required for all subscriptions, and only list owners can view the list of subscribers. The confirmations don't actually solve the email bombing problem but it will keep bogus subscriptions to a minimum. I have implemented some iptables filters as noted previously but I have not yet opened up the web interface externally. I have been monitoring traffic directed to port 80 on my Mailman server and it has gone down significantly since I put up the block. I may open it up again next week to see how my iptables filters work.
BTW, all the general speculation and conversation about CAPTCHAs, etc... notwithstanding, you do clearly have a real operational problem today.
For your specific issue, I would recommend keeping your proposed solutions as relatively simple as possible, and layer them. Requiring confirmation is a good simple solution to a number of problems, as is restricting the ability to see list membership to only those people who are list owners.
In my experience, KISS+layering almost always beats solutions that are complex from Day One.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Kalbfleisch, Gary writes:
Note that for the majority of what I have seen in this attack it is the return email messages that the exploiters desire.
Yes, this is the most important point for Mailman developers, in fact. Thank you for reiterating it.
I have seen some evidence that these accounts may have been used in an attempt to harvest email address.
Yeah, but I don't know what you can do about that in an open subscription list unless you anonymize (which I'm not willing to do because private replies are often desirable on my lists, YMMV).
On Oct 23, 2012, at 8:41 AM, jdd <jdanield@free.fr> wrote:
that said there are some real human paid to catch web site, and against that no luck :-(
There's an old axiom in the security business that no defense can stop a sufficiently motivated attacker with sufficient resources. The US Secret Service knows this all too well, as they continue to try to protect the President (whomever that might be) against assassination attempts.
The "PlayThru" solution from areyouahuman.com is an interesting concept, but there are some other interesting alternatives as well. Among other things, I don't think that PlayThru would work for the visually-challenged, but then I've only read part of the FAQs so perhaps this is something they address later.
One interesting concept I've seen has been to use a mathematical function that is easy to compute (on your end), but hard to reverse (on the other end). Then you do a challenge-response query and they don't even get to see the "submit" button until the calculations are complete (automated via JavaScript, of course).
They could potentially hack the JavaScript, and maybe try to apply algorithms to speed up the calculations, so you have to choose carefully. Make the problem big enough, and even the biggest Google-enabled "rainbow tables" won't help, and it will be impossible to bypass with human-enabled methods.
The problem there is to *AVOID* making the problem so hard that your "real" customers are also prevented from being able to post -- that would be throwing the baby out with the bathwater.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
On Thu, 2012-10-18 at 23:53 +0000, Kalbfleisch, Gary wrote:
I am running 2.1.9 because that is the latest version available from Redhat as a package.
It's relatively simple to install Mailman from the source package, but one thing that would help a great deal with this would be default inclusion in the built package of a standard text or script that would contain, or issue, the arguments provided to configure during the build process. There are several critical parameters including the prefix, the var-prefix and of course the mail-gid which ought to be readily available for this purpose.
If you've already built Mailman from source, this information is of course available in the config.log, but for people installing Mailman from an outdated package from a distribution, and wanting to catch up with the latest improvements or security fixes, having this information available as part of the distributed end product would be a big help. This is already done for many large and complex packages, would be a big help in making the transition from a pre-built Mailman package to a source-based update.
Maybe this information is already available. I only spent about 5 minutes looking for it outside of the source tree and couldn't find it.
-- Lindsay Haisley | "Behold! Our way lies through a FMP Computer Services | dark wood whence in which 512-259-1190 | weirdness may wallow!” http://www.fmp.com | --Beauregard
On 10/29/2012 11:25 AM, Lindsay Haisley wrote:
On Thu, 2012-10-18 at 23:53 +0000, Kalbfleisch, Gary wrote:
I am running 2.1.9 because that is the latest version available from Redhat as a package.
It's relatively simple to install Mailman from the source package, but one thing that would help a great deal with this would be default inclusion in the built package of a standard text or script that would contain, or issue, the arguments provided to configure during the build process. [...] Maybe this information is already available. I only spent about 5 minutes looking for it outside of the source tree and couldn't find it.
See <http://wiki.list.org/x/KYCB> and the Mailman-Developers post linked therefrom. It's probably out of date and does not directly address the issue of making this information available as part of the 3rd party package, but it is probably still useful to someone trying to upgrade RedHat Mailman from source.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, 2012-10-29 at 11:43 -0700, Mark Sapiro wrote:
See <http://wiki.list.org/x/KYCB> and the Mailman-Developers post linked therefrom. It's probably out of date and does not directly address the issue of making this information available as part of the 3rd party package, but it is probably still useful to someone trying to upgrade RedHat Mailman from source.
Yes, this article is very informative, and at present may be the best thing available for an old-package to new-source upgrade. And yes, it does not address the issue of making this information available as a default part of the 3rd party package.
Such an enhancement would obviously not help anyone using a currently "older" Mailman package, but going forward, say into MM3, it might be a good idea to make this information available in some such way. I use courier as a MTA, and courier has a "courier-config" executable in /usr/bin which spits out all sorts of useful build information, including the package creator's build-time configure args.
-- Lindsay Haisley | "The difference between a duck is because FMP Computer Services | one leg is both the same" 512-259-1190 | - Anonymous http://www.fmp.com |
On Mon, 2012-10-29 at 14:14 -0500, Lindsay Haisley wrote:
On Mon, 2012-10-29 at 11:43 -0700, Mark Sapiro wrote:
See <http://wiki.list.org/x/KYCB> and the Mailman-Developers post linked therefrom. It's probably out of date and does not directly address the issue of making this information available as part of the 3rd party package, but it is probably still useful to someone trying to upgrade RedHat Mailman from source.
Yes, this article is very informative, and at present may be the best thing available for an old-package to new-source upgrade. And yes, it does not address the issue of making this information available as a default part of the 3rd party package.
Adding this feature would involve only about 6 lines of code :) in configure.in: --- configure.in.orig 2012-10-29 14:37:31.000000000 -0500 +++ configure.in 2012-10-29 14:59:13.000000000 -0500 @@ -18,7 +18,8 @@ AC_REVISION($Revision: 8122 $) AC_PREREQ(2.0) AC_INIT(src/common.h) - +CONFIGURE_CLI="$0 $@" +AC_SUBST(CONFIGURE_CLI) # /usr/local/mailman is the default installation directory AC_PREFIX_DEFAULT(/usr/local/mailman) @@ -683,6 +684,7 @@ contrib/qmail-to-mailman.py \ contrib/courier-to-mailman.py \ contrib/rotatelogs.py \ +contrib/mm-config \ cron/bumpdigests \ cron/checkdbs \ cron/cull_bad_shunt \ And in the contrib directory, a short script, mm-config, to display this information: #!/usr/bin/python print """Mailman was built with the following configuration invocation: %s""" % ("@CONFIGURE_CLI@",) This properly belongs on the mailman-developers list, so please excuse my posting it on the thread here, but I though the discussion might be useful. I also posted it to the developers list. -- Lindsay Haisley | "Real programmers use butterflies" FMP Computer Services | 512-259-1190 | - xkcd http://www.fmp.com |
On Oct 29, 2012, at 02:14 PM, Lindsay Haisley wrote:
Such an enhancement would obviously not help anyone using a currently "older" Mailman package, but going forward, say into MM3, it might be a good idea to make this information available in some such way. I use courier as a MTA, and courier has a "courier-config" executable in /usr/bin which spits out all sorts of useful build information, including the package creator's build-time configure args.
Mailman 3 should be much more FHS friendly out of the box. Of course, one important change is that we have actual ini-file configuration and not the crazy mm_cfg.py stuff.
The ini-file contains a [mailman]layout configuration variable which names a [paths.*] section from your configuration file. These sections are used to locate all the directories Mailman puts things. By default, it uses the [paths.dev] layout which puts everything under a local, relative 'var' directory. It comes with a [paths.fhs] section so switching to FHS layout (which of course distro versions of Mailman 3 should do), you would add the following to your mailman.cfg file:
-----snip snip----- [mailman] layout: fhs -----snip snip-----
Here are the values it uses in FHS layout:
[paths.fhs] # Filesystem Hiearchy Standard 2.3 # http://www.pathname.com/fhs/pub/fhs-2.3.html bin_dir: /sbin var_dir: /var/lib/mailman queue_dir: /var/spool/mailman log_dir: /var/log/mailman lock_dir: /var/lock/mailman etc_dir: /etc ext_dir: /etc/mailman.d pid_file: /var/run/mailman/master.pid
Of course, if you wanted to e.g. put the master.pid file in /run instead of /var/run, you could do something like this:
-----snip snip----- [mailman] layout: slashrun
[paths.slashrun] bin_dir: /sbin var_dir: /var/lib/mailman queue_dir: /var/spool/mailman log_dir: /var/log/mailman lock_dir: /var/lock/mailman etc_dir: /etc ext_dir: /etc/mailman.d pid_file: /run/mailman/master.pid -----snip snip-----
Cheers, -Barry
I like to stick with packages when possible because it makes maintenance much easier. This is really a non-issue since the current version of Mailman does not have a fix for this problem.
Thank you,
-- Gary Kalbfleisch -- Director of Technology Support Services -- Shoreline Community College -- (206) 546-5813 -- (206) 546-6943 Fax
-----Original Message----- From: Mailman-Users [mailto:mailman-users- bounces+garyk=shoreline.edu@python.org] On Behalf Of Lindsay Haisley Sent: Monday, October 29, 2012 11:25 AM To: mailman-users@python.org Subject: Re: [Mailman-Users] Automated Subscription Bots Inundating List Owners With Subscription Requests
On Thu, 2012-10-18 at 23:53 +0000, Kalbfleisch, Gary wrote:
I am running 2.1.9 because that is the latest version available from Redhat as a package.
It's relatively simple to install Mailman from the source package, but one thing that would help a great deal with this would be default inclusion in the built package of a standard text or script that would contain, or issue, the arguments provided to configure during the build process. There are several critical parameters including the prefix, the var-prefix and of course the mail- gid which ought to be readily available for this purpose.
If you've already built Mailman from source, this information is of course available in the config.log, but for people installing Mailman from an outdated package from a distribution, and wanting to catch up with the latest improvements or security fixes, having this information available as part of the distributed end product would be a big help. This is already done for many large and complex packages, would be a big help in making the transition from a pre-built Mailman package to a source- based update.
Maybe this information is already available. I only spent about 5 minutes looking for it outside of the source tree and couldn't find it.
-- Lindsay Haisley | "Behold! Our way lies through a FMP Computer Services | dark wood whence in which 512-259-1190 | weirdness may wallow!” http://www.fmp.com | --Beauregard
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail- archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman- users/garyk%40shoreline.edu
On Mon, 2012-10-29 at 21:04 +0000, Kalbfleisch, Gary wrote:
I like to stick with packages when possible because it makes maintenance much easier.
As do I. There are times, however, when mission-critical packages in a distribution are outdated, or absent, or broken and building from source is the only option. IMHO, having the knowledge and the tools on one's system to do builds from the upstream source is an important system administration skill. I always seem to have one or two packages on any box that end up being built from source. Mailman is one of them, because I have a number of patches for it that I've developed, and because building and installing it from source is very easy.
Juggling packages vs. upstream source is something you get used to. All package management system that I know of have ways of freezing packages at a certain level or version so that your custom builds don't get crosswise of package management.
-- Lindsay Haisley | "Real programmers use butterflies" FMP Computer Services | 512-259-1190 | - xkcd http://www.fmp.com |
Don't assume that I don't have the skills. I have been building the linux os from source since long before most people even heard of the Internet. I manage my time very carefully, and mailman is a very small part of what I do. The newest version of mailman does not resolve any of the issues that I have been expiriencing if you have read my posts. I have implemented the security measures required using other means until such a time that they are resolved in mailman.
Regards
Gary Kalbfleisch
Sent from my iPod
On Oct 29, 2012, at 8:37 PM, "Lindsay Haisley" <fmouse-mailman@fmp.com> wrote:
On Mon, 2012-10-29 at 21:04 +0000, Kalbfleisch, Gary wrote:
I like to stick with packages when possible because it makes maintenance much easier.
As do I. There are times, however, when mission-critical packages in a distribution are outdated, or absent, or broken and building from source is the only option. IMHO, having the knowledge and the tools on one's system to do builds from the upstream source is an important system administration skill. I always seem to have one or two packages on any box that end up being built from source. Mailman is one of them, because I have a number of patches for it that I've developed, and because building and installing it from source is very easy.
Juggling packages vs. upstream source is something you get used to. All package management system that I know of have ways of freezing packages at a certain level or version so that your custom builds don't get crosswise of package management.
-- Lindsay Haisley | "Real programmers use butterflies" FMP Computer Services | 512-259-1190 | - xkcd http://www.fmp.com |
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/garyk%40shoreline.edu
On Tue, 2012-10-30 at 04:56 +0000, Kalbfleisch, Gary wrote:
Don't assume that I don't have the skills.
I don't. Please accept my apology if you thought that I implied this.
I have been building the linux os from source since long before most people even heard of the Internet. I manage my time very carefully, and mailman is a very small part of what I do. The newest version of mailman does not resolve any of the issues that I have been expiriencing if you have read my posts.
Yes, I have been following the thread. An update to a newer version of MM would allow you to bulk-delete spurious subscription requests - a small advantage, to be sure, but a time-saver over versions which didn't offer this administrative feature.
I have implemented the security measures required using other means until such a time that they are resolved in mailman.
FWIW, I've had very good results using SpamAssassin as a pre-filter for Mailman, using James Henstridge's package (patched for post MM versions
= 2.1.10). See:
http://wiki.list.org/pages/viewpage.action?pageId=4030589 http://www.jamesh.id.au/articles/mailman-spamassassin/
This filter also blocks a lot of spurious subscription attempts, according to my list hosting customers, who have told me that the filter has substantially reduced the amount of administrative spam they have to deal with (compared to when the filter has not been in place) and haven't mentioned a problem with false positives.
I know this filter is quite old, but with the patch for more recent MM versions (wiki.list.org) it seems to work quite well.
Servers here also block email at the front door based on the CBL advisory list, which probably also helps.
-- Lindsay Haisley | "Humor will get you through times of no humor FMP Computer Services | better than no humor will get you through 512-259-1190 | times of humor." http://www.fmp.com | - Butch Hancock
participants (10)
-
Barry Warsaw -
Brad Knowles -
Carl Zwanzig -
jdd -
Kalbfleisch, Gary -
Lindsay Haisley -
Mark Sapiro -
Ralf Hildebrandt -
Stephen J. Turnbull -
Stephen J. Turnbull