[BlueOnyx:21411] Re: Solarspeed RBL blacklist

[Michael Stauber]

Hi all,

Maurice asked:
> Is there a policy when you release the addresses from the RBL?
> 
> Just curious because I run something familiar.

I had planned to release entries automatically after a given amount of
time, based on the "change_date" table row of the PDNS "records" table.
But then I noticed that the entries there are a bit arbitrary and don't
really reflect the date.

So I now do this:

Whenever the script/cronjob adds IPs for blacklisting into the RBL by
creating a new record in the PDNS MySQL table of my RBL-Zone, then it
also creates an entry in a separate MySQL table that's unrelated to PDNS
itself.

Into that it stores the ID of the blacklist entry in the PDNS table, the
offending IP-address, the header of the SPAM-email, the date of the
listing and that a delisting has not yet been requested by nobody.

Just getting the headers of one or more emails from a mailbox folder
that contain a certain IP is fairly simple in Perl.

Here is a rudimentary demonstrator that I had hacked together for it:

https://pastebin.com/XzLfzPaq

The $emailCache folder isn't the mailbox, that's one line below. The
cache is just something this Perl-script uses to speed up processing of
large mailboxes.

This needs the RPMs "perl-Mail-MboxParser" and "perl-List-Flatten"
installed, for which RPMs exist in the 5209R YUM repository.

Chris wrote:
> Of course, a lot of that could be handily remedied with a few
> webpages describing the list.  If it could include some automation
> (ie: lookup why your IP was listed, what the evidence is against it,
> petition for an automated or moderated de-listing) that would really
> make it a top-notch offering.  I've not (as of yet) been willing to
> make the investment in time that would require.

Yeah, I am not yet entirely there, but this is in the making. I set up a
really rudimentary webpage for this that explains the basics of the RBL.
What's still missing is the lookup and "petition for removal" forms.

The lookup itself is simple: The form will ask for the IP, the IP is
checked against the MySQL database and if it's found, we can also show
the header of the offending email (if we wanted to) and offer a petition
for a removal via yet another form. When I get the form generated email
it'll contain the header(s) of the offending SPAM(s) and whatever excuse
the person presents for the delisting-request. It can also directly have
a link to a PHP script that does the purge from the PDNS zone file and
also flags the separately stored header in the other MySQL database as
"delisted". It would sure be nice to also store the email of the person
that asked for the delisting and of course the date of the delisting.

That way we can also keep track if someone is a repeat offender who
already got delisted in the past and is now back with more SPAM from the
same IP.

To be honest: All in all I'm mildly surprised how little scripting
effort this all is.

What you said about the difficulty of finding where you are blacklisted?
Here is the catch: If an RBL is tied into SpamAssassin and its score is
set high enough to automatically cause a rejection at the MTA level,
then all the offender gets is the generic "SpamAssassin has rejected
this email as SPAM.". That's because other factors than just the RBL
might have contributed to that judgment. And it might not be wise to
tell an offender exactly which rules he triggered.

If the score is lower than the "reject at the MTA level", the SPAM will
get through, gets flagged as SPAM and the fact that the sender was
listed on the RBL gets shown to the recipient in the usual SpamAssassin
insert that makes it into header and (if classified as SPAM) into the
body. Of course: You could also tie the RBL directly into Sendmail, in
which case a precise reason and the URL of the RBL can be mentioned.

By the way: Even T-Online runs an arbitrary internal RBL that you have
to ask about to find out that you're listed. I just had it earlier this
week that a client couldn't send email to any <username>@t-online.de
account. All we could see in the maillog of the server was a generic
"dsn=5.0.0, stat=Service unavailable" from the T-Online MX-Servers upon
attempted email delivery.

The message my client got in the bounce of his email attempt was
slightly more descriptive:

  ----- The following addresses had permanent fatal errors -----
<redacted at t-online.de>
    (reason: 554 IP=XX.XX.XX.XX - A problem occurred. (Ask your
postmaster for help or to contact tosa at rx.t-online.de to clarify.) (BL))

The (BL) at the end was the only clue they were offering. But once asked
about it by email they were pretty quick on the case and informed us of
SPAM they had received from that server eight months ago. That's
actually where I got the idea from to store the headers. ;-)

But to be entirely honest: If it were just for my own benefit I wouldn't
mind to run the RBL vigilante style. My personal view is: A single
unsolicited offer for goods or services from someone I had no prior
contact with is sufficient reason for eternal blacklisting. But yeah,
it's not a perfect world as that garbage often comes from compromised
servers.

-- 
With best regards

Michael Stauber