RIPE 39

RIPE Anti-spam working group, 2 May 2001 Bologna

A Administrative matters

A1 Scribe: Sabine Mader, RIPE NCC. Thanks to Sabine.
A2 List of participants: 22 people attended.
A3 Agenda agreed with the addition of A5 (see below).
A4 Minutes: circulated and on the RIPE Web pages.

A5 Other security areas

RIPE Chairman Rob Blokzijl introduced this topic.

Most of the working groups deal with security-related matters as
a side-effect of what they are doing.
Rob is concerned that RIPE does not waste effort by covering the
same things more than once, and does not leave gaps where security
is not properly addressed because no WG takes an overall view of
what is being done. The few people from each member organization
cannot attend all the WGs.

One obvious possibility is to start a new Security WG. Another is
to require all WGs (including this one) to take a wider view of
security.

*****
** We are asked to provide our suggestions before RIPE 40 so that
** that meeting can agree a way forward.
*****


B Update

B1 Recent list discussion:

A little followup on Spamwhack (http://www.spamwhack.com/).
Database of hashed information on spamming customers reported by
member ISPs; can include drivers licence, credit card, telephone
number. To use the data, member ISPs submit personal details (in
plain text) and SpamWhack returns a score indicating how nearly
the details match any reported spammer.
Details of the process by which a member ISP reports a spammer
are only available to members.

B2 Developments in spam:

Bigger spam runs often start on a Friday afternoon and may continue
through much of the weekend.
Messages more often include graphics
(but nasty pictures still usually require a click).
Messages often contain scripts hiding the URLs reached by clicking.
Since late in 2000, spam has been arriving from the Asia Pacific area
(Korea, Taiwan, China) but seems to be originated in the US
and to advertise to US consumers (prices in dollars, US phone numbers).
Since early in 2001, the eastern European countries (Romania, Russia)
have also been used for relaying and origination.
There is still much less UBE from the RIPE region than the rest of the
world.
UBE from some countries has political content.

New concealment tricks, making it harder to identify the source of UBE:
+ Add spurious 'Received:' lines to confuse the reader.
+ Long HELO can result in a 'Received:' line that is just 2 or 3 lines
of dots. This must be a bug in one or more products.
+ A lot more JavaScript in UBE. Typically it will disable some browser
features to make it hard to leave the page, and will crudely encode
the target URL.

B3 Developments in Anti-spam

Nearly all UBE comes from dial-up connections -- a little DSL.
Some is delivered directly, but most passes through open relays
-- machines that have not been set up securely.
(There are also dedicated bulk mailing facilities with better
connections.)

Major US dial-up ISPs (mainly UUNET and PSInet) have made it a bit
more difficult for bulk mailers to use their services.
Blocking of port 25 from dialups is becoming normal, though there
are still a lot of exceptions.
This is no doubt part of the reason for the move to other countries.

Some regions (eg RIPE) have relatively few open relays, but the bulk
mailers can find plenty elsewhere in the Internet.

There are still a lot of people working hard to spot patterns in
message headers and bodies which reliably indicate UBE, so that those
messages can be rejected by filters. This work is always a step
behind the tricks for concealment which the bulk mailers work equally
hard at.

MAPS DCC is a new product recently into beta testing; see
http://mail-abuse.org/vtf/dccbeta.html.
It should allow recipients to compare the hash of an incoming
message body with the DCC reference database, and so quickly identify
bulk mail. Users will pay for the service.

To identify and sue individuals is difficult for ISPs (in the
personal opinion of the WG Chair); but they can do it.
We should not give up complaining, otherwise bulk mailers see that
their practices work, and their ISPs can claim that bulk mailing
causes no difficulty.

There are some signs that organizations are finding excuses not to
worry about UBE any more, but to live with it. The present
generation of end users have never known e-mail without UBE, and
they regard it as normal to have to filter incoming mail.

We still choose not to offer advice about the use of ORBS.
[note since the meeting -- ORBS now no longer operates]

B4 Open relay products

Nothing new. Most products are now shipped with initial
configurations that implement some kind of anti-relaying.

Most systems abused for relaying are old sendmails or Exchange,
for which anti-relay configurations are readily available. Also
seen are Lotus products, which seem harder to correct.


C Advice

C1 opt-IN lists (work item)

LINX have a document awaiting the approval of LINX members which
describes good practice in the use of mailing lists. It should be
possible to circulate this document before long.
[note after the meeting: now available at
http://www.linx.net/noncore/bcp/mailinglistBCP.html ]

C2 opt-OUT lists

The above good practice advises against opt-OUT mailings.
It seems hard for some smaller companies to realise that sending out
two thousand e-mails for commercial purposes to addresses collected
from people who visited their website for some other purpose is an
abuse.

Again lots of new end users may regard this as normal; and we may
need to keep people aware of the difficulties with it.

C3 Reporting spam

Question from the WG Chair:
Who is reporting every piece of spam they see?

+ 1 attendee reports 95% of what he sees
(20-30 e-mails per day, using a script)
and gets about 10% response rate.
[note -- if the person who said this could make his scripts available
through the list it would be very helpful]
+ Some attendees have given up complaining;
+ Most end users read and delete.

What happens when you report abuse:

+ In the worst case the abuse address doesn't work and mail bounces.
+ Some service providers do not reply. It's hard to tell which of
them do anything about the abuse.
+ The usual initial reply is an automatic response, and from some
service providers that's all you ever hear. It usually promises to
investigate but not to give any feedback.
+ Some service providers include a ticket number in their reply.
You may be able to get more information by sending another message
that includes the ticket number.
+ Some operators send a follow-up message a few days later, stating
that they have taken some action.

Make sure to find out the right place to report to!
Often there is a long chain that you have to go back through.

Overall, the very low level of feedback makes it very hard to
reassure our own users.

End users should be encouraged to see that UBE reduces the value of
the service they get from their own ISP, so that it becomes an issue
between ISP and customer. If that ISP can then say to another that
"there are 3000 complaining customers behind me" it may have some
effect. The complaining ISP may need to escalate the handling of
some incidents.

Direct complaints by end users confirm to bulk mailers that "this is
a valid address", and can lead to further abuse.

The view was expressed that keeping the Internet free is a duty we
all share.
+ Laws offer almost no protection for the end user of a commercial
ISP;
+ Freedom and privacy may not be primary concerns of the management
of a commercial ISP.


D Technical measures

D1 Filtering

No new issues.


E Interaction with CERTs

E1 Reading mail headers (work item)

The WG Chair is gathering some material.


Y AOB

The WG Chair proposed that we increase cooperation between the RIPE
and APNIC regions, and start by making whatever contacts are
appropriate. The WG support this direction, and it was presented to
the plenary who also approved. APNIC staff welcome the approach;
Robert Winkler was present at the WG meeting.

Topics to explore might include:
+ Language issues. Most software, configuration guides and UBE
complaints are in English and it is not surprising that staff whose
native language is not English configure their mailers incorrectly
and do not read or respond to abuse reports.
(This also applies to some networks in Eastern Europe.)
+ Different views of the responsibilities of an ISP or network
operator.
+ The role of CSIRTs and the way UBE abuse is related to other forms
of network abuse.


Z Next meeting agenda

To be agreed on the mailing list as soon as possible.


Actions:
Suggestions for security work. All.
Circulate LINX paper on mailing lists. WG Chair. [done]
APNIC region contacts. WG Chair.
Agenda for RIPE 40. WG Chair and then all.

Please mail comments/suggestions on:

content to the Chair of the working group.

• format to webmaster@ripe.net.