RIPE 47

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

Anti-spam Working Group minutes (DRAFT)
RIPE 47 Amsterdam
Tuesday 27th January 2004, 16:00 to 17:30.

Chair: Rodney Tillotson, JANET-CERT
Scribe: Emma Bretherick, RIPE NCC

DRAFT minutes only; not yet approved by the WG.

A Administrivia

Thanks to our scribe.
41 participants.
Agenda agreed, with extensions from that recently sent to the list.
Minutes: no comments at the meeting, had been quoted on lists.
WG co-chair or alternative chair; offers of help always welcome.


B Update

B1 DNSBLs tutorial

DNSBL in practice; tutorial by Sabri Berisha, BIT BV.
(see slides at http://www.cluecentral.net/ripe47/)

In introducing the tutorial the Chair asked a few background
questions.

How many of the participants use one or more DNSBLs?
About half.

How many operate their own DNSBL?
None.

Are DNSBLs a way out of our present problems with spam?
Will we still need DNSBLs in 5 years time?
No opinions offered.

Some discussion followed the tutorial.

What proportion of the Internet should be able to transfer
mail directly (ie connect to destination SMTP port)?
(The questioner already blocks port 25 inbound for customers
unless they prove themselves clueful, and is tempted to block
outbound too).

A topic arousing violent passions.
For most consumers, blocking outbound connections to port 25
and forcing them to use an ISP server for outbound mail causes
them no inconvenience and protects the Internet against some
kinds of abuse if their computer is compromised (virus or worm,
insecure OS or applications including open relay and proxy).
Blocking inbound connections to port 25 (and most other ports)
causes such users no inconvenience either, and reduces their
exposure to some network attacks.
For competent customers wishing to operate their own mail
server, able to keep it in a secure state and willing to accept
the risks involved, an ISP might provide an unrestricted
connection.

Where a provider can apply only one regime, users for whom the
other one is more suitable are inconvenienced.

It was pointed out that the Exchange mail product is widely
deployed in customer businesses, but cannot use DNSBLs directly.
There is at least one third-party product claiming to modify
the behaviour of Exchange, though it seems not to be much
deployed; in some contexts it is appropriate to deploy a simple
relay for incoming mail using a DNSBL-capable MTA and hide the
Exchange system behind it.

B2 Recent list discussion

Main point is the discussion of a new abuse-c attribute, although
the main discussion was actually within the Database WG. The
discussion was trying to ensure that abuse complaints are
directed to the correct addresses. It was also discussed whether
the IRT object was filling this requirement or not.


B3 Developments in UBE

Bots and Trojans are here to stay.

Financial Services fraud (phishing) becoming very frequent; this
is mainly a content issue but has attracted the attention of the
banks etc.

A participant mentioned UBE in which a phone number is the only
contact. In general it is harder for individuals or ISPs to trace
the person or organization responsible from a phone number than
from a domain name. Providers are not willing to be identified,
let alone held responsible.
In the Netherlands anyone can buy a SIM card at places such as a
supermarket and there is no way the provider or anyone else can
trace misuse to the person responsible. This is no longer allowed
in the UK.

B4 Developments in anti-spam

ASRG update

Covered below at D5.

SpamCop

Rodney recently explained to the developer of SpamCop what the IRT
object was about and he agreed he could code it into the software
to achieve more accurate destinations for reports of e-mail abuse.
There are at present not many IP addresses with an associated IRT,
but if this or some other mechanism is widely adopted it should
not be hard to use the references in commonly available tools.
This will not reduce the other serious mistake that users of
reporting tools make, of reporting on the basis of _every_ IP
address or domain in the message header (which is easy) rather
than identifying the two or three which are principally involved
(a far harder task for humans or for automated tools).
of these type of objects in the DB.

Habeas

Habeas' original idea was to copyright a poem which licensed users
can insert into the header of the messages they send.
Message filters can then treat the Habeas mark as an indicator of
good practice at the origin of the message.
Habeas have recently engaged in some litigation to protect their
copyright from misuse by bulk mailers.

MSN

Microsoft are planning a range of anti-spam activities, mostly for
the benefit of their own customers:
Commercial service - measures will be applied to MSN rather than to
the free Hotmail service;
Filtering - already fairly effective in Hotmail;
Source block list - IP addresses are blacklisted but little detail
given as to why;
Recipient whitelist - this appears to be a large part of the
strategy in software products as well as services;
Challenge-response - for example supplying a picture to the sender
and asking what the picture is to ensure human involvement before
delivering the message;
Sender pays - recipients may accept certain messages on the basis
that the sender will pay them (money) for each one;
Litigation against bulk mail senders who do not conform to MS'
requirements.

A participant pointed out that the use of visual puzzles in
challenge-response would be attacked by senders of UBE.
Well-known challenge patterns will become ineffective and an
arms race will result.

AOL

AOL are protecting their own customers with a cryptographic tokens
they call DomainKeys, identifying participating senders even in the
presence of misleading indications in a message. They are also
trying SPF ("Sender Permitted From", one of the assurance of origin
techniques considered in the ASRG).


B5 Legislation

European Commission Directive now widely implemented:
Denmark recently managed to fine a spammer;
In Sweden (and several other countries) business addresses are
not protected.

US
CAN-SPAM is the first federal legislation. Not clear what its effect
will be inside the US or elsewhere; it appears that the marketing
industry is pleased, and it is possible that activities outside
the narrow range of things declared illegal will be treated as
acceptable practices.


B6 Products

Nothing new noted.


C Technical measures

C1 Sender verification

SPF, DMP, RMX etc; not discussed in detail though they are part
of ASRG activity.

C2 Sender pays

There are still people and groups keen to deploy schemes in which
senders must either pay real money to recipients or perform
a few seconds of cryptographic computation for each message to
be delivered. It is not clear how these work while UBE is sent
through unauthorised relays, proxies or zombie agent.

C3 Filtering

Still essential for most people.
SpamAssassin is popular and can be effective.
For abuse desks, filters must try to distinguish between UBE and
a report of UBE, which can be tricky.


D Interactions

D1 Marketers
D2 Other ISPs
D3 Bulk mailers
D4 RIRs
No significant changes.

D5 ASRG

A note on ASRG activity is enclosed at the end of these minutes.
We are grateful to the ASRG chairs for this summary.

D6 Other Working Groups

EOF
At the EOF the day before, Patrik Falstrom had given a
presentation identifying points in the paths of e-mail flow
where UBE might be controlled.
No conclusions or actions were reported to the WG.

Database WG

Common practice for end users troubled by UBE is to look in
the RIR databases for contacts associated with the IP addresses
they think are involved. They may also refer to domain name
registries.
It is recognised that in many cases a naive user is misguided
in trying to complain about every IP address they notice; but
the underlying feeling is reasonable, that use of an IP address
carries some responsibility and that it should be possible to
identify the party responsible and ask them to take some action
in respect of UBE.

The popular view is that the RIR databases accept an IP address
and return the mail address to which reports should be sent.
One approach would be to make this the default behaviour of some
freely accessible service which might not be the same as the
present databases.

We have raised this with the Database WG. Wilfried Woeber, chair
ow that WG, kindly set out some issues as he sees them.
The original goal for the database was to keep track of the
IP address space distribution. RIPE NCC has a responsibility to
keep this data accurate, secure, available and up-to-date.
There is also the routing registry, available to anyone to debug
routing problems or configure their routers. The RIPE NCC is not
responsible for the correctness or the completeness of this data.

Contact information for the holders of the resource or the
information in the database was needed. Originally this was an
administrative and a technical contact, to support the resolution
of issues among holders of address space or providers of routing
details.
In addition to those contacts, entries were later added to record
who changed or updated info (the changed: attribute), as an aid
to managing data quality.
All this is in support of the purposes for which RIPE NCC are
funded to operate and maintain the database.

An important issue is the extent to which database content or
behaviour should be modified to reflect the change of use and
the class of users not originally foreseen, who now generate the
majority of database requests but are quite unaware of the
historical purposes of the data they use. An alternative approach
is to design a different route through which such end users can
find what they need.


The question from this WG for the DB WG is whether we should press
for the inclusion of an abuse-c attribute/object, or for some
different facility. We note that a number of related activities
are in hand:
promotion of IRT links;
organisation object;
CRISP.

A participant suggested a new global registry or database that
handles the abuse contact information
(note that abuse.net is available for domains and behaves in this
way).

The DB includes the Routing Registry; could it not also include
an abuse registry?

(Niall O'Reilly commented)
Such a registry would have to ensure that people kept information
correct and up-to-date, and make sure that software used by users
to find abuse contacts uses this accurately. We have been unable
to get the people concerned to properly use the Database so far,
and there is no reason to suppose that inventing new data will
correct this problem, therefore I think we should use the existing
options and improve on them. Presentation Slides then given.

Another participant pointed out that what we are doing currently
is to overload the remarks field which is a poor starting point.
The users have solved a problem for themselves in a way that is
not ideal.

There was interest in a dedicated attribute (such as abuse-c).
Wilfried pointed out that as soon as you change the attributes of
an object, all software which reads an answer from the database
needs to be updated. It is more important first to work on the
definitions of abuse categories. This would solve the problem of
companies having to sort internally which departments each message
should be forwarded to.
He also hoped that participants in the Anti-spam WG could also
attend the DB WG.


E Advice

No changes.


Y Future tasks

Y1 WG direction

Raised the question whether the WG is doing the best it can.

Should the working group restrict itself to UBE or e-mail abuse,
or cover the whole of abuse activity?
No time for discussion on this occasion.


Z Agenda for RIPE 48

The same outline is proposed. Offers of tutorials are welcome,
as are suggestions for tutorial topics.

Wilfried Woeber commented that if someone comes up with a good idea
for a tutorial they should think about offering it within the EOF
to ensure it is not competing with another working group, especially
if it is training which could benefit others.
The chair will bear this in mind.


References
ASRG
http://asrg.sp.am/
Mail flows (presented at EOF)
http://www.ripe.net/ripe/meetings/ripe-47/mailflows.pdf


Summary of tutorial on DNSBLs
"DNSBL in practice"; Sabri Berisha, BIT BV.
(see slides at http://www.cluecentral.net/ripe47/)

DNS blacklists are DNS zones such as blacklists.org.tld
holding A and TXT records for domains or reversed IP addresses
such as
baddomain.net.blacklists.org.tld (for baddomain.net)
or
4.3.2.1.blacklists.org.tld (for 1.2.3.4).

IP addresses listed should return
an unroutable A record (typically 127.0.0.2) and
a TXT record with a diagnostic such as
"Listed for relaying, see http://www.blacklists.org.tld/".
127.0.0.2 and example.com are often included as test entries.

Any nameserver software will support DNSBL zones. It is
important to have adequate secodary nameservers.

Third-party DNSBLs should have respectable policies for
listing and removal, and should publish them.

Using DNSBLs is trivial in Sendmail; enable FEATURE dnsbl
and say where the zone is. In qmail a separate binary has to
be invoked in the wrapper script, again saying where the zone
is. Exim is also straightforward. You may wish to configure
response text to use with the 550 reply code when refusing a
connection.

Note that connections from listed addresses will be refused
very early in the transfer protocol. Messages to postmaster
will be blocked along with all the rest; this violates
RFC 2821 (among others) and such use is at your own risk.

In the tutorial, Sabri established a rudimentary DNSBL on
a bit.nl nameserver and demonstrated that it prevented the
presentation laptop from sending mail to a server using the
temporary DNSBL.


Summary report from the ASRG

In the past month, the ASRG has been seriously reshuffled. We
changed our charter to focus on more realistic approaches
rather than consent frameworks, created a new website and set
up new subgroups. We also changed our research agenda.

Our new research agenda and charter focuses on three main areas:
problem analysis,
improving existing solutions
and proposing new solutions.
We have also organized subgroups along the lines of this agenda
and are looking for feedback on both the research agenda and the
subgroups. Volunteers would be appreciated as well. The subgroups
are still being formed and will become operational in a few weeks.

We have the following:
o Analysis & Characterization (A&C)
- applies empirical and quantitative methods to problems and
issues surrounding spam.
o Abuse Reporting Standards
- researches standard formats and protocols for reporting email
and network abuse
o Best Current Practices (BCP)
- researches and documents best practices for spam management
o Filtering Standards (FILTERING)
- researches filtering standards for dynamic updating and
interaction with MTAs
o Inventory of Problems
- research problems with the current email architecture that
facilitate spam
o Message Verification (MSG-VERIFY)
- researches solutions dealing with verification and
authentication in the email messages and headers
o SMTP Session Verification (SMTP-VERIFY)
- researches solutions dealing with authentication and
verification of the SMTP session

There will also possibly be a BOF session being held at the next
IETF meeting in Seoul (1st week of March) on different proposals
that address domain forgery (LMAP, SPF, DMP, RMX, etc.).