on 12/18/08 6:15 PM, Marvin Humphrey said:
I run a couple software support mailing lists on a site that's been around for
a decade or so. I'm the only admin, and an avalanche of spam crashes down on
me every day.
Welcome to the club.
Ideally, I'd like to simply turn off the list-owner
Moin,
On Fri, 19 Dec 2008 02:03:55 -0600
Brad Knowles b...@shub-internet.org wrote:
Generally speaking, one of the best things you can do to lighten your
burden is to have a good anti-spam system incorporated into your MTA, so
that you block that ~95% of e-mail that is actually spam from
NFN Smith writes:
(Note - you are subscribing to a list of mailing lists, so the
password notice will be sent to the admin address for your
membership, myaddress-ow...@example.com)
This is a feature oriented to umbrella lists. For example, suppose
you have two departments, Support and
Brad Knowles writes:
1) Eliminate any public reference to the list-owner address
That doesn't really solve the problem. Anyone, anywhere can easily
guess list-owner and list-request and list-bounces, etc... for any given
list address.
Brad, do you think spammers really do that just
On Thu, Dec 18, 2008 at 04:15:18PM -0800, Marvin Humphrey wrote:
Greets,
I run a couple software support mailing lists on a site that's been around for
a decade or so. I'm the only admin, and an avalanche of spam crashes down on
me every day.
Are they all coming from the same address?
Jeanne Ilchuk wrote:
I was looking thru the archives and found this note from 2004 (below) which
gave me the impression that it did not work with exchange. That being said,
here are more of my details.
I'm installing on a Solaris sparc (v10), which has a functioning Sendmail on
it. I just
Attila Kinali wrote:
Moin,
Is this meant in the French version of the word, or the Northern Germanic
interpretation? Or is there another interpretation I should be aware of?
IMHO mailman should allow to filter all mailman related adresses
seperately, w/o requiring any changes in the MTA
Stephen J. Turnbull wrote:
Brad, do you think spammers really do that just to increase their
address count? I've always assumed that they were just harvested in
the usual way.
I am convinced that spammers do this, yes.
Just like they boost their deliverability numbers by intentionally
On Fri, 2008-12-19 at 02:03 -0600, Brad Knowles wrote:
on 12/18/08 6:15 PM, Marvin Humphrey said:
I run a couple software support mailing lists on a site that's been around
for
a decade or so. I'm the only admin, and an avalanche of spam crashes down
on
me every day.
Welcome
Good Morning Everyone.
I think I see something in this debate that may be lost on the
mailman listowners. While you may have 14k++ users, they are well behaved
useers on a technical list.
The listowner you are comparing notes with (and correctly
asserting to split the work
James Riendeau wrote:
I need to run bin/add_member in our Mailman 2.1.11 list server
installation from a cgi/perl script. Normally, it has to run as
root. The easy solution was to add the www user to the mailman
group. You can then:
open(LISTSERVER, '|/usr/local/mailman/bin/add_members
On 12/18/08 06:51, Jeanne Ilchuk wrote:
I was looking thru the archives and found this note from 2004 (below)
which gave me the impression that it did not work with exchange.
I don't think that it is possible to integrate Mailman with Exchange
like you can with Sendmail / Postfix / Qmail /
Lindsay Haisley wrote:
I note that Brad doesn't mention this solution in his reply to you, so
it may be frowned upon officially, but I've found it helpful.
SpamAssassin is one good anti-spam tool, but IMO it should be integrated
into the MTA, because that's the only place where you can make
J.A. Terranson wrote:
The listowner you are comparing notes with (and correctly
asserting to split the work to) is more likely to be someone like me,
playing the role of listowner for non-technical people who use mailman
like it was IRC. Sadly, this is a not uncommon application for
On Fri, 19 Dec 2008, Brad Knowles wrote:
This is the first I'm hearing in this conversation as a request for more
granularity in terms of what certain users are allowed to do. More
granularity with regards to what they can do when sending messages to the list
is a perfectly reasonable
J.A. Terranson wrote:
OK. If it's reasonable, here's my wish list:
Add option checkboxes to the current request. You already have an Allow
this person to send in the future, add an Allow this person to ignore
future size limits and an Allow this person to use implicit addresses.
I'd
Lindsay Haisley wrote:
The problem with this is that no spam detection method is 100%
effective, and with SpamAssassin there's some overlap between setting
the rejection level low enough to be effective and getting false
positive identification of spam.
That's certainly true, but that's no
On Fri, 19 Dec 2008, Brad Knowles wrote:
J.A. Terranson wrote:
OK. If it's reasonable, here's my wish list:
Add option checkboxes to the current request. You already have an Allow
this person to send in the future, add an Allow this person to ignore
future size limits and an
When I upgraded my test Ubuntu system from Mailman 2.1.9 to 2.1.11
I saw messages for each list:
Updating mailing list: mailman
Updating the held requests database.
- updating old private mbox file
looks like you have a really recent CVS installation...
you're
Barry Finkel wrote:
When I upgraded my test Ubuntu system from Mailman 2.1.9 to 2.1.11
I saw messages for each list:
Updating mailing list: mailman
Updating the held requests database.
- updating old private mbox file
looks like you have a really recent CVS
Brad Knowles writes:
Just like they boost their deliverability numbers by intentionally
targeting postmaster@ addresses (because the RFCs require that
address will always accept mail no matter what).
Sad that their customers can be fooled by this
J.A. Terranson writes:
Add option checkboxes to the current request. You already have an Allow
this person to send in the future, add
Allow this person to ignore future size limits
Better phrasing would be
Do not enforce size limits on this person.
(in the future is implied,
On Fri, 2008-12-19 at 12:09 -0600, Brad Knowles wrote:
That's certainly true, but that's no reason to push anti-spam processing
back to the point where you can't use SpamAssassin to refuse to accept the
message. Even if you can't get 100% accuracy and 100% precision, you should
do all the
Brad Knowles writes:
Lindsay Haisley wrote:
The problem with this is that no spam detection method is 100%
effective, and with SpamAssassin there's some overlap between setting
the rejection level low enough to be effective and getting false
positive identification of spam.
You're
on 12/19/08 10:31 PM, Lindsay Haisley said:
SpamAssassin has to do a fairly intensive examination of the mail body
and may reject based on this examination, but because of the way SMTP
works, it's a bad practice to wait until after the DATA section of a
mail transaction is complete to reject an
on 12/19/08 10:32 PM, Stephen J. Turnbull said:
I don't much like this addition of more options per post, though,
because these pages are already too big for convenience, spilling over
to many screens. I would prefer a more compressed format so I can
nuke the obvious spam quickly, then go
On Fri, 19 Dec 2008, Lindsay Haisley wrote:
SNIP
Mailman already has a SpamDetect module which is reasonably useless, and
discards (not rejects) spam internally. What I'd really like is a way
Lindsay, you cannot, repeat NOT -reject- after you have accepted a
message. Nonononono! Go look
on 12/19/08 10:54 PM, Stephen J. Turnbull said:
Not entirely true. Many installations refuse to permit per-user rules.
(If you run SA yourself, you can specify the config file, and therefore
your own rules.)
Fair enough. Which leads me to what I've said before, which is that the
only
On Sat, 20 Dec 2008, Stephen J. Turnbull wrote:
J.A. Terranson writes:
Add option checkboxes to the current request. You already have an Allow
this person to send in the future, add
Allow this person to ignore future size limits
Better phrasing would be
Do not enforce
Lindsay Haisley writes:
So if I can't refuse potential spam at the SMTP front door, what
difference does it make whether it gets detected in Mailman or the MTA?
None. But one still wonders why anybody would consider *running
SpamAssassin* anywhere but in the MTA (or in the pipe to the
On Sat, 2008-12-20 at 13:54 +0900, Stephen J. Turnbull wrote:
Brad Knowles writes:
Lindsay Haisley wrote:
The problem with this is that no spam detection method is 100%
effective, and with SpamAssassin there's some overlap between setting
the rejection level low enough to be
On Fri, 2008-12-19 at 23:38 -0600, J.A. Terranson wrote:
On Fri, 19 Dec 2008, Lindsay Haisley wrote:
SNIP
Mailman already has a SpamDetect module which is reasonably useless, and
discards (not rejects) spam internally. What I'd really like is a way
Lindsay, you cannot, repeat NOT
On Sat, 2008-12-20 at 14:49 +0900, Stephen J. Turnbull wrote:
Lindsay Haisley writes:
So if I can't refuse potential spam at the SMTP front door, what
difference does it make whether it gets detected in Mailman or the MTA?
None. But one still wonders why anybody would consider
Thanks, Mark. I'm on vac today but will find out if all email is sent to
exchange (my guess is that it is because of prior problems with ecartis bounced
messages). Sendmail doesn't have a user or group. /etc/group shows smmsp::25:
I forgot where I found that information (to use 25)
I'll
Thanks, Grant. My email to the mailman list is taking a long time to get
through. Would you mind doing a reply all ? I'm on vacation and will work on
this next week. Needs to be up and running by the end of the year.
jeanne
You did not say, do you want your mailing lists to be in the
35 matches
Mail list logo
