...meanwhile I advanced to: policyd-1.9x-200708200636 and still have entries
like that in my blacklist_helo table.
....
| 222.253.21.103. | # blacklisted helo: (localhost) | 0 |
| 222.252.232.6.% | # blacklisted helo: (localhost) | 0 |
| 222.252.246.175 | # blacklisted helo: (localhost) | 0 |
....
I originally wanted to use the blacklist helo function, similar to that of
blacklisting a dnsname.
Perhaps the feature is not meant to be used like that, but this is what I
need to do right now.
What I expected was that wildcards my be used in all blacklisting tables.
After I did some monitoring I figured out, that most of my spammers
use generated helo fields which would be very simple to filter out by some
regular expression pattern.
When I read blacklist_helo.c I found that the sql-request
against the mysql database is different to the one in the other modules.
In this case equality is checked.
Original:
"SELECT COUNT(_helo) FROM blacklist_helo WHERE _helo='%s'",
triplet_array[fd][5]);
I changed this similar to the blacklist_dnsname query.
Change:
"SELECT COUNT(_helo) FROM blacklist_helo WHERE '%s' like _helo",
triplet_array[fd][5]);
So I can use a blacklist helo entry like that: 'mail%.spammer.de'
To filter out:
mail12.spammer.de
mail22.spammer.de
mail02.spammer.de
Because of the wildcards there may be more than one row returned,
so this check has to be changed, otherwise not blacklisting inserts are
made:
original:
/* we have forged helo attempt*/
if(mysql_optarray[fd][0] == 1)
changed:
/* we have forged helo attempt
* forged in this cas means illegal so blacklist if more than one
* so >=1 not == one */
if(mysql_optarray[fd][0] >= 1)
After I recompiled, I certainly had an increasing number of entries into the
blacklist table.
One of them showed me that there has to be something wrong with the inserts
which are
done by blacklist_helo.c .
'222.252.232.6.%' derieves from full IPV4 Adress + '%' for the blacklist
netblock parameter in policyd.conf.
When I change host_array[fd][2] into host_array[fd][3],
Original:
snprintf(mysqlquery_array[fd], 512,
"INSERT DELAYED INTO blacklist (_blacklist,_description,_expire)
VALUES ('%s','# blacklisted helo: (%s)',%d)",
host_array[fd][3], triplet_array[fd][5], expire);
Change:
snprintf(mysqlquery_array[fd], 512,
"INSERT DELAYED INTO blacklist (_blacklist,_description,_expire)
VALUES ('%s','# blacklisted helo: (%s)',%d)",
host_array[fd][3], triplet_array[fd][5], expire);
I do get the correct entry.
So I am guessing that the fields after the blacklist netblock decision have
been exchanged with each other.
Leaving BLACKLIST_NETBLOCK to default produces the correct blacklist
entries.
But setting this to on will produce the unexpected ones that I had.
Perhaps this might be useful for anybody out there.
viele Grüße, Tom Neubauer
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
policyd-users mailing list
policyd-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/policyd-users
