RIPE 45

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

Anti-spam Working Group Draft minutes

RIPE 45 Barcelona, Wednesday 14th May 2003

Chair: Rodney Tillotson, JANET-CERT
Scribe: Emma Bretherick, RIPE NCC

A. Administrivia
Thanks to our scribe.
37 participants.
Agenda as sent to the list (rather late).
Minutes: no comments. had been spotted on US anti-spam lists.
WG co-chair or alternative chair; offers of help always welcome.

B. Update

B1. Recent list discussion

No attendees admitted to reading the mailing list!
To subscribe, see http://www.ripe.net/mailman/listinfo/anti-spam-wg.
List archive at
http://www.ripe.net/ripe/mail-archives/anti-spam-wg/index.html.

Contact information in the Whois Database
(see also discussion in AOB).

Often the contact information is not useful for abuse handling. There
is an IRT object for the database but hardly in use. Also a problem
with all e-mail addresses in database objects being contacted with
complaints. Issue for the Database WG. RIPE NCC Database Operations
Team worried about Whois information being misused. Again, issue for
Database WG.

Are open relays a security problem?
Probably, but most security teams keep apart from abuse teams.

Bulk mailers making HTML content of their messages more difficult for
filters to catch and for individuals to pick out.

Discussion: Is all HTML mail bad anyway? Nobody at the meeting thought
it useful, and most UBE has HTML content.

The chair pointed out that HTML content is the default behaviour for
many current mail programs and _is_ considered useful by individuals
and corporations who never knew 'plain text' mail. Filter writers now
strip off some of the extra deception; but the bulk mailers will
adapt. If all HTML content is filtered or blocked the bulk mailers
will change to something else.

Effectiveness of MAPS and other DNSBLs.

The MAPS RBL+ is highly respected but blocks less bulk mail than many
other DNS Block Lists and you have to pay to use it:
http://mail-abuse.org/.

SBL (Spamhaus Block List) is also of very high quality and identifies
more IP addresses associated with bulk mail abuse:
http://spamhaus.org/sbl/.

Opinions differ on the quality and effectiveness of other DNSBLs.
Most will block a lot of UBE but their policies and their robustness
may make them less suitable for ISP use.

EU legislation.
Directive 2002/58/EC is the main provision and is at
http://register.consilium.eu.int/pdf/en/02/st03/03636en2.pdf
(Google may find faster mirrors or copies).

B2. Developments in UBE

UBE volume is greatly increased; for some destinations it has doubled
in the last 3 months. Some ISPs felt the load from incoming UBE would
become a serious technical problem for their mail systems by the end
of 2003.

Open relays are no longer the bulk mailers' primary route. Open
proxies are still widely used (and leave no trace of the starting
point of the bulk mail).

The growth of consumer (and SME) connections that are always on, with
significant bandwidth and in many cases a poor level of host and
network security has led to new ways of working. Bulk mailers install
unauthorised SMTP senders as trojans following a user action such as
clicking on some URL, as the payload of some worm, or as part of a
privilege compromise. The senders may have a hard-wired single-shot
bulk mail to send or they may have a control channel (IRC client or
listener on some chosen port) so that they can be used repeatedly for
one bulk mailing after another until the insecure network or host is
cleaned up. The IRC control method in particular is similar to that
used in botnets used for packet DDoS attacks.

Although these techniques are fairly sophisticated, some of the bulk
mailers using them have no great technical ability. Bulk mailing tools
are getting better and most users are simply downloading them and
using them. These users do not understand that spam is a bad thing
(perhaps their ISPs have not told them). They are more naive than
bad. But the bandwidth of their connections is enough to make them
dangerous. Sending bulk mail has become a consumer activity as well
as one for the full-time or technically competent operator.

It is often stated that no more than 200 bulk mailers are responsible
for sending 95% of all UBE. People questioned this because UBE now
reaches them from an ever-increasing region of IP address space; it is
not clear whether the owners of the addresses used are themselves
senders of bulk mail, or are running insecure networks and so allowing
others (possibly from the hard core) to use their IP addresses. In
the same way it is not possible without further research in specific
cases to tell whether a flood of UBE apparently from a single user
account or mail address but arriving from a wide range of IP addresses
is being routed through a botnet, a pool of open proxies or some other
mechanism.

Some ISPs and users feel able to block /8s representing whole
geographical areas (usually Asia Pacific or South America) because all
their mail connections from those netblocks seem to carry UBE, with no
wanted mail. For many in Europe and the US, this is at present likely
to be true; but it is an undesirable partitioning of the Internet and
leaves those regions with less incentive to correct the behaviour of
their users.

B3. Developments in anti-spam

Nobody at the meeting had attended the Anti-Spam Research Group of the
Internet Research Task Force.

Rodney Tillotson had, however, tried to follow the vast flow of mail
on the ASRG list and had identified some threads which are listed at
the end of these minutes, with some URLs for further reading.

Solutions and research areas proposed so far are of four broad types:

* challenge-response protocols;
* DNS extensions for reverse or sender MX verification;
* electronic postage stamps;
* electronic approval marks.

A WG member kindly pointed out that the Earthlink scheme for
challenge-response is described in:
http://www.washingtonpost.com/wp-dyn/articles/A22390-2003May6.html

B4. Legislation

Australian National Office for the Information Economy (NOIE) have
prepared an interesting report and proposals.
PDF, available through:
http://www.govonline.gov.au/publications/NOIE/spam/final_report/index.htm

B5. US litigation

AOL, MSN and Yahoo! are jointly suing one or more full-time bulk
mailers.

A curious coalition including some well-known bulk mailers appears to
have laid a case against an equally curious combination of anti-spam
organizations and individuals including Habeas, SPEWS and Spamhaus.
See: http://www.spamhaus.org/legal/answer-03-80295.html

B6. Products

No specific issues at present.

C. Technical Measures

C1. Filtering

Bayesian filters are in routine use (SpamAssassin, SpamBayes) and the
increasing obfuscation noted in B1 above is probably the response by
the bulk mailers.

D. Interactions

Not discussed at this meeting.

D1. Marketers
D2. Other ISPs
D3. Bulk Mailers
D4. RIRs
D5. ASRG

E. Advice

E1. Update RIPE-206
Add guidance for services supporting UBE; advertised URLs,
nameservers etc.
E2. opt-IN lists
LINX BCP may be suitable:
http://www.linx.net/noncore/bcp/mailinglist-bcp.html
E3. Reporting UBE
Standard format for reports;
may be included in the Survival Guide (see AOB).

No work on any of these at the meeting.

X. AOB

X1. Whois contact information
(see also B1 above).
ARIN and the Address Council ask two questions:

a) Should there be a mandatory abuse contact in the whois
database?
b) If ARIN find outdated information in the whois database
should they flag it?

Abuse contact
Points made included:

If you make it mandatory to provide abuse contact info, people will
probably just use bogus information and therefore there will be
further incorrect data in the DB.

Need to consider how best to record an abuse contact in the database:

introduce a dedicated attribute in the object (most intuitive way,
would immediately be visible to whois users);
add abuse details in the remarks field (most common workaround at
present);
use the IRT object or something with similar structure (single point
maintenance for all objects with the same contact).

Need to consider what objects should have an abuse contact:
IP address - abuse contact
(thought by the meeting to be the most common lookup);
domain - abuse contact
(may seem more appropriate to some other group).

Need to consider the likely use of abuse information. The meeting
heard the view that having abuse reports more easily generated is not
necessarily a useful thing overall; user UBE reporting machinery often
complains to innocent parties, and it is perhaps better if users can
only report things that they really care about. This is rather a
defensive attitude; users must be able to complain to someone and at
present most ISPs are not interested in handling complaints from their
users about another ISP's customer.

Flag for out-of-date contact information

The flag would be provided so that users could use it to easily
blacklist address space that is not up-to-date. The interest in this
has come from certain providers. It began with a discussion regarding
taking address space away from ISPs which do not have working contact
information and went from that extreme to simply flagging the objects
concerned. The flag would be added by ARIN and the pwner of the
flagged object would not be able to remove it directly. ARIN would
clear the flag after correspondence to re-establish contact and agree
future arrangements.

Both questions are probably things on which we should offer advice to
the Database WG.

X2. Assured Path Messaging

Rodney to send to WG list an outline of his bright idea for Assured
Path Messaging; there was not time to present this properly at the
meeting.

Z. Agenda for RIPE 46

The same outline.

With UBE continuing to increase there are numerous operators taking
desperate measures to combat the problem. We should make best practice
advice on defensive measures (a 'Survival Guide') and make a
presentation at the next RIPE Meeting.

ASRG threads

Main ASRG page at http://www.irtf.org/asrg/
Official list of current work at
http://www.elan.net/~william/asrg/index.htm

* Requirements
o Dave Crocker ID
https://www1.ietf.org/internet-drafts/draft-crocker-spam-techconsider-01.txt
* Challenge-response
o Turing test for authorisation
o Earthlink
* Whois
o Identity of advertisers
* RMX
* DS
http://www.ietf.org/internet-drafts/draft-fecyk-dsprotocol-02.txt
* Crypto-based
o Tripoli
o Hashcash and stamps
o TEOS
http://www.eprivacygroup.com/teos
* DNSBLs
* Filters
o Content filtering
* New headers
o Use of ADV:
* Legislation
o Bulk mailers sued; MSN-AOL-Yahoo
o Suit against SPEWS etc
* Definitions of spam
o Keith Moore's taxonomy at
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01100.html
* Mailing lists
o Opt-IN and opt-OUT
o Expression of consent
* Proposals from bulk mailers
o OMPUAC
http://ompuac.org/paper.html
o Lumos (ESPC)
http://www.networkadvertising.org/espc/press.asp
* Certified senders
o Originator
o Server (MTA)
+ Ken Hirsch plan
+ SMTP over SSL
* New mail protocols
o Comparison with NNTP