[anti-spam-wg@localhost] Anti-spam WG draft minutes RIPE 45
- Date: Tue, 27 May 2003 14:29:18 +0100
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 RIPE database which should be easier
to maintain but is not routinely presented to whois users. Only six
IRT objects are in place; we do not know what fraction of addresses
or database objects they cover.
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: Sould we declare 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 may never have known '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 broadband 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 appears that no more than 200 bulk mailers are responsible
for sending 90% of all UBE (see http://spamhaus.org/rokso/).
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.
A flood of UBE may arrive from a wide range of IP addresses but
apparently from a single user account. In the same way it is not
possible without further research in specific cases to tell
whether it 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 participant 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-00.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
