RIPE 46

Anti-spam Working Group minutes
RIPE 46 Amsterdam, Tuesday 2nd September 2003

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


A Administrivia

Thanks to our scribe.
38 participants.
Agenda agreed as 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
particularly from people unlike the present chair:
non-old? non-UK? non-male?


B Update

B1 Recent List Discussion

GIEIS
This was an idea promoted with great vigour by one individual but
it gained no support on this list; nor on the ASRG list after that.

'Do Not Mail' List
Not a new idea, though tempting by analogy with postal opt-out
lists in some countries.
Weaknesses are well-known; central point of failure, various
attacks if lists are washed centrally and returned for
sending. Expensive to manage the trusted third party who will
operate the list, expensive to maintain the list.

B2 Developments in UBE

Proxies are no longer novel. Routine process is for the bulker
to find in advance a collection of proxies and exploit many in
parallel.

Bots (also Trojans, Worms and Viruses)
All these are additional software running on a victim machine;
the distinctions are rather arbitrary and are mostly to do with
the way the software gets on to the machine to start with.
Bots are traditionally controlled through IRC channels. Other
control technologies include scheduled outbound connections to
the attacker's server to fetch new tasks (phoning home); in this
case the task might be a message, an address list and perhaps
a list of proxies to use. The phoning home may be in response to
a wakeup call if the victim network allows incoming calls. A
single UDP packet is enough.

Until recently, bots were used for all sorts of mischief except
bulk mail, but it was always possible that the substantial
resources under the control of attackers would become available
to bulk mailers. There are now some indirect indications that
this is happening; one person at the WG reports as follows:

> By examining mails stuck in our queue we can see the spams
> that are trickling through the system. We sort them to identify
> a small number of originating IP addresses. We are beginning to
> see more hosts on the list which cannot be shown to be open
> relays or proxies so we can only assume it is through bots.

Malware known to be used for bulk mailing includes Jeem and
wthunk32.dll; and no doubt others.

This is a substantial loss of control and potentially very
worrying; people wondered what defence there might be against
it. As usual, keeping Windows and anti-virus up to date is the
simplest thing to stop it becoming more widespread. Once the
bulk mail is launched, it is no different from any other; the
same filters and blocks will have the same effect.

An interesting comment on Windows patching, not specific to UBE.
Windows Update only works for legal copies of Windows. Apparently
China and other Asian countries have a very high proportion of
counterfeit copies installed, which will never be patched. That
region will inevitably be the target for many further compromises.

Viruses (viri?)
As well as potentially carrying a bulk mail payload as above,
recent viruses including Sobig.F have generated a lot of mail
traffic with false but plausible originator. The public and the
Press do not see much difference between messages generated by
viruses whose purpose is to spread the virus, and bulk mail
which usually has some sort of content; they look much the same
in the Inbox, they both apply the same sort of social engineering
to get people to read them, and both are unwanted.
See also the related problem with MailScanner (B5 below).

We have to think seriously about this. It will become very
difficult to resist or campaign against UBE if it is made to
appear that viruses are a worse problem. There is no indication
that Sobig.F was launched to confuse consumers in this way, but
another virus might do just that. It is also possible that a
virus which is run-time extensible like this one could run a
bulk mail task.

[Not mentioned during the meeting]
Bulk mailers are currently exploiting mailers which use SMTP AUTH
but with weak passwords. They use them just like open relays.
It is unfortunate that SMTP AUTH used properly is a mechanism
for improving e-mail security, but that it has in these cases
reduced it through poor configuration and use.

Address Harvesting
Presentation by Sabri Berisha, accessible through the RIPE 46
meeting pages or at:
http://www.cluecentral.net/ripe46/
For the research a few addresses created specially for the
experiment in a new domain were planted in various places. The
paper summarised how much and in what ways each address came to
be abused for UBE.

Some questions followed.
Categories of UBE were arbitrary and were chosen to fit the UBE
after it had come in.
There was no attempt to devise an algorithm to put the messages
into their categories.
There may have been some overlap between sources of harvested
messages, although separate addresses were planted in the
different places.
Originating AS number determined partly from the message header
and partly from the source of the incoming mail connection.
So it could indicate a box that is compromised in that AS,
rather than one whose owner is deliberately sending UBE.
It would be interesting to compare the ASNs for a sample of
legitimate received mail as well. It would look particularly
bad if an AS which scored high for UBE also scored low for
good mail.
None of these questions will be followed up; the research was
a one-off exercise as part of a study programme.

For comparison, a study by the Centre for Democracy and Technology
recorded how long it took for mail addresses to _stop_ being used.
On the whole, surprisingly quickly.
http://www.cdt.org/speech/spam/030319spamreport.shtml

B3 Developments in anti-spam

There have been very heavy traffic attacks on DNS Block Lists.
Osirusoft (and the SPEWS mirror hosted there) is completely shut
down and no longer offers any blocking support. For a short time
a positive answer was returned for every query; every address was
treated as listed and mailers using these DNSBLs accepted no mail
at all.
The nameservers were withdrawn because the DoS attacks were of so
much traffic that they were no longer providing a usable service.
[note after the meeting: the widely respected SBL (Spamhaus) is
often under pressure but has just had a very determined attack]

APCAUCE has started up in the Asia Pacific region, following the
model of CAUCE (Coalition Against UCE) in the US. Good people are
involved.

B4 Legislation

Italy have implemented the EU directives with something that seems
to cover all bulk mail abuse leaving very few loopholes; opt-IN
is clearly required.
Opt-IN is not mandated in Sweden.
In the Netherlands opt-IN is specified but there will be no one
enforcing it!
In Russia legislation is also in place but unfortunately it was
prepared by politicians without consulting technicians.
Irish legislation is on the way. Oddly, it protects an ISP's
customers from being spammed but not customers of a business.

Habeas is an organization which stamps mail so that you can trust
it. It adds lines in the message header which form the text of a
haiku that is a copyright work, licensed only to Habeas customers
who have undertaken to follow best practice in bulk and other
mailing. Any bulk mailer writing this text so as to evade checking
cane be prosecuted under copyright legislation, provided they can
be identified and are in a suitable jurisdiction.
Habeas have recently succeeded in a case; nobody could provide
exact details.
They have also been through an internal shake-up. Outcome not
yet clear.

B5 Products

MailScanner scans the contents of messages once they have been
accepted, typically by passing them to a proprietary anti-virus
engine or to SpamAssassin. It can then annotate incoming messages
('this looks like UBE'; 'an attached virus was removed') and this
is very useful for UBE; the local recipient can make their own
choice to filter it, complain etc. Unfortunately it is often
configured to send warnings for viruses received, and for some
current mail viruses this results in unwanted messages to the
forged sender. Note that there is a feature to prevent this
behaviour, but it requires occasional updating which users have
not all done.

As with the virus messages themselves, end users easily confuse
this with bulk mail. The confusion is heightened by the inclusion
of a header line by the Sobig.F virus which names MailScanner and
gives the impression that it is in some way responsible. The ISP
hosting the MailScanner site has received dire threats about its
spamming behaviour ...


C Technical measures

C1 Filtering

No comments.

C2 camram

Presentation by Rodney on behalf of Eric Johansson, accessible
through the RIPE 46 Web site.
General information at http://www.camram.org
This is a Sender Pays system. Participating recipients accept
without challenge messages including a cryptographic token unique
to each message which is designed to be easy to verify but hard
to generate. Messages not stamped can be dealt with in various
ways, some of which involve return to an originator address which
may have been false.
There are other broadly similar schemes but the author believes
that camram is fairly fully worked through. It is perhaps not
clear how a balance of cryptographic power in favour of recipients
can be maintained as processor power increases; and there is a
question about the process of widespread deployment.


D Interactions

D2 Bulk mailers

Innocent organizations are tricked into using mailing lists from
bulk mailers as they believe claims that the addresses are
appropriate, obtained legitimately etc. It will sometimes be
necessary to complain to them or their ISPs.

D4 RIRs

It would be good to bring in reports from the other RIRs.

D5 ASRG

Presentation by Rodney on behalf of Paul Judge, ASRG chair,
accessible through the RIPE 46 Web pages.
See also http://www.irtf.org/asrg

This was an overview of the ASRG's work areas and progress.
A key concept for them is 'consent-based messaging'. One of the
WG pointed out that that sounds similar to instant messaging
where you can choose how people send you messages.
There is an interesting ecosystem slide hinting at relationships
between several classes of participant. We were surprised to see
no arrows from Govt to ISP, and spammers not mentioned at all! -
but it may be that the image was meant as a framework and not for
detailed interpretation.

D6 Database WG

Generally the wrong e-mail address obtained from the RIPE database
is used for complaints of abuse. People look at the information in
the database, see a contact person and then think that this person
is responsible for spam, hacking, pornographic content etc.
There is a serious lack of user awareness with regard to the
results obtained. In many cases multiple addresses are used, some
within the ripe.net domain; they are chosen apparently because they
are easy to find.

The Database WG are broadly aware of the problem and are working
on features which they believe are relevant:
the IRT object could be very useful if the object can be made to
appear by default and if (for instance) SpamCop will start to
derive contact details from it;
an Organisation object is currently under discussion which could
be another good place to list an abuse contact.
The Database WG could also consider changing the default behaviour
of whois in the light of its importance to naive users, perhaps
suppressing misleading mail addresses or inserting the most
appropriate contact available.

This is an area which we need to raise with the Database WG.
[note from the Chair after the meeting: I have brought it to
their attention and they ask that we present our concerns and
suggestions for consideration. We will generate a proposal on
the mailing list.]

An ISP representative at the meeting asked:

> How do you fund dealing with the complaints that are sent
> through any contacts given in the database?
> How do you persuade management to pay to deal with this?

Some discussion; agreed that where short-term costs are critical
abuse processing is seen as a luxurious overhead offering no
competitive benefit. Similar attitudes apply when customers
report to their own ISP abuse they are receiving from another
network. The WG may have to find the right question to put to
a management specialist.

There is a very deep technical divide here. Often offended end
users don't just not understand the RIPE Database but also don't
understand what their personal firewall is telling them, what a
log is, what information they need etc. Unfortunately there is
nobody to tell them; unless it's this WG?


X AOB

No comments at this point. Later, a WG member asked:

> I have seen a lot of spam through tertiary MX records. I do not
> understand how spammers use MX records.

Some discussion followed in private after the meeting. Broadly,
bulk mailers have noticed that defences against UBE are often
implemented on the main MX destination and overlooked on the
rest. For instance, it is easy to think that a lower preference
mail receiver can accept all mail and forward it to the main
mailer which can make the right decisions. Unfortunately the
main mailer may be configured to accept all mail from internal
systems and to regard the alternative MX as such a system. All
the checks are bypassed.
A countermeasure sometimes thought helpful is to add a further MX
record of lower priority than any real one, which points back to
the same mailer as the preferred MX. This is, of course, only one
more step in an arms race; in general, alternative MX systems
should have security configuration to match the main mailer,
though they may be of smaller capacity. It is even questionable
whether you should operate an alternative MX destination for an
end-point mail system; it will be necessary for large user
communities and for transit mailers, but for others the cost and
complexity may be more than the expected benefit.


Y Future tasks

We need to think about what the group is doing and how we
should progress or develop; all WGs will be doing the same and
the next RIPE meeting will take an overall view.
This is something Rodney will bring up on the mailing list.


Z Agenda for RIPE 47

Please come forward with any comments and suggestions. The same
outline as the RIPE 46 agenda may well be suitable but probably
needs some specific items.
Suggestions for any tutorials that would be useful, subjects that
we should cover etc, either to the list or to Rodney at
R.Tillotson@localhost.

Tutorial suggestions on the spot (or off the cuff):
how to use a DNSBL;
how to operate their own DNSBL;
tracing e-mails;
contract issues, (largely covered in RIPE-206);
rejecting mail early.
Experts willing to present such tutorials will be particularly
welcome :-)