Re: [anti-spam-wg] BCP on limiting e-mail abuse

[Markus Stumpf maex-lists-spam-ripe-anti-spam@localhost]

On Tue, Oct 03, 2006 at 05:05:43PM +0100, Rodney Tillotson wrote:
> You may feel that the next revision
> is due already, in which case we can start preparing it at once!

I don't understand the intended goal of this draft. The title "BCP on
limiting e-mail abuse" suggests general information but reading it
I get the impression that it would be better titled "BCP for running an
ISP mailserver and how to handle abuse reports".

Sorry, if this sounds offensive, but I get the impression that the anti
spam practices adviced (at least 1-3) are outdated for at least 3-5 years.
Although I have no real numbers at hand I have the impression that more
than 95% of all spam is coming from
   a) abused broadband computers (botnets, viruses)
   b) abused webservers (php(BB), feedback scripts)
and neither of them passes mail systems at ISPs.
I haven't seen a relay open mailserver at an ISP for a rather long time
and this is even true for relay open mailserver (at least with our customers)
relaying through our mailservers.

A few comments on the document:

> Of course many products have entirely legitimate uses in handling
> mailing lists run on an opt-in basis and there is no question of
> preventing these products being promoted.

As Opt-In does not provide authentication in any way it is totally useless
with regard to authorization.
With simple Opt-In one cannot tell authentic requests from fake requests.
Extreme example:
running a script on one host that sends FORM submits with data from a
address list to a webserver transmitting user and email information is
Opted-In from the view of the webserver owner and so all addresses are
added "correctly".

And:
> The ISP may find that the customer claims that the email was in fact
> solicited. The ISP MUST NOT accept this claim unless the email address
> was obtained and processed "fairly and lawfully".

Simple Opt-In is not "Fairly and lawfully" does not prove demand by the
owner of the email address and so the message may still be unsolicited.

Trying to classify/ban bulk mailing software (think about the zillions
of Opt-In PHP newsletter scripts) on such a weak basis as Opt-In is
IMHO pretty useless if not ridiculous.

> The ISP MUST acknowledge the receipt of abuse reports ...

In order for abuse reports to reach the abuse address with high reliability
it is in most cases not appropriate for abuse addresses to be protected
by spam filters (including spam in a report often would give the abuse
report the same "spam level" as the original spam).
Sending out automated ACKs to each and every message to the abuse report
will harrass a *lot* of innocent users whose addresses have been
faked/abused and will also allow spammers to discredit that ISP (i.e. by
sending some 1000 messages to abuse@localhost with sender addresses of
abuse@localhost, abuse@localhost, ..., abuse@localhost
and repeat that process 20-50 times).
Misdirected bounces from spam and viruses are a big problem already and this
requirement forces ISPs to contribute to the problem.

> the ISP MUST document the appropriate abuse@ address within the
> Regional Registry information for each IP address block delegated to
> them.

Add some information/reference on how this is done?

> At present, registry entries can only record abuse mailbox details by
> means of comment fields, which inhibits automatic processing, but a
> formally specified system may be introduced in the future.

Still true?
I have lost track on the database discussion, but I still would prefer to
make RP records in DNS mandatory, anyway.
The DNS RR "RP" (Responsible Person) is there since October 1990 through
RFC 1183 and it provides a clear and documented way to add that kind of
information that is unique across the whole Internet and does not depend
on different (free format) records in some larger number of different whois
databases and "database referral" even comes included with the DNS protocol.
For examples see
    $ dig 30.195.in-addr.arpa rp
    $ dig 1.30.195.in-addr.arpa rp
or even (customer webserver)
    $ dig 1.249.30.195.in-addr.arpa rp

> ISPs are required to accept and process emailed reports of abuse by
> their customers.

Maybe its because I am no native english speaker, but I had to read this
sentence more than one time, as with the first reading I didn't get
the IMHO intended meaning of "reports about (potentionally) abusive customers"

> ISPs MUST keep other logs for a reasonable period so that they can
> ensure that they are able to translate a given dynamic IP address, in
> use at a given time, to a particular customer who can be held
> accountable for any abuse.

This may be in violation of national data protections laws. In Germany
ISPs may only keep logs of this kind of information for accounting
purposes. If the customer has e.g. a broadband flat rate there is no
reason for accounting (flat rate) and so the kind of logfiles may not be
written.
So I'd suggest to add "unless this is in violation of local data protection
laws".

> ISPs MUST ensure that they keep accurate time on their email systems.

IMHO this holds also for nearly every system at an ISP. Think of radius,
logging, ... this fact is implied in the next two sections, but in the
sentence above only mailservers are explicitly mentioned. 
It is also important (IMHO even more important) that all the systems at
the ISP are very closely sync'ed *among each other* (see the ISDN example
in the document).

> Many people cannot be bothered to report abuse, because they believe
> reports will not be effective. So an ISP cannot expect to see a large
> number of corroborating reports. Therefore just two reports which give
> identical messages MUST be considered to be evidence of bulk sending.

*lol* We have received UBE complaints for lists that are strictly Double
Opt-In and where the customer had no chance to cheat. The addresses of
the people complaining had sometimes been on the list for 4 years and
longer and each message sent via the list had - besides automated removal
via email/mailing list manager capabilities - clear and easy one-click
unsubscribe information via web.
This is a well known phenomenon.

	\Maex