Re: spam from chinanet
* Marco d'Itri:
> On Sep 15, martin f krafft <madduck@debian.org> wrote:
>
>> Over the past 2 months, about 80 or 90% of the spam I received
>> through @d.o came from the networks of Chinanet. I have reported
> I agree that we need a way to filter spam sent to @debian.org and
> @packages.debian.org addresses, but I do not believe that local lists
> are the solution, because they would quickly become out of date.
Lists based on regular expressions for reverse lookup are quite stable
and not a big trouble to maintain, especially if your listing
criterion is not related to the spam amount.
I would recommend the following steps:
1. Find a team (two or three people are probably enough) that is
willing to maintain the blacklist.
2. Add a field to LDAP which developers can use to indicate if they
want the filter or not.
3. Decide which @debian.org addresses have to be exempt from
filtering (postmaster@, for example, and the address to report
filter issues).
4. Add a pseudo-package to the BTS to which filter change requests
can be submitted, and which is exempted from filtering.
5. Decide on the filtering algorithm. My proposal is:
a. Verify the HELO name, i.e. check that its forward lookup
matches the IP address.
b. If the HELO name is valid, it becomes the Originator Host
Name. Otherwise, the reverse lookup of the submitting IP
address is the Originator Host Name.
c. Lookup the Originator Host Name in the blacklist. Check if
the recipient is exempt from filtering.
d. If the Originator Host Name is not in the blacklist, accept
the message. If it is, but the recipient is not filtered,
record the blacklist check in the message header. Otherwise,
reject the message.
These steps would have to be performed for each RCPT TO: command
in the SMTP dialog.
6. Decide on a policy for the blacklists used in step 5:
a. What are the listing criteria?
b. Do we accept manual exclusions? If yes, in which cases?
c. Do we want to publish the lists?
My proposals:
a. We list everything that looks like an auto-generated host
name, unless the host names refer to a mail cluster.
b. Errors will be corrected, exclusions will not happen (but
see below).
c. Only DDs have access to the list. Debian should not enter
the RBL business because of the accompanying risk of DDoS
attacks. In addition, the algorithm of step 5 becomes
useless if it is universally used and spammers adapt their
tactics.
7. Implement the algorithm of step 5 in an Exim 4 ACL.
8. Wait until Exim 4 is availabe on all Debian MXes. (There's no
point in trying to do this with Exim 3.)
9. Devise a means to distribute the blacklist to all MXes (probably
using rsync).
10. Deploy it on all Debian MXes.
The proposed algorithm in step 5 and the listing policy in step 6 are
designed to stop spam which is submitted directly from dial-up/cable
mode/DSL hosts. However, if someone correctly uses his own domain
name in the HELO string, it is possible to avoid the filters. The
same is true if the ISP's smart host is used. This policy has the
important property that it is relatively transparent, and it's usually
quite clear if a blacklist entry is correct or not.
This doesn't do away with spam over webmailers (or other service
providers that don't handle abuse). Tracking those is certainly more
painful, but depending on the fraction of spam that comes over these
hosts, this could be defered to a second step.
Reply to: