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 ----- <redac...@t-online.de> (reason: 554 IP=XX.XX.XX.XX - A problem occurred. (Ask your postmaster for help or to contact t...@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 _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx
