213.214.98.20 is no longer listed in bl.spamcop.net !!!
Hey Thomas:
>>"You can have both too: SpamAssassin and
blacklisting" really says it like
>>it is.
Sounds like you have the tiger by the tail and a custom
solution to meet
your needs. Exim4. Nice. And you won't likely be junking
mail on RBL false
positives which is a big issue to overcome if these RBLs are
to be useful.
If you have no qualms about threaded PERL on an SMP unit,
embedded
SpamAssassin module flies. SpamAssassin can also be
accelerated
substantially by using spamc/spamd and running your own
local RBL or
RBL-mirror you can save 50-100ms per item.
Hey Jesse:
>>Pros and cons of before-queue content filtering
A thoughtful and novel sidebar introducing the old
'pre-queue mail filter'
argument to the RBL issue. Perhaps we will see all the
major-mail-leagues
scrambling to do SMTP connection screening on a
"Postage-Paid" criteria
(i.e.: Yahoo, AOL announce email 'postage' fee).
Thomas is referring to Exim4 while I referred to
Sendmail/Mimedefang each
used where limited but important criteria for rejecting mail
with a
permanent failure code is applied on initial SMTP
connection. You discuss
Postfix. Cool. I see several ways where Postfix does
inexpensive content
early (header and body checks), which, as only one example,
can be a method
to prevent many virus attachments entering the system just
by reading
headers. Anyway, some folks say Ford, some say Honda and
some say something
else is the best car. Same with MTAs. Whatever you like best
>> "...drive your system into the ground..."
I don't go along with the Armageddon theory of old. The
state-of-the-art is
mult-threaded-processing at near light speed. Form can now
follow function.
In the real world, the stakeholders freak if they don't have
some SPAM
filtering done for users and in many groups' cases they want
at least a few
SPAM quasi-controls on their WebMail. In all major regimes,
increasing
pre-queue accept/reject decisions is the wave of the future.
Users will go
to whomever understands and can supply the required
resources.
>> spamassassin chokes up delivery
Sounds very abnornal - maybe an overly aggressive filter set
(configuration)
for the available resources. See perldoc
Mail::SpamAssassin::Conf Things
like the SoBig traffic spike and other spikes have caused
filter overload
conditions for SA and for other filters but that is rare and
a valid time to
throttle traffic anyway.
Any way, folks. We are off the bl at SpamCop and it is good
to stay off
... Mike
----- Original Message -----
From: "Thomas Mueller" <news-exp-dec05 tmueller.com
To: <dbmaildbmail.org
Sent: Thursday, February 09, 2006 3:44 AM
Subject: [Dbmail] Re: dbmail list server on spamcop,
messages blocked
M. J. [Mike] OBrien schrieb am 08.02.2006 12:03:
Any methodology which passes mail through SpamAssassin for
the purpose
of 'Realtime Blackhole List' matching *after the MTA has
accepted* the
message is a defacto 'GREYlisting' process.
[..]
If you want a BLACKlist process, the immediate rejection of
UCE is the
most desirable action on a trusted RBL/DNSBL/URIDNSBL (RBL)
positive
match. The ideal place to do the reject-on-RBL-match is at
the initial
MTA SMTP connection -- reject the mail with a permanent
failure code
(5** response) in the first SMTP transaction.
You can have both too: SpamAssassin and blacklisting. Exim4
can pass the
mail to SA while keeping the SMTP connection open.
That way I can decide based on several BLs and further
tests if I want
to reject or accept the message.
My user can even decide on their own if mail is ever
rejected, and if
yes how many SA points are required. Works very well.
Thomas
_______________________________________________
Dbmail mailing list
Dbmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
|