Hmmm. I worry just a little about the precepts of this thread. I suggest you
can count on the fingers of one hand the number of RBLs good enough for
widespread use to truly regulate the acceptance of email. But, for example,
if an IP is listed with xbl.spamhaus.org, which tracks verified spammers,
spam gangs and spam services of about 150 criminal gangs and individuals, I
don't even want that connection, never mind mail traffic. That's a BLACKlist
There may be two or three others you can trust. Then there's as many as
another hundred RBLs out of which ten might be good GREYlists (for fear of
too many false positives) but not a criteria for regulating the acceptance
of mail.
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. SpamAssassin by default adds a score of
2 on a match. If you only want grey listing, use SpamAssassin's URIDNSBL
filter later in the mail delivery chain after the MTA accepts the message.
Whitelist your most trusted sender domains, just in case.
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 still use a white list in the MTA.
Generally MTA's handle RBL lookups with more flexibility than does
SpamAssassin. Nevertheless, SpamAssassin integrated into the MTA with a
Milter ( like MIMEDefang (Sendmail) ) is a good implementation to exploit
SpamAssassin's many features and Plugins including URIDNSBL because this
integrated method allows instant reject-on-match. (
http://wiki.apache.org/spamassassin/IntegratedInMta ).
If you do your RBL lookups after the MTA has accepted the message, you will
be compelled to deliver somewhere, store, or destroy the UCE . Unless you do
an SPF / Domain Key check on the message sender at this point (after the MTA
has accepted the message), *you must not bounce the message* or you have
configured a system to SPAM new victims. Conceivably, if your system
received 120 spoofed-sender SPAMs-per-user a day, with just 1000 users your
system could become an aggressive rogue sending 120,000 UCEs and or
virus/worm-laden mails daily. Yikes. DBMail postmasters are the best tribe
of mail people on the planet and don't make mistakes like that, eh. :o)
(Note: 'Bouncing' not to be confused with 'redirect with headers'
http://wiki.apache.org/spamassassin/ResendingMailWithHeaders. )
Currently the IP [213.214.98.20] is *only* on the SpamCop RBL.Hopefully it
drops off in a day or so. I like Paul's suggestion, not using SpamCop as an
RBL. I see SpamCop more as a GREY list --- but other people swear by
SpamCop and it is indeed a valid and well-maintained and widely acknowledged
RBL if not brutally strict. For the latter folks who favour SpamCop, using
Postfix as an MTA, I offer a suggestion to allow you to both use SpamCop for
DNSBL lookups and still get your DBMail.org list mail even while SpamCop
believes [213.214.98.20] to be a little SPAM-Meister :o).
Add the following to /etc/postfix/main.cf as a smtpd_recipient_restrictions
*before* your RBLs
"check_sender_access hash:/etc/postfix/whitelist"
where whitelist is a hash made from running the postmap command against a
whitelist file (i.e.: "postmap /etc/postfix/whitelist" )
# my Postfix whitelist file containing domains
# I want to receive mail from
# come hell or high water
@dbmail.org OK
@myotherLIST-servers.org OK
EXAMPLE:
smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination,
check_sender_access hash:/etc/postfix/whitelist
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client xbl.spamhaus.org
OR if you are already using DbMailAdministrator's (http://dbma.ca ) MTA
feature configured as per the instructions, all you need to do is add
"@dbmail.org" as the domain and "OK" as the 'action' using the the MTA
Access window. (See
http://dbma.ca/demo/dbmailadministrator/DBMA_help.htm#use_DBMA_MTA_Domains)
It is generally difficult to keep *any* list server out of RBLs from time to
time because some members' MTAs are occasionally misconfigured and do
misdirected bounces; or someone on the list is testing a run-amok
autoresponder. ( http://www.spamcop.net/fom-serve/cache/329.html )
best...
Mike
----- Original Message -----
From: "Jesse Norell" <[EMAIL PROTECTED]
To: "DBMail mailinglist" <[email protected]
Sent: Tuesday, February 07, 2006 7:11 PM
Subject: Re: [Dbmail] dbmail list server on spamcop, messages blocked
On Tue, 2006-02-07 at 16:04 -0700, Jesse Norell wrote:
Or rather, use it more intelligently.
Sorry, that was probably worded poorly. I meant that Spamassassin can
do make more intelligent use of the rbl match than your mta which can
only outright reject the message. That was not at all meant as an
insult or anything of the sort.
Eg. use spamcop to check that
And this ^^^^^^^ should have read spamassassin, not spamcop.
Jesse
rbl, so it increases your spam count, not completely rejecting the
message at the mta.
[
On Tue, 2006-02-07 at 23:03 +0100, Paul J Stevens wrote:
So don't use spamcop <duck>
Gregory S. Youngblood wrote:
I'm in the process of implementing new spam protections on my server.
I noticed that messages that appear to be from the dbmail.org list are
being bounced.
reject: RCPT from elnino.fastxs.net[213.214.98.20]: 554 Service
unavailable; Client host [213.214.98.20] blocked using bl.spamcop.net;
Blocked - see http://www.spamcop.net/bl.shtml?213.214.98.20
Thanks,
Greg
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
--
Jesse Norell - [EMAIL PROTECTED]
Kentec Communications, Inc.
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
