Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 45

RIPE Meeting:

45

Working Group:

Anti-Spam

Status:

Final

Revision Number:

1

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

List archive

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:

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