[Mailman-Users] Intermittent attacks agains Mailman instance
Over the past couple of months, I've observed a series of attacks against Mailman that are likely related because they use the same tactic every time. That tactic is to use Mailman's web interface to generate multiple subscription requests for multiple people. My guess is that the goal may be either (a) to harrass those people or (b) to get the outbound subscription confirmation requests from Mailman marked as spam (in mail systems which support that function) or (c) both. To spot this: check your subscription logs for bursts of activity -- in particular, subscription requests for the same address to multiple lists (including multiple unrelated mailing lists), and in further particular, requests that are never ACK'd, AND, in further particular, requests that originate from network space unlikely to be populated by real users. Of course I have no way of knowing if the instance I'm looking at is the only one being targeted or whether others are seeing this as well. On that point, it might be useful for those of you reading this to extract the networks below and use "grepcidr" or a similar tool to check them against your logs. That's part of my reason for writing this. The other part is to share the lists of network allocations that I've firewalled out from ports 80 and 443; all of these participated in one or more attacks (and subsequently tried to particpate in others, but were blocked). You may want to preemptively drop these into your firewall(s) IF it turns out that other Mailman instances are also being targeted. Here there are, in three groups: Pnvgroup: 23.94.58.0/25 PNVGROUPLtd 23.94.58.128/25 PNVGROUPLtd 23.95.99.0/25 PNVGROUPLtd 107.172.18.0/25 PNVGROUPLtd 192.3.56.0/25 PNVGROUPLtd 192.3.56.128/25 PNVGROUPLtd 192.3.57.0/25 PNVGROUPLtd 192.3.57.128/25 PNVGROUPLtd 192.3.58.0/25 PNVGROUPLtd 192.3.58.128/25 PNVGROUPLtd 192.3.59.0/25 PNVGROUPLtd 198.12.72.128/25PNVGROUPLtd 198.23.168.0/25 PNVGROUPLtd 198.23.168.128/25 PNVGROUPLtd 198.23.169.0/25 PNVGROUPLtd 198.23.170.0/25 PNVGROUPLtd 198.23.170.128/25 PNVGROUPLtd 198.23.171.0/25 PNVGROUPLtd 199.188.102.0/25PNVGROUPLtd Proxies-LLC: 108.165.184.0/22PROXIES-LLC 108.165.188.0/22PROXIES-LLC 108.165.184.0/22PROXIES-LLC 75.102.24.0/23 PROXIES-LLC 75.102.8.0/23 PROXIES-LLC Miscellaneous: 91.243.92.0/24 QualityNetworkCorp 91.243.94.0/24 QualityNetworkCorp 103.160.101.0/24IRT-DURABLEDNS-AP 172.98.181.0/24 Braveway/PrivateCustomer 172.104.17.0/24 Linode (this is just a chunk of the network) 194.26.135.0/24 ChangWayTechnologiesCoLimited 194.33.191.0/25 VirtuoHoldingsInc 194.33.191.128/25 VirtuoHoldingsInc ---rsk -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
[Mailman-Users] Re: mailman v2.x
On Wed, Aug 26, 2020 at 09:28:30AM -0400, Jim Popovitch via Mailman-Users wrote: > So, I have volunteered to spearhead an effort to add one or two more > people to the Mailman Coders group[2] in order to vet and approve new > features that continue the long tradition of providing value to Mailman > 2.x. Who's with me on this? 1. Sure. 2. I'm finishing the book on it anyway, so I might as well. ;) 3. Captchas are a worst practice in security and should never be used. They can be and are defeated at will by any adversary who wants to trouble themselves to do so. They're also user-hostile. There are much better methods available for protecting Mailman instances from abusers. Yes yes I know I just signed myself up to explain those. This is not my first time. ;) 4. One of things that I discovered while doing (2) is that Mailman v2.x expects that it has *outbound* HTTP access. I need to write this up so that the problem is understandable/arguable/fixable, but: it's a really bad idea to presume that's the case, and it's an equally bad idea to make it the case. ---rsk -- Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
[Mailman-Users] GSOC idea: The central scrutinizer ;)
I have a partially-completed spec for a module that will examine messages for various issues but my Python-fu is likely not sufficient to realize it and I'm busy writing anyway. This is probably a GSOC-size and GSOC-scope project, so if anybody is game, below is a poorly-written and large incomplete description of what I have in mind. 1. As I've said for years, anti-abuse controls should be layered and should start at the network perimeter (with things like the Spamhaus DROP list in border routers). Additional layers may be in firewalls, in the MTA, in the MLM (such as Mailman). No one layer can catch everything because it doesn't have contextual knowledge, e.g., the firewall doesn't know who the members of a mailing list are or even that a particular SMTP connection it's allowing contains traffic for a mailing list. Unfortunately, email accounts have been hijacked by the billions (and that's just counting Yahoo). The new owners of those accounts likely enjoy the same SMTP reachability that the old owners did and can thus drop messages onto mailing lists. (I'm going to omit the long explanation about why context-sensitive measures in the MTA are not only inadequate to stop this, but are also highly undesirable.) To put it another way: we don't have many defenses against our friends. But we need them. 2. We all have our own views on proper netiquette for mail/mailing lists, and of course, mine are the only correct ones. ;) But regardless of those, it'd be useful to have a mechanism to scrutinize messages for things like "800 lines of quoted digest with one top-posted line above it". Of course some of this is easy to see and hard to code, but I think a modest attempt in this direction would be helpful. (Besides, if the action taken on detection of these is to merely hold the message, then little harm is done by false positives.) 3. 1 and 2 are related. The same kinds of criteria that are useful in detecting and putting a hold on spam are useful in detecting undesirable content in messages, like URL shorteners and third-party tracking links. So it makes sense to have a highly configurable module that comes with a minimal/loose default configuration that can be salted to taste. So what I have in mind is a module that scrutinizes messages based on a set of (enabled/disabled) criteria, each one of which is configurable. I know that's not very clear. Let me make up an example and see if that helps. Let's suppose we call this module the Central Scrutinizer (CS) because oblique tributes to Frank Zappa are always in order. The CS might have a list of dozens of checks like this: - URL shorteners (1) - tracking links (2) - full digest quoting (3) Check (1) would consult a list of known URL shortening domains and do pattern matching of any URLs in the message against them. Check (2) would attempt to detect tracking links/"web bugs". Check (3) would check messages to see if it includes an entire quoted digest. Each one of these would be associated with an action -- and I strongly think that "hold" would be best, because these tests are going to make lots of mistakes for a while. The results would be presented to list owners (in email notifications and in the browser interface) with something like: Central scrutinizer report: - URL shorteners - fail, example.net detected - tracking links - pass, none detected - full digest quoting - pass, none detected with appropriate presentation so that it's easy to read and so that when a test fails, it reports *why* it failed. Let me note that the MTA is wrong place to do this stuff for a whole bunch of reasons. Among other things, lots and lots of people want different policies applied to mailing list traffic (which will result in outbound mail traffic) than they due to local traffic (which won't). This is a serious issue for anybody concerned with their mail system's reputation, which is based on what it emits, not what it accepts. Of course not everyone will agree with every check, and not every check is appropriate on every mailing list. (For example, a one-way announce-only list is unlikely to need most of these.) But if this is modular, and if individual checks can be switched on/off readily, then it can ship with everything off and folks can enable whatever subset they find palatable. Let me also note that the motivation for this comes not just from things I've bumped into while running lists, but things I've seen on other lists. (And I'm on rather a lot of them.) I've been thinking about this for years, but have become convinced in the last six months or so that the problem has now reached a point where a solution is worth constructing. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy:
[Mailman-Users] GSOC idea: mail server/DNS server/mailing list healthcheck
The idea for this comes from some of the web sites that perform this; unfortunately most of them are "upgrading" from simple, fast, easy checks to bloated ones that use a ton of Javascript, can't be scripted, and are increasingly behind signups/paywalls/etc. The concept is simple: given a domain, check its DNS, mail, etc. setup for correctness and consistency. For example: - does it have an A record? - is that valid hostname? - does it have an record? - is that valid hostname? - does it have MX records? - are the MX records *not* CNAMEs? - are they valid hostnames? - do those hostnames resolve to public IP addresses? - are any of those MX records duplicates? - are all the MX responding? - are the MX weights valid? - do all MX's pass FCrDNS check? - does it have NS records? - are they valid hostnames? - do they have A, records? - are they in public IP space? - are the NS records *not* CNAMEs? - do all NS pass FCrDNS check? - are any of those NS records duplicates? - does the list of NS match the list of authoritative NS? - do all the NS return the same list of NS? - do all the NS return the same list of MX? - do the NS *not* allow recursion? - are any of the NS lame? - are any of the NS missing? - are all the NS responding? - is there a working postmaster address? - is there a working abuse address? - is there a working hostmaster address? - if not is there a working address that matches the one in the SOA? - is the domain's SOA sane? (e.g. plausible serial number, refresh, retry, etc.) - do all the NS return the same SOA with the same serial number? - is there ASN diversity among the NS? - and so on Those are the sort of checks that pertain to the operation of any domain and its nameservers and mail exchangers. But in addition, if run on a Mailman 2 or 3 host: - what mailing lists are public? - what mailing lists are private? - does every list have a working -request address? - does every list have a working -owner address? - does every list have a working -bounces address? - if any list supports the optional -subscribe address, does it have a -unsubscribe address? - if any list supports the optional -join address, does it have a -leave address? - and so on Note: command-line tool. It has to be, because then it can be scripted and run via cron and so on. Besides, anyone running name servers, mail servers, etc., had better be able to work at the command line. Note: should work on systems that aren't running Mailman: just can't analyze Mailman then, of course. This leaves open the door for people using other MLMs to write checks that work with those. And maybe that'd be a nice thing to do. Note: should have varying levels of verbosity, including one that explains why something is wrong by referencing RFCs/BCPs/manual by chapter and verse. Note: the second set of checks (above) are outside the scope of what Mailman checks inside itself. That is, they require correlating what Mailman thinks should be in place versus what's actually in place in the MTA. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Brute force attacks on mailman web ui
On Mon, Apr 16, 2018 at 02:05:35PM -0400, tlhackque via Mailman-Users wrote: > Good advice.??? But use httpS: (and make sure the UA validates the server > certificate). > Unless you fancy experimenting with DOS attacks. Yep. You're exactly right. > But the biggest source of attacks, by far, is the US.??? Unfortunately, > while some people run business that don't interact with the US, in most > cases a non-country based approach is necessary for that :-) Yes. There's no question that the US is a huge source of attacks, and if I were running a mailing list for birdwatchers in Australia, I'd seriously consider blocking it. But you're right, that bumps into all kinds of hosting/infrastructure issues and so blocking the whole country will likely have unpleasant side effects. > https://github.com/tlhackque/BlockCountries > A new release that provides better management is overdue -- but > hopefully soon. That...is cool. Thanks for the pointer. > The best defense for ssh is to configure it for certificate > authentication only. >The script kiddies will make their 10,000 login attempts [...] True, but I find the clutter in logs annoying. ;) So in situations where I know a priori that a valid login attempt will never originate from an operation, I just firewall it and let them eat dropped packets. > [I'm not kidding; I do see lists of 10K+ attempts from "adam adam", > "adam password" thru "zeke password" "zeke zeke"...] I stood up a new server last fall with *no* valid ssh access and logged about 750,000 attempts in a month. Similar patterns. > If you keep up your lists of cloud services' network blocks & have them > on a publicly accessible > website, I'll add them to my list of optional block lists.??? (Hopefully > you use a standard format - e.g. > ipaddress[/netmask or length] with # or ; comments...) I keep them in CIDRnetwork-name but honestly I'm not diligent enough about maintaining them. As a result, they're always under-inclusive (very rarely over-inclusive). That works for what I use them for, but I'm hesitant to inflict my laziness on others. Let me see if I can locate someone who's doing a better job than I am. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Brute force attacks on mailman web ui
On Mon, Apr 16, 2018 at 09:08:43AM +0200, mailman-admin wrote: > Brute Force attempts can only be mitigated by e.g. fail2ban. Nope. There are other ways. Brute force attacks can be pre-emptively blocked by nearly everyone operating a Mailman instance. (I say "nearly" for specific reasons that will become clear below.) 1. You'll need a firewall, either in front of your Mailman instance or onboard the same system, that can handle a significant number of IP ranges in CIDR format. I highly recommend "pf", which is part of OpenBSD (among others) and is easily the best firewall available. However, you can do this with other firewalls such as iptables just as readily. 2. Get the Spamhaus DROP (Don't Route Or Peer) list, along with the EDROP list: http://www.spamhaus.org/drop/drop.txt http://www.spamhaus.org/drop/edrop.txt They're small. Take a look at them. The DROP/EDROP lists are well-curated and consist of blocks that are known to be hijacked and known to belong to malicious actors. You should *bidirectionally* block *all* traffic to/from the networks listed on them: HTTP, SMTP, DNS, everything. Update them by fetching new copies once a month. 3. The next step depends on the intended audience for your mailing lists. If you're operating one for a bowling league in Akron, Ohio, then you probably don't need to accept subscription attempts from Peru, Pakistan, or Portugal. If on the other hand you're operating one with global reach then you'll need a different approach. In either case, you'll want ipdeny.com's list of all network blocks by country: http://ipdeny.com/ipblocks/data/countries/all-zones.tar.gz and you may want the Okean lists of blocks for China and Korea: http://www.okean.com/chinacidr.txt http://www.okean.com/koreacidr.txt (In theory, the list of CN and KR blocks in ipdeny's compilation should exactly match Okean's. In practice, there are slight differences that tend to resolve over time. I think if you're only configuring for CN and KR, use the latter; if you need more, use the former. But we'll get to that.) By the way, if you use these, you should update them once a month just like the DROP/EDROP lists. 3a. If your list is localized to one country or two or six, then use the ipdeny data to configure your firewall to block *all* HTTP traffic to your mailman instance and then only allow traffic from the countries that you need. This usually takes a huge bite out of incoming abuse. 3b. If your list is global or nearly so in scope, then block as many countries as you can. Look at your logs, see where the attacks are coming from, see where real subscriptions are coming from, and figure out the disjoint set. (The utility "grepcidr" is often very helpful.) If you have, let's say, zero subscriptions from FR over the past nine years but do have a parade of attacks: firewall it out. I recommend, in doing this analysis, that you start by looking at CN and KR. Why? Because two decades of careful logging and analysis of data from quite a few sites indicates that these are #1 and #2 on the hit parade of attackers. There's no point in trying to file complaints in the hope that some responsible professional will take remedial action and make it stop: just firewall and forget. (Next on the list are RU and IN. Same problems.) Comment on 3a and 3b: Yes, this is draconian. That's a good thing. Let me quote for you what I think is arguably the best thing ever said on NANOG, and given the tens of thousands of years of accumulated network experience represented there, that's saying a lot: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie You can either get to work with a firewall or you can continue to be a victim. Choose. If you want to continue to allow SMTP traffic from these countries so that users can subscribe/unsubscribe/etc. via mail that's your call. I've tailored my configuration to suit the lists that I run and in some cases, that includes configuring the MTA to deny traffic from the same ranges as the web server; in others, it includes denying traffic from the TLD; in others, both. The key to all of this is understanding (a) what you need to allow in order for your lists to function as intended and (b) what your own logs are telling you about what attacks/abuse are coming from. 4. Supplement this by blocking operations that are unlikely to originate any valid subscriptions but are likely to originate abuse. For example, Amazon's cloud -- due to the negligence and incompetence of the people running it -- is a notorious source of nonstop brute-force attacks. They not only refuse to do anything about it, they refuse to even accept
Re: [Mailman-Users] MM3 book in the works
On Sat, Jan 13, 2018 at 06:34:03PM +, Tom Browder wrote: > Good deal, Rich, that book is sorely needed IMHO! Is there any place we can > sign up to get a copy or see its status? I'm currently shoving Markdown into my brain at an accelerated pace while simultaneously stitching together a number of already-written modules into something that might vaguely resemble cohesive chapters. This is not happening in a particular order, e.g., chapters 7 and 3 may emerge before chapter 1. But as soon as they're ready, I'll make pieces available for review. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] MM3 book in the works
On Sat, Jan 13, 2018 at 05:27:01PM +, Tom Browder wrote: > I would love to see a new book on MM3. Anyone know of such a project > proposed or in the works? I've been working on a book about mailing list management and usage -- including MTAs, MLMs (such as Mailman), processes, best practices, etc. The MM material to this point has been MM2-centric, but I've been running various instances of MM3 and accumulating experience with it. This is intended -- somewhat -- as a modern version of "Managing Mailing Lists" by Schwartz, which is now 20 years old. Obviously the landscape has changed quite a bit since then; I don't think we need to worry much about UUCP-style addresses any more, but we do need to worry about DMARC. And so on. I can't see leaving out MM2 at this point, because a LOT of people are running and are going to be running it for years. But it would seem a disservice not to cover MM3. So I suspect, at the risk of some duplication, both with have to make the cut. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Our list serv host is threatening to shut us down for spam abuse
I'll second the suggestion that you split the list. I'll also suggest
that you do *not* subscribe anyone to the split-off instance: you should
make them go through a COI (confirmed opt-in) process AND you should
make certain that you retain all records of that as long as the list
exists. ("records" being the Mailman logs and copies of any correspondence.)
But let me make a general comment about this problem -- which stems
from companies like AOL and Yahoo delegating control of part of the
anti-spam process to their users.
That's incredibly stupid. It's off-the-scale idiotic. It flies in
the face of everything we've learned about spam in the past several decades.
Consider: if users, en masse, could reliably distinguish spam from
non-spam, would the spam problem be as bad as it is?
No. It would not. It would only be a tiny fraction of its current scale.
But users have spent the past several decade proving, beyond any
possible argument, that they are absolutely horrible at this task.
So delegating it to them is not only lazy, it's insane.
To be clear: yes, users should be able to *report* suspected spam.
That's why everyone should have an abuse@ address per RFC 2142
and decades of best practices. A user who's capable of remembering
that, and who's capable of forwarding spam to it with full headers,
is a user at least worth paying attention to. (And of course the
local admin/postmaster/abuse/whatever team should read and analyze
every such message: that's mail system admin 101.) But a user who
blindly hits the spam button for any message they don't like or
don't find useful or don't agree with or anything else is worse
than useless: they're actively degrading the process.
Dave Crocker put it quite well when he said:
The best model to invoke, with respect to the idea of recruiting
end users to be active participants in abuse detection or
prevention is mostly:
Don't.
Unfortunately, the AOLs and Yahoos of the world are deaf to this.
And as a result of that, I have no doubt whatsoever that many of your
non-spam messages are being flagged as spam by users at those operations
(and elsewhere) despite the fact that they're on-topic for a mailing list
that they signed up for.
I've found it necessary to use VERP and similar techniques to identify
the specific individuals responsible for this abuse and to either
(a) unsubscribe them and/or (b) ban them. This isn't a panacea, but
it does help cut down on the complaint rate and thus the spurious
blacklisting.
---rsk
--
Mailman-Users mailing list Mailman-Users@python.org
https://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:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Mailman and recipient spam filtering
On Mon, Apr 04, 2016 at 05:30:13PM -0700, Andrew Daviel wrote: > I have an incident where a rejection message was forwarded to a > list, and on to other members. I don't know if that was even > mailman, but it got me thinking. First, that's because the system which originated the rejection is broken. All mail systems doing anti-spam/anti-virus/anti-whatever should *always* reject (if they're going to reject) during the SMTP conversation (a) because that's most effective and efficient and (b) because that avoids generating a bounce message, which in turn avoids backscatter such as you've described. Second, anything coming back should go to the Sender:, which I believe defaults to: LISTNAME-bounces@LISTHOST I believe that LISTNAME-bounces, in turn, should be sent by the MTA in play to: "|/usr/local/mailman/mail/mailman bounces LISTNAME" (although I have it set up like this in the sendmail aliases file: LISTNAME-bounces:"|/usr/local/mailman/mail/mailman bounces LISTNAME", postmaster@LISTHOST so that the local postmaster gets a copy of the bounce for examination.) This doesn't necessarily yield the desired outcome, e.g., it may result in incrementing the bounce count for a subscriber when that shouldn't really happen, but at least it avoids forwarding backscatter to an entire mailing list. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Subscription Form Spam -- It continues . . .
I'd be curiously to see the logs for these. (I intend to check them against various address range lists to see if the originating IP addresses correlate with anything else I'm tracking.) If they're coming from botted hosts, then (as noted in the thread) using the XBL or similar may help. If they're coming from hijacked networks, then the DROP/EDROP lists may help. If they're coming from...well, without analyzing the data and looking for patterns, it's hard to say what will help. But I'm certainly willing to put in some time scripting and eyeballing even though the most likely outcome is nothing useful. Mark is probably right about the addresses being forgeries, but once in a while attacks like these turn out to be using a smattering of real ones mixed in with the junk. That's why I suggested running the collation past Gmail people: they may be able to match it up with some other activity that isn't visible out here. (Or not.) Question/speculation: in the SMTP world, we've found that using things like greet_pause (which causes the SMTP server to refrain from sending its greeting for a little bit, and thus lets us detect SMTP clients that start sending too soon) can be pretty effective. Does the timing of these attacks lend itself to a similar approach? (Yes, of course clients can and will eventually adapt...but years later, greet_pause still manages to fend off some of the attacks.) ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Subscription Form Spam -- It continues . . .
On Wed, Oct 07, 2015 at 09:16:32AM -0400, br...@emwd.com wrote: > I have seen another type of subscription form spam pop-up on our > servers. It is particularly affecting one client that has 80 mailman > lists and they wish to keep their lists publicly advertised. We keep > seeing dozens of subscription spam coming in from gmail addresses > PER MINUTE with the following format: There are multiple approaches to this: 1. Look at the logs. Find out where the subscriptions are coming from, and firewall out the appropriate network(s) or countries. (See ipdeny.com for country IP ranges.) or 2. If you only expect to receive subscriptions from one or a few countries, then firewall out the entire world and only allow connections from that small set. and/or 3. Use the Spamhaus DROP and EDROP lists in your firewall and drop *all* inbound traffic from and *all* outbound traffic to those ranges. This achieves lossless compression. (This should be done whether you do 1 or 2 or neither. It's basic network self-defense.) and/or 4. Collect all the forged subscriptions and have a chat with the email people at Gmail. It's possible that they can do something about this on their side. I can put you in touch with someone if need be. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Wonderful gmail (was: at Slayter 7pm TOMORROW Wed., FREE Beginner lesson, Live Band)
On Wed, Sep 02, 2015 at 02:10:23PM +0200, Laura Creighton wrote: > But we may be at 'friends don't let friends use gmail' time, if > not right now, then fairly soon. Exactly how many things can you > do to break mail, Google? I (a) strongly concur with this and (b) will add that this sentiment also applies to MSN/Hotmail, Yahoo, and, sadly [1], AOL. ---rsk [1] Why "sadly"? Because some years ago Carl Hutzler and his team managed to fight an uphill battle against AOL management apathy and cluelessness, and made significant progress toward the goal of making AOL's mail service a quality operation. AOL welcomed this success by dismissing the entire team and the slide back into incompetence and negligence began almost immediately. Not that I agreed with everything Carl et.al. did, because I didn't; but I recognized that they had good intentions and they worked hard. To see all that effort discarded is appalling. -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
[Mailman-Users] Bogus/forged subscription attempts: request for comments and possibly data
If you (Mailman site operators) have a spare moment, please try running this: cut here-- #!/bin/sh cd /var/local/mailman/logs egrep pending [a-z]+ [a-z]+@[a-z]+\.com subscribe \ | egrep -v @gmail.com \ | egrep -v @hotmail.com \ | egrep -v @msn.com \ | egrep -v @aol.com \ | egrep -v @yahoo.com \ | sed -e s/(.*pending// cut here-- This is a first-cut, mildly sloppy script that will try to match some patterns of interest that I've noticed in my subscribe log and that might be in yours. The egrep clauses are in there to throw away data not of interest; the sed snips off the mailing list name and some other irrelevancies. Here is what the last 10 lines of its output look like on my system: Jun 06 00:14:32 2014 ehkfioxlkrr yuj...@zwdxgc.com 62.210.226.131 Jun 06 13:23:16 2014 norchmecn sty...@zdddmk.com 86.51.26.20 Jun 07 02:06:20 2014 eljult qbp...@wabtdh.com 86.51.26.11 Jun 07 13:21:20 2014 dvlevbpj drk...@nlcvek.com 210.14.138.102 Jun 07 15:41:10 2014 sdbdelkv mtp...@ghazhc.com 86.51.26.18 Jun 07 16:17:10 2014 yqrebrgipo ubn...@cgtnki.com 86.51.26.20 Jun 08 06:37:12 2014 cihjwn sou...@bprryw.com 202.143.148.58 Jun 08 06:55:47 2014 ehxvwgrboo iou...@mnaisa.com 86.51.26.21 Jun 08 23:47:58 2014 qqpluym jpb...@qkvfdi.com 190.14.219.166 Jun 09 16:44:15 2014 mloepuj fig...@jjxlcu.com 172.245.142.194 This is forged gibberish, of course. The user real name is always a lowercase alpha string. The email address is also, both LHS and RHS, and the TLD is always .com. (Hence the regexp in the first egrep.) I'm curious. First, is anybody else seeing these? Second, does anyone have a theory as to their purpose? And third, is there any value in combining data to see if patterns emerge? (I have some privacy concerns about that last one, since real email addresses might leak through, so I suspect if we decided to do that, it would be best to remove everything but the timestamp and IP address. I doubt the gibberish has any real explanatory value anyway.) ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Export all subsribers
On Sun, Jun 08, 2014 at 08:11:54PM +0300, EyeLand wrote: Hello, on mailing list I have many emails on Membership Management... - [Membership List], how I can export all on txt file? Thank you. From the shell: ~mailman/bin/list_members name-of-mailing-list will put the list on stdout, so you could redirect it to a file if you wish: ~mailman/bin/list_members name-of-mailing-list roster If you have a number of mailing lists and want to dump them all, you could use something along the lines of: #!/bin/csh set filelist = `~mailman/bin/list_lists -b` foreach i ($filelist) ~mailman/bin/list_members $i $i.roster end which will create a series of files whose names consist of the name of each mailing list suffixed with .roster. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] DMARC issues
(my apologies to anyone who reads NANOG, this is mostly a repeat of what I said there) On Thu, Apr 10, 2014 at 11:36:16AM -0400, Barry Warsaw wrote: It *is* a shame that these anti-spam defenses knowingly break mailing lists. It's a shame that this is being pushed as an anti-spam defense when in fact (a) it has little-to-no anti-spam value and (b) measures that have much higher anti-spam value with few adverse effects are not being used. Nearly all (at least 99% and likely quite a bit more) of the spam [as observed by my numerous spamtraps] that purports to originate from Yahoo really *does* originate from Yahoo. All that I have to do to verify that is to look at the originating host -- that is, it's not necessary to check DMARC or anything else. There are several reasons for this. First, Yahoo has done an absolutely miserable job of outbound abuse control. For over a decade. Second, they've done a correspondingly miserable job of handling abuse reports, so even when one of their victims is kind and generous enough to do their work for them and tell them that they have a problem...they don't pay attention and they don't take any action. (Or they fire back a clueless boilerplate denial that it was their user on their host on their network...even though it was all three.) Also for over a decade. Third, why would any spammer forge a @yahoo.com address when it's easy enough to buy hijacked accounts by the bucketful -- or to use any of the usual exploits to go get some? Fourth, at least some spammers seem to have caught on that Yahoo isn't *worth* forging: it's a toxic cesspool because the people running it have allowed it to be become one. So let's not pretend that this has anything to do with stopping spam. If Yahoo actually wanted to do something about spam, they could have done that years and years ago simply by *paying attention* to what was going on inside their own operation. This is just (a) propaganda, so that they claim to be doing something and (b) a clumsy attempt to coerce people into using *their* mailing lists, which are just as horribly run as the rest of their mail system. ---rsk -- Mailman-Users mailing list Mailman-Users@python.org https://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: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Amazon SES and Verified Senders
On Fri, Jan 11, 2013 at 09:27:23AM -0800, Duane Winner wrote: Does anyone have any ideas on how to deal with this? [snip] Amazon's cloud has been a prolific long-term source of spam and other forms of abuse (e.g., brute-force ssh attacks). Thus it's long since been a best practice to refuse all email from hosts in compute-1.amazonaws.com and compute.amazonaws.com subdomains, and no doubt unless serious efforts are made to address this, blocking of incoming SMTP connections from Amazon's cloud will eventually increase in both scope and coverage. Not that this is your fault, of course. But unless you can convince Amazon to take an active interest in controlling *outbound* abuse from their operation, there's little you can do about it. So my recommendation is to set up a VPN tunnel from your Mailman host to a (secure) SMTP relay outside their network space. (And of course outside other problematic network spaces; check Spamhaus and similar resources first.) Let the host inside Amazon do the heavy lifting of running Mailman and so on, let the one outside do the simple work of just relaying outbound traffic. OpenBSD+postfix+BIND on very low-end hardware should suffice, and as long as it only relays traffic handed off via the VPN, you should be okay. (Incidentally, verifying senders has no anti-spam value. I get spam by the megabyte in my spamtraps all day, every day, from verified senders and from verified hosts.) ---rsk -- 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/archive%40jab.org
Re: [Mailman-Users] Best Mail Program to Use w/ Mailman
On Mon, Feb 22, 2010 at 11:20:05AM -0500, Beyer, Clay wrote: We are setting up a Debian web server and would like to use Mailman to manage a couple of mailing lists that we control. After some initial complications with Mailman and Postfix we decided to uninstall and reinstall everything, before we get going again, I just wanted to get an idea of what the best mail program, taken from the Mailman Documentation, to use with Mailman... Postfix, Qmail, Exim, or Sendmail. I strongly recommend against qmail, as it is not suitable for professional or even amateur use. I have deployed the rest in various environments numerous times. None is best across the board, but each may be best depending on your environment, your needs, and your mail system knowledge. Roughly, and I emphasize ROUGHLY speaking: - exim is the simplest to install and configure. If your needs are straightforward and modest, this might be the best choice. - postfix is not as simple, but it *is* modular, well-designed, and quite capable of supporting complex environments. - sendmail is still more complex, but is widely known (in part because of its longevity) and there is a larger knowledge base for it than any other MTA. Sendmail milters offer an extensive feature set for sufficiently-advanced administrators. Personally, I tend to use sendmail and postfix -- in part because I'm usually dealing with non-straightforward environments. However, I would advise that if you think can manage with exim, you should at least try. Without having detailed knowledge of the factors above (environment, needs, knowledge) it's tough to say much further than that, but: if you're only handling mail for one domain, if you're only handling mailing list traffic, if you're not running an associated POP/IMAP server, if you're running a single server, if you're handling low to moderate volumes of traffic, then my guess would be that exim will work very well for you. ---Rsk -- 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/archive%40jab.org
Re: [Mailman-Users] Sending bulk mail (400,000 users)
On Sat, Apr 11, 2009 at 09:38:05PM +0530, Phoenix Kiula wrote: Hi. I need to send annoucements to a large opt-in list. Having never done this before [...] Since you've never done this before, and you mention that the list has 400K users, I urge extreme caution. Unless you/your operation have explicitly requested and explicitly received permission from all 400K users to send them bulk email, then you should not do so. Note that permission is NOT transferable: a user who has given permission to A to receive bulk email from A has not given that same permission to B. Permission cannot be bought, sold, traded, presumed or inferred: and the sending of bulk email without permission is called spamming. For further explanation, please see: http://www.spamhaus.org/faq/answers.lasso?section=Marketing%20FAQs ---Rsk -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] The economics of spam
On Sun, Jan 04, 2009 at 03:56:42PM -0800, Jan Steinman wrote: Is it really necessary to take this arrogant and abusive tone? Consider it exasperation at seeing this FUSSP brought up yet *again*, long after it was staked through the heart and buried at a crossroads. Please see: http://www.rhyolite.com/anti-spam/you-might-be.html#e-postage for background on and examples of FUSSPs. If you (rhetorical you) want to self-educate and to potentially apply yourself to addressing the problem, then by all means, please do. But this list isn't appropriate; I suggest joining some/all of these: spam-l (via lists...@peach.ease.lsoft.com) asrg (via asrg-requ...@irtf.org) spamtools (via spamtools-requ...@lists.abuse.net) AND reading most of their archives, especially spam-l, before attempting to promulgate your favorite tactic/strategy. (I'm not the only one with a short fuse when it comes to dealing with the same known-failed idea for the 47th time, although I will readily admit that some others show far more patience than I do. Maybe they have more -- or better -- brandy.) ---Rsk p.s. As a small courtesy, and by way of compensation, let me try to provide some minor assistance to potential future contributors by enumerating a few of the fundamental design errors that immediately doom some anti-spam ideas: - redefining abuse - redirecting abuse - amplifying abuse - fighting abuse with abuse - failure to consider scaling issues (what if everyone did this?) - failure to consider adoption issues (what if everyone didn't do this?) - failure to consider counter-measures (what if spammers read RFCs?) - generating yet more SMTP traffic - presumption of spammer honesty/compliance/acquiescence - allowing unknown third parties to generate significant amounts of outbound traffic to destinations of their choosing - reliance on legislation and/or law enforcement - forcing effort and costs of abuse control onto third parties - drastic underestimation of spammer resources and abilities - presumption of secure network endpoints There's more, of course, but a few minutes' contemplation of these is sufficient to understand why some approaches (e.g., opt-out, SPF, C/R, SAV, BlueFrog, and yes, e-postage) are not going to work regardless of how they're implemented, and why attempts to implement them make (or would make) the spam/abuse problem considerably worse. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] The economics of spam
On Sat, Jan 03, 2009 at 02:52:21PM -0800, Jan Steinman wrote: No, it is based upon the idea that a system could be implemented whereby it would be impossible to avoid the payment. It can't. This idiotic idea resurfaces periodically (see hashcash and other similar products of the wishful thinking of clueless newbies [1]). It is one of the very stupidest anti-spam ideas -- and there's a lot of competition for that honor, unfortunately. [2] I suggest that you refer to the archives of the spam-l and irtf-asrg mailing lists for a quite thorough debunking of this nonsense by the most senior and experienced people working in the field. ---Rsk [1] Hashcash fails on inspection because attackers control vastly more computing resources than defenders, by several orders of magnitude. [2] Including anti-spam ideas which actually make the problem worse. See C/R and SAV, for example. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] The economics of spam
On Sun, Jan 04, 2009 at 11:15:19AM -0600, J.A. Terranson wrote: I realise I may well be just another stupid newbie in your eyes, so please explain why something that can enforce a fixed amount of work to each and every transaction on the SENDER's side is a bad idea by itself. I've covered this in detail elsewhere, and it's not really appropriate for this list, so I'll be brief. I suggest those interested in such schemes peruse the archives of various spam-related mailing lists and newsgroups. Hashcash is an attempt to drown people who own the ocean. Spammers control, in the aggregate, several orders of magnitude more computing horsepower than anyone else. (And could, if they deemed it desirable or necessary, increase that computing pool even further.) I'm talking, of course, about the ~10e8 hijacked systems out there (zombies) and will note in passing that this is an order-of-magnitude estimate: based on my research as well as that of others, I wouldn't be surprised if the actual number was in the 2x10e8 to 4x10e8 range. [1] The activities that these systems are currently engaged in (sending spam, hosting DNS for spamvertised web sites, hosting spamvertised web sites, harvesting email addresses, conducting DoS attacks, etc.) consume only a small fraction of their available computing capacity -- that is, the overwhelming majority is left over. There is plenty left to maintain the illusion for their former owners [2] that they actually still control these systems -- and there is certainly plenty left to deal with any additional computational burden imposed on an SMTP transaction. Note as well that each time the former owners of these systems upgrade them, their new owners acquire a free performance increase. Similarly, when they replace them, the same poor computing practices (e.g., use of inferior operating systems, careless downloading, missing or incorrect firewall configuration, etc.) that led to the compromise of the old system quite often lead to compromise of the new one, once again resulting in a free performance increase for the new -- that is, the real -- owners. Thus we see that imposing such a requirement will not impede spammers in the slightest -- while it *will* impede nearly everyone else. Note as well that in the several years since it first became clear that spammers (and other abusers) had acquired these resources, no reasons have surfaced to indicate that the problem is getting or will get any better. On the contrary, there is every reason to believe that the problem is getting steadily worse. [3] Spammers/abusers now control an essentially-unbounded pool of computing resources -- not just CPU, but memory, disk, bandwidth, etc. So all that hashcash and other similar schemes would do is burn a lot of CPU in a lot of places...for absolutely nothing. ---Rsk [1] Note that the actual number is not only unknown, but unknowable, since a system which provides no externally-visible evidence of its hijacked state will not be detected. Neither will a system which does provide such evidence, but does not provide it to a suitable detector. Note as well that there is substantial evidence which suggests that hijackers have long since learned to hold many systems in reserve against the possibility that some are lost to them; clearly, this is a basic strategic concept well within their grasp, so it would be surprising if they *didn't*. [2] If someone else can run arbitrary code of their choice on your system, it's not YOUR system any more. [3] It's not necessary to take my or anyone else's word for this. Anyone running a mail server can acquire their own sample by using passive OS fingerprinting, rDNS lookups, and spam logging in combination. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] The economics of spam
On Sun, Jan 04, 2009 at 02:56:40PM -0600, J.A. Terranson wrote: You're argument boils down to it's not wholly effective, [snip] Actually, my primary argument is that it has/would have zero effect. There's no point in deploying something that the enemy completely defeated years ago. My secondary argument, which I didn't bother to articulate here, but have gone into elsewhere, is that it may well make the spam and related abuse problem *worse*. (One of the most common mistakes made by those proposing anti-spam measures is that they presume the enemy will passively or actively accomodate those measures, despite decades of evidence suggesting that at best, such measures will encounter passive resistance, and at worse, they'll be actively subverted to suit the enemy's purposes.) ---Rsk -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] The economics of spam
On Tue, Dec 23, 2008 at 10:15:43AM -0800, Jan Steinman wrote: I would willingly pay a hundredth of a cent (or so) per email sent if it would reduce spam to near-zero. This is a thoroughly-discredited, utterly broken idea which, unfortunately, seems to keep coming back like a bad penny. It is based on the ludicrous notion that abusers -- who have consistently demonstrated themselves to be willing to spam, hijack computer systems, purloin ASNs, craft spyware, release viruses, send junk faxes, etc. -- will, for absolutely no reason whatsoever, suddenly and magically behave honestly and pay to send mail. Please. Put a stake through the heart of this idiocy and let's not ever mention it again. ---Rsk -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Users] Suggestion: do not include List-Id header on subscribe/unsubscribe messages
Reasoning: those messages are not actually mailing list traffic. Yes, they're related to the list, and they're about the list, but they're not being sent through the list per se. In addition, one of the things that I've noticed is that filtering/filing based on List-Id (say, a procmail recipe) will filter/file these messages along with ordinary list traffic. But I don't think that's desirable behavior; especially in case of unsubscribe notifications generated on the server side (say, due to an excess number of undeliverable messages). Opinions, comments? ---Rsk -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Users] Spam backscatter: Which aliases to remove
On Thu, Mar 20, 2008 at 10:56:07PM -0500, Brad Knowles wrote: On 3/20/08, Rich Kulawiec wrote: (Incidentally, I'm not aware of any current effort to update RFC 2142.) Not any current efforts to update 2142, no. But there are other standard role mailbox names that I've seen used and recommended, although I have not yet been able to locate a source for some of those. My experience matches yours: I think we're all walking around with various (differing) lists of role mailbox names that we picked up over time. Do you think it'd be worth the effort to attempt to bring all those together, figure out which ones are worth recommending (or mandating), and then updating 2142? ---Rsk -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] corporate spam filter operation
On Fri, Mar 21, 2008 at 08:50:45PM -0400, Matt Morgan wrote: Are there corporate, enterprise spam-killing services that work on a user-by-user basis, rather than a message-by-message basis? For example, where the same message, sent to a few different people, might be rejected as spam for one recipient but not others? Yes, there are. There are also innumerable ways to handle this using open-source software coupled with MTAs like sendmail, postfix, etc. But (and I'll try to keep this very short since it's off-topic, so contact me off-list to discuss) I consider it a major strategic mistake to attempt this. Per-user exceptions only benefit the enemy. And under no circumstances should users be permitted to control them: they're clearly incapable, as they've proven hundreds of millions of times (if not more) and continue to prove all day every day. See also item #5 on Marcus Ranum's most excellent: The Six Dumbest Ideas in Computer Security http://www.ranum.com/security/computer_security/editorials/dumb/ ---Rsk -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Spam backscatter: Which aliases to remove
On Wed, Mar 19, 2008 at 05:34:18PM -0500, Barry Warsaw wrote: On python.org this is postmaster. Do many sites split the responsibilities between mail and list care and feeding? I know that some do, some don't; but beyond that, I don't have much of a feel for how it's done across the 'net. I thought that perhaps raising the subject for discussion here might provide at least a few data points from this community. Locally, I've delegated responsibilities equivalent to what I think of as listmaster to people who are trained to work with Mailman and majordomo, but not yet ready to dabble with sendmail and postfix. I've also found it useful to add list-owners to the listmaster alias expansion in order to add some transparency to the process. (I split this off from postmaster because most of that traffic doesn't pertain to lists, and some of it involves private mail issues that don't need to be exposed to list-owners.) (Incidentally, I'm not aware of any current effort to update RFC 2142.) ---Rsk -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Spam backscatter: Which aliases to remove
On Mon, Mar 17, 2008 at 07:10:30PM -0700, Kenneth Porter wrote: Ok, thanks. It sounds like I can safely prune admin, subscribe, unsubscribe, join, and leave. That leaves bounces, confirm, owner, and request, which I can tolerate dealing with manually. I certainly agree with keeping -request, especially because of RFC 2142 Section 6: Mailing lists have an administrative mailbox name to which add/drop requests and other meta-queries can be sent. For a mailing list whose submission mailbox name is: [EMAIL PROTECTED] there MUST be the administrative mailbox name: [EMAIL PROTECTED] Distribution List management software, such as MajorDomo and Listserv, also have a single mailbox name associated with the software on that system -- usually the name of the software -- rather than a particular list on that system. Use of such mailbox names requires participants to know the type of list software employed at the site. This is problematic. Consequently: LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED, INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE MAILBOX NAMES. RFC 1211 discusses the use of owner -- except that it's owner-list, not list-owner. I've seen both used over the years, and tend to favor the latter as it keeps the list name first, which is handy when searching or sorting alias or virtusertable files. I think it's also less confusing to users: my experience has been that just getting the -request convention firmly established can often take considerable effort, so it seems to me that if we get that far, then keeping the form consistent is a win. There's been all kinds of discussion on this point, some of which has to do with the vagaries of particular MTAs or MLM programs (like majordomo) and some of which has to do with the nuances of how people are running their lists. If we ever get around to updating RFC 2142, I think I'd like to argue for including the trailing -owner form instead of the leading owner- form. What I do locally: list-owner is fed to mailman just like -request or anything else. Inside mailman, I use owner-list as the value of the relevant field. Then I have an alias owner-list which actually expands to the list of people who run the list. This lets me change that list of people without getting into the mailman config: it's just an alias update. It also lets me send messages directly to those people (via owner-list) without routing them through mailman. And it means that something reasonable will probably happen to incoming mail from outside addressed to owner-list or list-owner. Summarizing that last paragraph of unintelligble gibberish: Inside mailman: the foo-list owner field value is owner-foo. In the aliases file: foo-owner: |/usr/local/mailman/mail/mailman owner foo owner-foo: [EMAIL PROTECTED], [EMAIL PROTECTED] so the last entry is the only thing that needs to be touched if the keepers of the list change. While I'm blabbing about this, I'd like to float another idea related to RFC 2142. We have postmaster (mail), webmaster (web) and quite often hostmaster (DNS). How about listmaster, which would expand to the person or persons responsible for the overall care and feeding of mailing lists associated with this domain? Why have such as thing? Because there are many sites (like one that I run) where the keeper of the mail system, mailman, and everything else isn't one of the people responsible for any lists, and vice versa. So asking a random list-owner, or even asking all list-owners, to effect a site-side change doesn't work because none of them can do it. Hence...the listmaster, who *can* do it and is thus the right person to be contacting. Thoughts? (...produces pocket-watch, swings it slowly...yes...yes...you are all concurring that it is positively the most brilliant thing you have ever read...god...sleeep now...) ---Rsk -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
On Fri, Jun 29, 2007 at 01:25:15PM -0700, John W. Baxter wrote: I wasn't referring to sender verification callbacks (which we do not use). I was referring to recipient verification callforwards, where the edge MTA doesn't know valid recipients but some internal (or even customer) MTA does. Exim can configure these easily (but that doesn't help because Mailman doesn't act like an MTA). I don't know about any other MTAs in this regard. Ah, understood. *Those* I highly approve of, since they at least help mitigate accept-then-bounce issues due to non-existent recipient addresses at the final/internal/destination MTA. Whether it's done by callforwards, or LDAP lookups, or script-generated virtual user tables, or aliases, or whatever, I'm all for it. ---Rsk -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
On Sat, Jun 30, 2007 at 10:36:19PM +0900, Stephen J. Turnbull wrote: You have to be careful, though. For several years on one of my lists I had a subscriber whose address was something like (I don't recall exactly) [EMAIL PROTECTED], which was a perfectly valid address and at which he/she/it did receive mail and from which he/she/it would reply. Agreed, care is needed in order to avoid false positives. (nobody, by the way, is often aliased thus in stock sendmail installations on various 'nix boxes: nobody: /dev/null so while there's nothing wrong with it per se -- and it's not a special address per RFC 2142 -- I find myself wondering how many people have hardwired it into various anti-spam setups. ;-) ) I should probably mention that I'm not a fan of [EMAIL PROTECTED] and similar addresses, which seem to be often used these days for one-way mailing lists: I think *all* messages should be replyable. But I figure that, as a practical matter, as long as so many sites are using that convention, we might as well leverage it to our advantage. ---Rsk -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] specific (1) LHS and (2) sender rules tofrustrate spam/phishing
On Fri, Jun 29, 2007 at 01:35:51PM -0700, Mark Sapiro wrote:
If I were trying to do it, I would use the KNOWN_SPAMMERS list in
mm_cfg.py. For example just listing a few of yours
KNOWN_SPAMMERS = [
('from', '^(.*[\s])?do-not-reply@'),
('from', '^(.*[\s])[EMAIL PROTECTED]([\s].*)?'),
]
That's *very* handy to know. I'm going to do some limited
experiments with it over the next week or two, and will be
back with results.
Thanks!
---Rsk
--
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/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
Two related suggestions. (1) LHS (left-hand-side) rules Any incoming mail message whose putative sender matches: do-not-reply@ do.not.reply@ donotreply@ no-reply@ no.reply@ noreply@ and which is directed to any of the Mailman standard aliases can be rejected (not bounced [1]) with SMTP status 550 (extended status 5.7.1) since either: (a) it's a forgery, therefore there's no point in letting Mailman attempt to emit a reply -- or even in accepting the message to begin with. (a) it's not a forgery, therefore there's no point in trying to reply to it. (Nor is there any point in permitting it to subscribe to a list or send any traffic to one.) Arguably, this could be done in some MTAs by configuring rejection of those LHS patterns on a per-local-user basis; but I'll argue that doing this in Mailman itself would be more useful, since many (perhaps most) sites don't use per-local-user configuration (and perhaps don't know how). Moreover, any site running multiple mailing lists would need to set this up for every Mailman alias for every mailing list -- so it seems simpler to handle it inside Mailman itself. My guess is that this should be a switchable feature, named something like reject-noreplies. (Not that I can envision a need to switch it off, but I think it'd be more conversative to have that option.) (2) sender rules Any incoming mail message whose putative sender matches the list below can also be rejected (SMTP status 550, extended status 5.7.1) because these addresses will never send traffic to any mailing list nor subscribe to any mailing list. There's thus no point in expending the bandwidth/CPU necessary to process them, nor in forwarding them on to list admins for possible approval -- any message from these addresses to any Mailman-related address is invariably a phish attempt. I'm sure this list is incomplete; I built it by looking at incoming attempts received locally in 2007. It's not meant to be complete, only illustrative. Again, this could be done at the MTA level by blocking on a per-local-user basis, but (as above) I think wiring it into Mailman would make it useful to people who do not have their MTAs so configured. And this should probably also be switchable feature, perhaps named reject-obvious-phishes. More comments below this list. [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Mailman-Users] specific (1) LHS and (2) sender rules to frustrate spam/phishing
Mark, John -- reading both your messages (and applying significantly more coffee) has induced enlightenment. Yep, this is just not going to work the way I'd suggested. Bad me. No biscuit. So let me modify these as follows and see if this is any better: (1) LHS (left-hand-side) rules Present to list-owner for disposition as done today, but mark it prominently as noreply address, almost certainly a forgery. (2) sender rules Present to list-owner for disposition as done today, but mark it prominently as probable phish. Granted, in both cases, the message still has be to processed, but perhaps marking it (both on the Subject line and inside the message body) will make it easier/faster for list-owners to deal with. ---Rsk p.s. As as aside, I strongly recommend against callbacks/SAV. It's inherently abusive, it's a deliberate attempt to bypass site security policies [and thus illegal in some jurisdictions, but ask your attorney for clarification 'cause IANAL], it provides a spam support service, and -- as we've already seen -- it can be used to conduct quite effective DoS/DDoS attacks. And on top of that, far more effective, efficient, and difficult-to-abuse anti-spam methods exist. I'm working [yeah, alright, for some values of work] on a stupid anti-spam techniques FAQ that will cover this in considerably more depth, so I don't intend this to be by any means a full explanation. However, this topic has been repeatedly discussed on Spam-L in depth, so I'll refer anyone interested to that list's archives until I can manage to get that FAQ cranked out. -- 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] your software
Interesting discussion. I don't think anyone pointed out to the original questioner that mailman seems to work on any number of Unix-ish platforms (since he asked for a non-Linux OS): I'm playing with it in another window on OpenBSD on Sparc at the moment. I don't want to get into an elaborate discussion of the credit given vs. credit asked for vs. credit taken mess, except to make a couple of general comments: 1. Sometimes folks who should get the credit don't -- because they never asked for it and nobody really knew to give it to them. 2. Sometimes folks get credit for something despite their best honest efforts to disclaim it. 3. Sometimes it's unclear, even to the people doing the work, who should get credit for it. This gets really complicated as we build on each others' work, whether in terms of code, protocols, interfaces, or ideas. 4. Thankfully, most people really do make an effort to try to claim the appropriate amount of credit and disclaim any more. ---Rsk -- Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
