Seem to be getting this a lot on f...@here - spam comes from ffml-owner,
but that address is not subscribed, so it bounces, and bombards six people
with rejected spam. Is there a more elegant way to deal with this than add
subscriber to a 'summarily discard all' rule?
-Dennis
On Sun, Jan 31, 2010 at 10:59:13AM -0800, Dennis Carr wrote:
Seem to be getting this a lot on f...@here - spam comes from ffml-owner,
but that address is not subscribed, so it bounces, and bombards six people
with rejected spam. Is there a more elegant way to deal with this than add
Dennis Carr wrote:
Seem to be getting this a lot on f...@here - spam comes from ffml-owner,
but that address is not subscribed, so it bounces, and bombards six people
with rejected spam. Is there a more elegant way to deal with this than add
subscriber to a 'summarily discard all' rule?
Lindsay Haisley writes:
On Sat, 2008-12-20 at 19:35 +0900, Stephen J. Turnbull wrote:
Courier doesn't need milters. Maildrop can be run in what's called
embedded mode which is effectively the same thing.
x`
No, it's not the same, not for the purpose of deciding whether
On Mon, 2008-12-22 at 11:25 +0900, Stephen J. Turnbull wrote:
Lindsay Haisley writes:
On Sat, 2008-12-20 at 19:35 +0900, Stephen J. Turnbull wrote:
Courier doesn't need milters. Maildrop can be run in what's called
embedded mode which is effectively the same thing.
x`
No,
Lindsay Haisley writes:
Courier doesn't need milters. Maildrop can be run in what's called
embedded mode which is effectively the same thing.
No, it's not the same, not for the purpose of deciding whether
*Courier* needs milters. *You* don't need milters because you don't
mind eating the
On Sat, 2008-12-20 at 19:35 +0900, Stephen J. Turnbull wrote:
Courier doesn't need milters. Maildrop can be run in what's called
embedded mode which is effectively the same thing.
x`
No, it's not the same, not for the purpose of deciding whether
*Courier* needs milters.
A milter is just
on 12/20/08 10:41 AM, Lindsay Haisley said:
A milter is just an MTA component/plugin that reflects user-space
(outside the MTA) decisions on spam/viruses back to the SMTP dialog so
that a receiving server can reject an email for cause without generating
a backscatter email to the envelope
On Sat, 2008-12-20 at 13:13 -0600, Brad Knowles wrote:
Unfortunately, milters are not widely supported outside of modern
versions of sendmail and postfix.
Courier's maildrop implements a perl-like structured scripting language
that's about as flexible as anything I'm aware of for this purpose.
on 12/20/08 1:54 PM, Lindsay Haisley said:
Well I'm probably not doing as effective a job of pre-filtering as you
are at UT.
And what we're doing for python.org and ntp.org can't match those
numbers, either.
For ntp.org, we do pretty much the same as you -- use a few RBLs
up-front, and
On Sat, 2008-12-20 at 14:24 -0600, Brad Knowles wrote:
I'd also
like to make sure that SpamAssassin is set up to run interactively.
What do you mean by this. Can shell account users not interactively use
spamc or spamassassin from a command prompt?
--
Lindsay Haisley | The difference
on 12/20/08 2:35 PM, Lindsay Haisley said:
What do you mean by this. Can shell account users not interactively use
spamc or spamassassin from a command prompt?
By interactive, I mean that SpamAssassin (or SpamBayes) would be
executed before we give the sender a 250 Ok for the message. That
On Sat, 2008-12-20 at 17:55 -0600, Brad Knowles wrote:
By interactive, I mean that SpamAssassin (or SpamBayes) would be
executed before we give the sender a 250 Ok for the message. That
would allow us to reject stuff that gets a high spam score instead of
dropping it.
Oh, Ok. Thanks. I
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
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?
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
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
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
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
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 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
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
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.
Only subscribers are allowed to post and non-subscriber post attempts are
silently discarded, which allows me to
33 matches
Mail list logo
