Skip to main content

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

RIPE 51

RIPE Meeting:

51

Working Group:

Anti-Spam

Status:

Final

Revision Number:

1

RIPE 51
Amsterdam, the Netherlands
Anti-spam WG
Wednesday, 12 October 2005

Draft minutes. Comments welcome on the list or privately.

Chair: Rodney Tillotson (JANET-CERT)
Scribe: Shane Kerr (RIPE NCC)

A. Administrative matters
B. Update
C. Technical measures
D. Interactions
E. Advice
X. AOB
Y. Future tasks
Z. Agenda for RIPE 52

A. Administrative matters
No comments about previous minutes.
Co-chair Sabri Berisha unable to attend this time.

Priority item
E1 Update to RIPE-206,
BCP for ISPs on behaviour to manage e-mail abuse

1) Is there anything to do at all?

RIPE-206 was based on version 1 of the LINX BCP and there is now an
update, version 2. We should consider updating RIPE-206. As a basis
for discussion, Rodney Tillotson has edited the new LINX text in the
same way as version 1 was adapted to become RIPE-206, with the changes
from version 1 marked.

(long URL on two lines)
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/
ripe51-second_draft_update_ripe206.html

The easiest thing for the WG to agree is to adopt version 2 with no
further changes. Alternatively we might add some material to reflect
changes in the UBE environment in the last year, or even write a
different document.

At the last WG meeting the consensus seemed to be for some additions
but not a full rewrite.

Malcolm Hutty, LINX: think this is a good idea, encourage changes.
Adopted in August 2004, but not aware of changes since then that make
it out of date.

Brian Nisbet: Additions rather than rewriting is better option. Would
be willing to do some or all of that work.

2) Words about educating end users

Sander Steffan: What should be done is to educate customers. At least
make them understand why you are making so much trouble over e-mail
messages.

Rodney Tillotson: Compare the way Microsoft have reduced the message
about Windows security for end users to three lines.

Brian Swenson, Microsoft: we strongly advise people to turn on
automatic updates, because a lot of spam originates from bots.

Brian Nisbet: Not sure if a 3 line short form is of use in discussing
a document like this. So many vectors for spam, this document is aimed
at more technical people.

Niall O'Reilly: May be worth adding a paragraph, "what to tell your
users/customers/students".

Andrew Cormack: There is a FAQ for users about spam on UKERNA web site
which is free for non-commercial users.
http://www.ja.net/services/publications/factsheets/054-junkmail.pdf

Mention of a short video from GOVCERT.NL, also with a three-point
security and awareness plan for consumers (presented at the end).
Appealing to techies, impact on real consumers not yet known.

3) Words about active testing of customer systems

Andrew Cormack: Is active probing of customer machines acceptable or
desirable? JANET has a service to check for relays. Discussion in UK
when it is going to become best practice for this.

Rodney Tillotson: Don't think this is a bad idea, but worried about
how you would say that. Point we ought to consider.

Heinrich Hauser: Just a victim of spam - a user, not an ISP. Find it
very interesting, but missing the motivation from the ISP side. The
guys who could stop it - the ISPs - can make money more easily by
selling anti-spam products and services.

Rodney Tillotson: Not necessarily a commercial conflict of interest.
One of the aims of the BCP is to give ISPs some confidence that their
competitors will not take bad but profitable business.

Brian Nisbet: While we are a non-commercial ISP, a lot of commercial
ISPs offer anti-spam solutions free. Large parts of the commercial
anti-spam industry have this conflict of interest, not just ISPs.


B. Update

Raza Rizvi: Greylisting is temporary rejection of mail to a mail
server, which then will be re-tried after a certain period. It is
believed that proper SMTP service will retry but spambots don't. A
tuple is kept of the sender's name and IP address and the recipient's
name and this is used to check the second attempt.

Peter Koch: Does anybody beside me believe this is a really bad thing
(handy though it can be)?

Lars-Johan Linman: Too strong a word.

Peter Koch: Greylisting is pushing the problem towards the
infrastructure. If I have a high-volume mail server, lots of mail does
not get delivered on time and puts burden on the sender side.

(Rodney Tillotson: Mail should not be regarded as "real time".)

Brian Nisbet: We should expect greylisting to be slowly implemented,
so is this really a burden on the infrastructure? Interested if
anyone has numbers to confirm or deny that. In the long run it is
also a relief on infrastructure because we have less spam.

Peter Koch: Not worried if it works, but if it causes harm. Not
optimistic regarding reduction of spam. All attempts at "protocol
education" have seen spammers react faster than legitimate operators.

Brian Nisbet: While greylisting does remove some spam, it has a high
false-positive rate if large misconfigured mail systems do not re-try
after transient reject. Interactions between timeout periods can
introduce delays of two hours or more, which are perceived as
unnecessary.

Rodney Tillotson: How many are keen on greylisting? (some hands)


C. Technical measures

DKIM Domain Keys Identified Mail
http://mipassoc.org/dkim/

Patrik Faltstrom gave a presentation on DKIM status and technology.
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/dkim.pdf

Lars-Johan Linman: You talked about normalisation? What about agents
that modify transfer content encoding?

Patrik Faltstrom: It does stuff to ensure 7-bit encoding. Compare
PGP normalisation.

Rodney Tillotson: Is this going to fly or not?

Patrik Faltstrom: No, I think it is going to work! At Cisco they
notice that about 10% of messages are signed. There are a number of
DKIM-aware tools: Sun Mail, Yahoo!, Cisco, SpamAssassin.

Brian Nisbet: Other technologies also being developed. CSV, Certified
Server Validation (was Client SMTP Validation). Driven by Tony Finch
(U. of Cambridge): http://mipassoc.org/csv/


X. AOB

Andrew Cormack: NL educational video is at
http://www.waarschuwingsdienst.nl/movies/botnetfilm_en.wmv (13Mb)
http://www.waarschuwingsdienst.nl/movies/botnetfilm_en.mpg (103Mb)
Can be customised to various languages and places.
The video was shown.


Z. Agenda for RIPE 52

Similar outline to this one.

Action Points:

* Rodney Tillotson - submit LINX BCP as a revised RIPE-206 using the
PDP.

Highlights:

* The document on which RIPE-206 is based has been updated, and
RIPE-206 will be revised.

* Greylisting discussion showed some consider it harmful, and some use
it.

* DKIM is an up-and-coming authentication technique.