[anti-spam-wg] RIPE 51 anti-spam WG minutes

  • To: RIPE anti-spam WG <
    >
  • From: Rodney Tillotson <
    >
  • Date: Wed, 07 Dec 2005 16:16:44 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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), R.Tillotson@localhost
Scribe: Shane Kerr (RIPE NCC), shane@localhost

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 Fãltstrõm 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 Fãltstrõm: It does stuff to ensure 7-bit encoding. Compare
PGP normalisation.

Rodney Tillotson: Is this going to fly or not?

Patrik Fãltstrõm: 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.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBQ5cK0cxy/J7PAuvpEQIpfgCfVWfKLUfGnP+WmaNQ9pDQjau4KR0AoPBq
mvvzVTqqKj/mw803Z/Eo28gh
=tTV0
-----END PGP SIGNATURE-----