RIPE 36

Date: 2000/5/17 14:00
Location: Mercure Room, Danubius Helia Hotel, Budapest
Chair: Rodney Tillotson, UKERNA
Scribe: Maldwyn Morris, RIPE NCC

1. Admin
1.1 Rodney opened the meeting.
1.2 Maldwyn Morris volunteered as scribe.
1.3 The agenda was agreed, with a few additions to the draft.


2. Update
2.1 Mailing list

The minutes of the last meeting are on the list.
There has not been much other recent discussion on the list.

2.2 Spam developments

ILOVEYOU
-- Was not spam.
-- May mean opt-out lists are vulnerable.
-- Not felt that marketers will use viruses for marketing.

Greeting card web sites
-- Seen abused for sending spam.
-- Even x 'cards' (= emails) per IP per day means a class C is
enough for a fair amount of spam.
-- Only seen used to advertise web sites so far.

demon.nl has seen more forged reply addreseses.

Tests of spam software seen!

2.3 Open relays

Evidence of spammers using ORBS information (ORBS scanning seen, then
relay attempts). This points to a serious leak from ORBS.

List of products that don't openly relay by default:
exim
sendmail 8.9+
eudora IMS
L-SMTP


3. Codes of Conduct
3.1 Status of BCP

Became RIPE 206, well received

3.2 Legislation

Keith Mitchell mentioned two new pieces of European Legislation --
Telecomms Data Protection and Distance Selling.

Data Protection legislation means opt-OUT for phone calls and opt-IN for
fax.

Distance Selling legislation means member states can choose their own
email laws.
Some member countries (UK, AT, SE) are going for opt-OUT. Apparently
Sweden has gone for opt-OUT but has no infrastructure to implement it!
Spammers will send from countries with no legislation, so harmonisation
needed.

3.3 Mailing Lists

MAPS documentation is useful (http://www.mail-abuse.org/rbl/manage.html).

Hard to find how to unsubscribe if the list software puts instructions
in a header line and delivery software removes or hides it. Instructions
in the message body should be OK.

RFC-822 means recipient headers will be changed by list software;
local receivers will be able to include all local recipients in
headers, but this answers a different question.

Different expectations of lists and of mail in general -- marketers,
users (who will move addresses and think it unimportant).

Chair is drafting a BCP -- will find what LINX have already done.

4. Technical Measures
4.1 ORBS
Discussed above.

4.2 Filtering Products and Services

Paying someone else to check your mail for spam, viruses, obscenities,
etc. e.g. MessageLabs.

5. Assistance to CERTs
5.1 Reading Mail Headers

Fighting Spam book not specially helpful, and no clear audience for
whom it might be useful. Formally you can only trust the last (local)
Received: line and the rest is guesswork, so not so simple.

5.2 Encouraging better responses to spam

Would like users to read headers so they can complain to right place.

Experience of .ac.uk shows many spurious abuse reports picking up,
for example, the use of innocent URLs in spam mails.

Need for more precise user tools.

Should users only complain to their own ISP?
-- expensive in staff at ISP;
-- abuse@ is for reporting abuse *from* the ISP's customers;
-- peering agreements could then permit ISPs to report problems
with each others users and handle problems with their own?


6. AOB

Swedish legislation as discussed above.


7. Next meeting agenda

Similar to this one, will be sent to the list.

Please mail comments/suggestions on:

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