Anti-Spam Working Group Minutes from RIPE 50

• content to the Chair of the working group.
  
• format to webmaster@ripe.net.

Anti-Spam Working Group - RIPE 50, Stockholm:
Friday 6 May, 2005, 09:00

Chair - Rodney Tillotson
Scribe - Emma Bretherick

A. Administrative Matters
Minutes of the last wg session can be found at:

http://www.ripe.net/ripe/wg/anti-spam/r49-minutes.html

Co-chair sends his apologies.

The agenda did not follow the published order. The priority item was discussion of a proposed update to ripe-206 (E1).

B. Update
B1 Developments in UBE

Bots and trojans

Rodney:
If I claim that it's all bots and trojans now does anyone agree with that?

Brian:
Well its certainly not all bots and trojans but it is a lot.

Rodney:
Absolutely and we have to take this very seriously because of the running together of different security threats. Blocking certain networks is also a serious issue and not all organisations block networks that they should. Does anyone know of the percentage of UBE which comes through bots and trojans (and so, in may cases, out through legitimate ISP relays)?

No response.

Does anyone know what to do about this?

Brian:
Authorised SMTP is at least a step in the right direction. Legitimate users will configure their mail programs to authenticate correctly, but bulk mailing software will usually be unable to do so.

Rodney:
I agree and this is probably something we should include in the BCP document we're going to look at under item E1.

B2 Developments in anti-spam

What do we think about Gmail?

Brian:
Bad, in that they do not write in the header crucial information required for traceability. In principle they have a novel chain of trust in which accounts are available by invitation and they know who released each invitation. Ultimately it depends whether they do what they say they will.

Rodney:
Any other issues? Black lists, any favourites?

Brian:
dnsbl.org

Rodney:
Asia Pacific Area Initiative, anyone know what's going on there?

John, APNIC:
There has been quite a lot of work done, but getting cooperation between all the different countries in the Asian regions will always be a problem. This is due to language and also because some countries are not action orientated! Australia is leading this but most countries are not doing much so not much has happened yet. Quite a few governments have signed up for this, which is a good sign, but so far that's it.

C. Technical Measures

Rodney:
Anyone know of different (new) tricks regarding filtering?

Brian:
Greylisting: when a message comes in the receiving server at first rejects it but not permanently. A genuine sending server will retry and its second attempt will normally be accepted. There are some issues with the resulting delays to messages.

Rodney:
Personally I feel that the bot writers will have found a way around this very soon.

D. Interactions

Kamran Khalid (during discussion of the BCP):
In regards to the abuse e-mail and notification, I remember there was going to be a new abuse attribute in the database objects?

Rodney gave a short update on the changes to the RIPE Database regarding the new abuse attribute.

Person:
I think it is not a good idea to add more contact details to the objects in the RIPE Database.

E. Advice
E1 Update to LINX BCP and ripe-206

How many people here have heard of ripe-206 or the LINX BCP?

Just three attendees put heir hands up, so Rodney gave some background information.

The LINX BCP has been updated and as ripe-206 was based on the original LINX BCP we should consider whether we want to update the RIPE document, and in what way.
Options include:
i, We accept the LINX doc as it is.
ii, We make some modifications for RIPE, eg change the references that are specific to the UK.
iii, We suggest improvements for the LINX BCP.

Rodney showed the attendees the RIPE Document and the LINX document. He has shown a suggestion of what the new RIPE Document might look like if it followed the new LINX text, with pink highlighting for additions to the existing RIPE Document, and yellow for modifications. Also some notes of possible changes to the document.

Person:
I think in many of the docs there is a lack of mechanisms for identifying anti-spam. There are difficulties in identifying if it is spam or advertising or bots. Even some anti-bots organizations are deleting some type of bots from their database as they are commercial adverts. There is no text about the origin of the complaints, there should be some text about what text needs to be included in a complaint about spam. About 30% of the messages I receive are not actually related to me, they are due to mistakes in whois or misleading links etc. It takes too long to explain to people what they have done that is wrong.

Rodney:
I believe the points made were about three things:
1, Identifying different types of spam.
2, Templates for what people should include in a complaint e-mail.
3, Ways of blocking.
I think all of them are out of scope for this document.

Person:
No I don't think so. Your doc splits the world into spammers and anti-spammers but it is not so clear. Sometimes anti-spammers can be more abusive than the spammers! There are no requirements for the anti-spam fighters anywhere and therefore they think they can behave anyway they like. They are not behaving in a best-practice way.

Brian from Heanet:
Blocking or not blocking. I don't think that has any place in this particular document, I think that comes under a much more general heading. This document is aimed towards suggestion to orgs what they should do to minimize e-mail abuse. Explaining to anti-spammers how they should react needs to be somewhere else.

Rodney:
You are basically saying that there are two parties and that this document is only focused towards one.

Person:
Yes.

Rodney:
I accept that and I agree that something may need to be done about it.

Second person:
I support 'person 1's conclusions. Can we then look toward creating a second document, so that we explain both how an ISP should behave and how anti-spammers should behave.

Rodney:
We will take note of this.

Action: on Rodney to move forward with this separate doc.

Person three:
You use normative language, eg MUST. Do you state what will happen if people do not do this?

Rodney:
No, this is not a legal document. Best Current Practice is to do what the document says, and keywords in it such as MUST and SHOULD identify which classes of behaviour are critical for conformance and which are not.

Rodney:
Which of the options regarding the LINX BCP should we take?

Brian:
I think option 3 is the best option, as long as it is not a continuous feedback loop.

Rodney:
I agree. I think that more could have been done with the update to the LINX BCP and we probably do need a better document to work on.

Brian Nesbit (HEAnet) offered to help with a new draft. We have enough people willing to work and comment on this so suggestions will be sent to the mailing list for further feedback.

Emma:
Regarding Rodney's point about the difficulty of the language in the LINX BCP for non-native English speakers, the RIPE NCC can 'Plain English' the new version of the RIPE doc.

X. AOB
None.

Y. Future Tasks
If anyone would like to do any tutorials just let us know!

Z. Agenda for RIPE 51
Standard form. Specific offers or requests by e-mail.