RIPE 44

Please mail comments/suggestions on:

• content to the Chair of the working group.
• format to [email protected].

Anti-spam WG RIPE 44 Amsterdam

Anti-spam WG RIPE 44 Amsterdam
28th January 2003 14:00

Chair Rodney Tillotson
Scribe Emma Bretherick RIPE NCC
27 participants

The meeting was held at the same time as Routing and DNS WGs.
A few people had had to choose between attending this WG and one
of the others. At the next meeting in Barcelona the grouping of
WG meetings will be different.


A5. Alternative WG chair.

If anyone is interested in becoming chair or co-chair for this
group please let Rodney know, he will not be offended!


B1. Recent list discussion.

B1.1 Laws about bulk mail

The issue had come up of legal requirements, such as what bulk mail
practices are acceptable and what the penalties are for doing
unacceptable things. The RIPE community would like to know what
laws apply in Europe and its member countries, and possibly in other
regions.
This WG should be able to collect together or summarise the laws.
http://www.spamlaws.com/ is one place to start.

Legislation does not directly reduce UBE. Its main value to an ISP
is that it adds weight to Conditions of Service or Acceptable Use
Policies; direct enforcement of the policy will still be a task for
the ISP.

Legislation can also help where there is a commercial conflict of
interests. If an ISP has business customers who wish to send bulk
mail and who are financially important to the ISP, it is difficult to
withdraw their service and lose them to a competitor. Linking the
withdrawal of service to a legal requirement which applies to
all ISPs (at least, all in the same country) may reduce the
competitive penalty for doing the right thing.

RIPE can help to set the direction for legislation, so that it
takes account of the expectations of the industry. At present the
clearest consensus is RIPE-206.

The European model requires opt-IN. However, it permits "soft opt-in"
which means that if you have ever bought a product from an
organisation, they can send you a single unsolicited e-mail inviting
you to opt IN.
The Telecoms Privacy Directive, which features the soft opt-in option,
has a deadline of 31st October by which all European countries must
have local legislation putting it into effect.

We do not know whether partner businesses can each send their own
single invitation, nor whether they have to state what their
relationship to the individual is within the e-mail.

B1.2 Responsibility for customer misbehaviour

A UK operator asked who is responsible when a customer ignores
instructions and deliberately sends UBE, or when a customer's
network is insecure because of open relays or proxies and the
customer fails to make it secure.

It is possible that a case could be made against such a customer.
Provided the contract with them is clear enough, the threat of
commercial action by their service provider is likely to be more
effective than court action.
The ISP may be prosecuted or receive complaints because they can be
traced, whereas the individual that actually sent the bulk mail
cannot.

The WG charter was written some time ago and has not been recently
updated.


B2. Update on UBE

B2.1 A new trick by a bulk mailer

Presentation by Sabri Berisha [email protected]
Slides can be found at: http://www.cluecentral.net/ripe44/

The abuse is to do with an advertised Web site rather than the bulk
mail itself. The bulk mailer managed to move advertised material to
Sabri's network.

Depends on finding in the victim network an open proxy and a
misconfigured Web cache.
1. Content available on bulker's site; URL resolves to
bulker's IP.
No bulk mail sent at this stage.
2. Bulker uses open proxy to enter the victim network
and pull content to the victim's Web cache.
3. Bulker changes A record so that the URL resolves to
the victim cache.
4. Bulker sends mail run.
May need refreshing from time to time.

To avoid this:
a. No open proxies.
b. Configure cacheflow not to answer external requests.
(You should do these anyway).

Recipients complain to the victim. Have seen this trick being used
for child pornography etc and legally this is a very difficult scenario.
If the police knock on your door it would be impossible to explain.

It was suggested that DNSSEC might have helped; not in this case
as only the attacker's own nameserver is involved.

B2.2 Regional distribution of UBE sources

Most UBE is now sent through insecure proxies and its real origin
is untraceable; but we briefly discussed where the proxies are.
Mostly Asia and South America. We do not see much UBE originating
within Europe, although Russia is often the host of any child
pornography advertised in the mail.

B2.3 RIPE database scraping

We are having some problems with e-mail addresses within the RIPE
database being copied to UBE recipient lists; people often ask
what RIPE can do to prevent this. The whois server imposes limits
on bulk database queries which make it harder to automatically
extract the complete collection, but no individual address is
protected. Organizations and people supplying addresses to RIPE
NCC for inclusion in the database know that its purpose is to make
the addresses publicly available. Perhaps we should advise users
to supply role addresses whenever possible, or at least addresses
different from the ones they use for personal correspondence.

In cases where addresses such as [email protected] receive UBE,
they may have been taken from the database and misused but there
are other explanations. The short local part "lir" will easily be
reached in a dictionary attack in which every combination of
three letters is added to the list, or the bulk mailers may be
aware that "lir" is a local part valid in lots of domains and
worth trying.

B2.4 Broadband connections

As the number of broadband customers increases the number of
problems increases. There are now more insecure proxies etc,
always on and with considerable bandwidth. ISPs should offer their
domestic and SME customers advice on security (use a NAT firewall,
disable all services you don't need) and elementary system
management (update anti-virus and OS patches daily); ISPs might
consider packet filtering within their own network as standard
for customers, although some customers will need to have such
filters disabled.

B2.5 Collateral spam

We heard reports about the denial of service which occurs when a
bulk mail run falsely uses your domain in its originator addresses
(MAIL FROM: and From:). Your mailers get all the bounces, and all
the complaints. There is no clear picture; one report was that the
number of messages using any one domain is now thousands rather than
hundreds of thousands (though many domains may be affected), but
another was of a very large attack. In the case of a large attack
the source will often be hosted by a major carrier and if while the
attack is still in progress you can report it by phone they may be
willing to take serious action against their customer.


B3. Content issues

UBE is not primarily a content issue, but certain content attracts
great public interest and responses which are not carefully
considered.

Cases of UBE with pornographic content need taking seriously. In
most countries there is an agency to which you can and should
report UBE likely to contain paedophile material. In the UK, child
protection campaigners regularly state that ISPs should be
responsible for banning pornographic spam; this is dangerous
because it is impracticable and it suggests that other UBE is
acceptable.


B4. Developments in anti-spam

B4.1 Brightmail

It appears that Hotmail has purchased the Brightmail service for
paying customers, but it seems not to be available to users of the
free Hotmail service.

B4.2 DNS Blacklists

There are now hundreds of DNSBLs, some with very odd policies for
adding and removing addresses.
MAPS is still there, does not block much e-mail though.
SBL is well thought of.
ORDB fairly popular.
Use others with caution. You probably don't want rfc-ignorant.


B5. Products

Now more problems with proxy products (squid, Apache, Proxy Server,
Border Manager) than mailer products still used as open relays.


C1. Bayesian filtering

Bayesian filtering is a statistical approach where you give a way
of describing a message and listing things that you do not want.
It adapts to your individual preferences and can be very accurate
on a personal basis. The new version of SpamAssassin has this.

In the bulk mail arms race this will help some recipients for a
little while. The more advanced bulk mailers will soon use it in
reverse, to adjust their messages until they defeat Bayesian
filtering; though they will never be entirely successful.

People at the WG seemed interested to know more about the technique,
and Rodney will try to find someone to talk about it at RIPE 45.

C2. Other filtering developments

There is something called SpamNet. It includes a plugin for Outlook
which enables you to mark a mail as spam and send its signature to a
central database. If ten people submit the same signature it will be
blocked by everyone else using the plugin. Clearly it would be easy
to abuse this free service.
http://www.cloudmark.com/products/spamnet/

MacAfee have bought the Windows version of SpamAssassin that will
may also help Outlook users.

Courier is a free product that is very good and very simple - but
even with simple products there are ways you can get your mail in
a mess.

Most filtering products accept messages before processing them
(unlike DNSBL blocking which rejects connections at a very early
stage). One person at the WG has developed software that transfers
the message header and body, but delays acknowledging the transfer
until it has passed the data to software (SpamAssassin in this case)
which checks whether it is bulk mail. The software then returns a
positive or negative acknowledgment depending on the check result.
Although unwanted messages are still transmitted across the network,
they are not written to disk or processed for delivery and a
performance benefit should result. It is working very well.


D3. ISP suppression of prohibited mail

A question from a backbone provider which operates over satellite,
connecting customers in Africa and the Middle East. They would like
to sniff outbound messages en-route in their own network before they
are transmitted, to enable them to suppress 419 fraud and other UBE
at source. None of these countries have privacy laws to restrict such
checking.
They would like some advice on how to go about this.

It should be possible to transparently redirect all outgoing SMTP
connections through a mail relay which checks each message.
Transparent Web proxies work in a similar way; it may be necessary
to install one of those and to configure it to examine each Web
connection it forwards. As with all technology there is an arms race
effect; the bad guys will find other ports and protocols as fast as
you can reconfigure your firewall.

Intrusion Detection Systems might be another class of products
capable of adaptation to call SpamAssassin or something similar, and
check each message.

Others at the WG pointed out that they have an AUP which forces
customers to take responsibility for their use of the network, and
not to push responsibility up the tree towards the ISP. Such an AUP
is in place in this case but it is not enough.

It was useful to hear a first-hand account of work with cybercafe
operators in Nigeria to counter the 419 fraud messages. The
cybercafe operators are in most cases also very keen to stamp it out
but they have not the resources to monitor everything.
Some customers have been persuaded to block outgoing SMTP connections
but for some this is an important part of their business and the ISP
is not able to block it. There may be other security measures that
can be applied in the cybercafes.

A court case for fraud by bulk e-mail is in progress at the moment
in Nigeria.

We discussed the difficulty of explaining to higher management that
customers need to be shut down if they are contributing to mail abuse
in any way, either sending it themselves or leaving themselves open
for other people to send it through them. Possible loss of revenue
may be an important issue at that level and it is important to point
out the potential cost of failing to take action - which means you
have to have some idea what that cost might be.


E1. Update RIPE-206

Please have a look at this document; it is something that this WG
adapted from a LINX BCP and it now needs to be updated to cover proxy
abuse, hosting websites that are advertised through UBE etc.
http://www.ripe.net/ripe/docs/spam.html

E2. Adopt LINX opt-IN BCP

Please look at this one too. It would be useful to make any changes
necessary and present it for acceptance as a RIPE document.
http://www.linx.net/noncore/bcp/mailinglist-bcp.html

E3. UBE report format

Too many different report formats through different services such as
SpamCop; and some are hard for an abuse desk to process. Ideally we
would propose something that will support some degree of automation
in generating reports and in processing them (or at least
pre-processing them) on receipt. IODEF and IDMEF are XML formats
likely to come into use in the Incident Response community, and it
might be possible to build on that work.


Y. Assured Path Messaging (presentation by Rodney)

An early outline of a proposal for a mail service to run alongside
current Internet mail, with bilateral links between participating
providers and a default deny policy. Some people will regard it as
whitelisting taken to its extreme. It needs a clear statement of
practices that are not acceptable (including any leakage of non-APM
messages into the service) and will involve APM exchanges to keep
down the number of separate links and manage the necessary trust
relationships.

Responses and comments included the following:

There are considerable startup issues. Although it is important to
involve large players early on, it will be necessary to start with
existing communities of smaller size.

There are also costs to all parties. Further work will have to
include an analysis of costs and benefits acceptable to commercial
organizations of all scales.

The idea of e-mail exchanges and excluding an ISP that we don't all
agree with is appealing. It gives us an opportunity to make our own
structure as an alternative to legislation, which the governments
across the world will not do in the near future. A danger is that
any effective structure will be condemned as a restrictive practice
(of course, the whole idea is to restrict some of the commercial
activities of some bulk mailers).

We might have to seek sponsors through universities, governments
etc.

Possibly a good idea to get some software vendors involved in this
as the availability of good configurations for all widely deployed
products is important.

Rodney will write this up and make it available.


Z. Agenda for RIPE 45

Include presentations on:
Update to WG charter;
Legislation;
Bayesian Filtering;
Assured Path Messaging.

Include updates on:
ISP filtering outgoing mail.

Possibly consider:
Bandwidth filtering (rate limiting, possibly variable).

[Note: offers to do any of these in Barcelona will be welcome]