RIPE 49

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

Anti-Spam Working Group minutes
RIPE 49 Manchester
Wednesday 22nd September 2004, 16:00 to 18:00.

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

A Administrative Matters

Thanks to our scribe.
51 participants.
A5 Co-chair Sabri Berisha was unable to attend and sends
his apologies.

The agenda is at (long URL split)
http://www.ripe.net/ripe/meetings/ripe-49/presentations/
ripe49-antispam-agenda.pdf
Three priority items were dealt with first, out of their
natural places in the agenda.


B1 Tutorial on message headers
Rodney Tillotson
(long URL split)
http://www.ripe.net/ripe/meetings/ripe-49/presentations/
ripe49-antispam-headers.pdf

Some discussion at various points:

Participants asked for a brief overview of SMTP, for which
there were no slides.

RFC2821 requires the HELO argument to contain an IP address
or fully-qualified domain name. Could we advise ISPs to reject
messages where the sending mailer does not present valid HELO?

Not in general; but there are considerations for and against:
* The standards explicitly forbid you to reject a message solely
because of a bad HELO.
* You SHOULD reject a transfer attempt that would result in
unauthorised relaying, but you cannot normally spot such
attempts at the HELO stage in the protocol.
* In many environments (a university was the example given) HELO
from end user systems and User Agent mail programs is the client
machine's view of its own name which is almost never a FQDN;
that is, these machines do not (and perhaps can not) use SMTP
properly. That doesn't matter within an administrative domain
such as a university or corporate network; it's a message
submission activity rather than standard transfer.
One participant reported that they are dropping single word HELO
in connections from outside their own network. Only one known
false positive, easily corrected, and many unwanted transfers
rejected.
* There are plenty of worse things to do with the SMTP protocol
than send misleading information in the HELO command.

Important distinction between protocol and policy:
* You are free to drop a transfer for any reason as long as you
document your policy for your customers or users and they agree.
We heard an anecdote about rejecting mail for failures to comply
with other aspects of standards (such as 8-bit values in the
header), which was eventually unacceptable to the customers
concerned.
* An interesting side-effect of such protocol policing is that it
forces the spammers to comply with protocol more effectively than
it improves the behaviour of otherwise legitimate parties such as
large content providers, whose incorrectly formed messages are
still valued by their recipients.
* Spammers adapt to new constraints very fast, possibly because
getting mail past restrictions is what they do all day.


D1 Abuse contacts and whois

For some months the Database WG has considered a variety of
ways to make RIPE whois a useful source of abuse contacts.
The requirement may have been lost in the possible technical
implementations.

This WG needs to send a clear set of requirements and an
indication of urgency to the Database WG, possibly suggesting
one or more concrete ways to implement changes but recognising
that that is a choice for the other group.

The agenda included outline requirements and listed the
technical implementations that had been proposed but from
which the Database WG had so far not been able to derive
consensus or a plan for action. The WG co-chair was in the
meeting and indicated that a clear request would be broadly
welcome.

The chair will summarise our requirements to the Database WG
broadly as suggested in the agenda
(note appended to these minutes).

Discussion raised the following issues:

* Altering the default whois output
Returning IRT details on its own will send even more changed
lines!
If some line in the defauilt output included the string "abuse"
it would help; it is conceivable that the other e-mail
addresses could then remain.
Even if we provide one e-mail address in the output that is
marked "abuse", some users will use all the other e-mail
addresses listed as well. It is then desirable to suppress most
e-mail addresses, and particularly those in "changed" lines,
though the most recent suggestion on the mailing list was to
only suppress addresses related to the maintainers.
A dedicated "whois.abuse" could return only one e-mail address,
and that the right one.
There is another class of users whose interface to the database
is some tool for partially automating spam complaints. Once the
desired e-mail address is present in the database it may be
possible for the writers of those tools to adapt their products
to extract it even if it is not directly included in the default
behaviour. We believe there are not very many of these tool
writers and it should not be hard to get the necessary
adaptations deployed.

* Use and possible modification of the IRT object
Part of the discussion is how to get the abuse address into the
database at all. The IRT object does many of the right things
(Rodney gave a short explanation of how it works).
The RIPE NCC have already agreed to ensure that the IRT object
is included in responses by default if it is present.
The authentication attribute for IRT objects will soon be
optional; at least one LIR feels that it could then be a
solution.
The name IRT does not automatically suggest an abuse resource
(compare the ARIN whois response when available).
We cannot at present force an LIR to use an IRT. We could make
an IRT link mandatory but this is not how it is currently.

* Maintenance effort
An abuse-mail entry in every inetnum sounds a daunting volume
of work for either LIRs or their customers.
Marco Hogewoning had found 10% of inetnum objects had text
in the remarks field indicating an abuse contact.
Some people who provide these remarks fields report that most
people do not read them; they simply select whatever e-mail
address or addresses they can find.
Suppressing inappropriate mail addresses would be very much
appreciated because (for instance) the MD would stop getting
abuse complaints and that will compensate some or all of the
effort in transition or ongoing maintenance.
Whatever technical solution is implemented, it may need to
include tools to help maintainers get it right.

* Nature of our consensus
Of the five basic components proposed to the mailing list,
a show of hands in the meeting indicated significant support
for a combination of IRT objects with some modifications,
and for changes to the default whois behaviour. Few people
were keen on other components.
The meeting then accepted with nobody disagreeing that we
should ask the Database WG to take action and should indicate
that we believe that that combination is one way forward.


E1 Update to LINX BCP and RIPE-206

The LINX BCP on UBE has been updated:
http://www.linx.net/noncore/bcp/ube-bcp-v2_0.html

RIPE-206
http://www.ripe.net/ripe/docs/spam.html
was based on the first version of the BCP and we should now
consider adopting an updated document incorporating similar
changes.

The issue had not been raised in the mailing list and
Malcolm Hutty (LINX) was able to bring out the key changes
for us:
* Good practice is described in respect of activities which
may be related to UBE; promotion of Web sites, use of third
party bulk mailing, distribution of bulk mailing tools.
* The description of good practice in accepting reports and
complaints about abuse is extended; it is not acceptable to
insist that reports use a Web form.
* The revised document points out that maintenance of the RIR
whois information is good practice.

Everyone at the WG session agreed to the following.
Rodney will send round:
* the URL for the new LINX document (see above),
* a note of the places where it differs from RIPE-206, and
* a draft for an updated RIPE document.
All are encouraged to comment in the mailing list in the hope
that consensus can be reached on the adoption of an updated
BCP and the witdrawal of RIPE-206. It may not be possible to
formally complete the process until the next RIPE meeting.


B Update

B1 Tutorial on reading mail headers, see above.

B2 Developments in UBE
Bots and trojans continue to be the dominant techniques.
The flow of UBE varies in detail from day to day but
overall it continues to increase.

B3 Developments in anti-spam
Spamhaus has recorded a notable success in persuading SAVVIS
to agree to business practices which discourage UBE.

http://www.theregister.co.uk/2004/09/09/savvis_spam_canned/

B4 Legislation
The OECD have an ongoing programme of workshops which are not
exclusively about legislation and regulation:
http://www.oecd.org/sti/spam

B5 Products
Nothing to comment on.

B6 Recent list discussion
Nothing to comment on.


C Technical measures

C1 Sender verification
The IETF MARID Working Group has produced several drafts:
http://www.ietf.org/ids.by.wg/marid.html
Their focus is on PRA and SPF working together
(Purported Responsible Address, Sender Policy Framework).
[note since the meeting, MARID has been closed down:
http://www.imc.org/ietf-mxcomp/mail-archive/msg04673.html]

C2 Filtering
Nothing to comment on.


D Interactions

D1 Database WG, described above.

D2 Other ISPs
LINX BCP Update described above.

D3 Bulk mailers
D4 RIRs
D5 ASRG
Nothing not commented on elsewhere.


E Advice

E1 Update to RIPE-206 described above.


X AOB
A TRANSITS course is arranged for Nov 2004;
this is about Incident Response activity and may be of
interest to those dealing with UBE:
http://www.ist-transits.org/events.php


Y Future tasks

Y1 WG direction
Very brief comment on the list in the agenda, urging people
to consider what might be priorities.


Z Agenda for RIPE 50
Broadly as before.
Volunteers and suggestions for agenda points are very welcome!