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
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
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
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.
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
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].*)?'),
]
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,
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
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
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
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)
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
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
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
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
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:
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
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,
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
(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
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,
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
35 matches
Mail list logo
