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 :o)
"...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 :o)
... Mike
----- Original Message -----
From: "Thomas Mueller" <[EMAIL PROTECTED]
To: <[email protected]
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
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
