[anti-spam-wg@ripe.net] Draft minutes RIPE 48

["Rodney Tillotson" <]

more mins.txt
Anti-Spam Working Group draft minutes
RIPE 48 Amsterdam
Tuesday 4th May 2004, 16:00 to 17:30.

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

A Administrative Matters

Thanks to our scribe.
43 participants.
There was a problem with the sound quality in the feed to the
Internet, not obvious to the people in the room.
Agenda agreed, with extensions from that recently sent to the
mailing list.
Minutes: no comments at the meeting.

A5 Alternative WG chair
We are grateful to Sabri Berisha for offering to be Co-chair.
Rodney will make any necessary arrangements.

B Update

B1 Recent list discussion

Some suggestions that EU Laws were inadequate (see B4)
The 'mail' sTLD (see B3)

B2 Developments in UBE

Bots and trojans continue to be used for UBE among other things.
Like e-mail viruses, they are able to originate mail from inside
legitimate networks; the resulting e-mail is hard to distinguish
from legitimate messages and often passes through ISPs' outbound
relays.

Financial Services fraud
UBE is a key element in 'phishing'. Messages are forged to appear
to come from a bank or card provider and say that some action is
necessary in connection with an account; neither the e-mail
forgeries nor the targetting are very good, but it doesn't seem
to matter. The usual economics of UBE apply and a number of
people are taken in.
The next level of forgery is more impressive both in its social
and its technical engineering. The messages include a URL that is
cloaked to look similar to that of some bank, and the target Web
page is typically quite a good replica of the real thing; the
victims supply their account details and PIN and the Web site
operator has control of their account.
Clearly it would be possible to withdraw money from the account.
Other undesirable activities include money laundering in which
the proceeds of crime are moved around, possibly between
countries or currencies.

The banks and card issuers are alarmed at this. Their customers
may suffer immediate loss of money, but the reputation of banks
and of the card systems on which they depend are also at risk.
It is not clear who is at fault; gullible customers, or finance
houses over-eager to promote their Internet services and more
concerned with functionality and convenience than with security.
The sums of money involved may be of the order of EUR100M, and
it is not clear how much of that represents financial losses to
consumers or banks.
http://www.antiphishing.org/
is a site giving an overview.

Clearly the options for dealing with the activity include:
eliminating UBE;
educating consumers;
educating banks;
blocking the URLs involved.
The banks may favour blocking URLs, for which a real-time service
based on a BGP peering like the MAPS RBL might be appropriate;
and because of the association with criminal activity the police
in some countries might support such a move. There are
difficulties in deployment (all ISPs concerned must be persuaded
to apply it) and difficulties in principle (is it acceptable to
block all access to an address for the sake of a single URL? What
safeguards are necessary to prevent the system creeping to other
things that Law Enforcement or other agencies take an interest in
from time to time?).

It is likely that the practice would evolve in response to any
technical measures. We might see a popup version distributed as
a virus, or some such thing.


B3 Developments in anti-spam

ASRG update
http://asrg.sp.am/about/subgroups.shtml
gives some overview.
The two main activity streams are in sender-pays technology and
validation of sending MTAs. A variety of possible implementations
of each approach are being considered; for some the author or
enthusiastic advocate believes that deployment can begin at once,
but others are more clearly in research.

Fearghas McKay reported on the sender-pays stream and specifically
on the 'camram' proposal which uses a well-documented system for
generating cryptographic signatures ('hashcash'). Senders generate
the signatures and must expend quite a lot of computing power to
do so; but the computing resource a recipient needs to verify a
signature generated by someone else is very small. It is not
necessary for any real-world money to change hands.

Q: How likely is it that this will be implemented?
A: It is designed for everyone to use. It does not depend on SMTP2
so it can be implemented on pretty much any kind of server.
Q: Won't spammers just steal the resources they need to sign their
bulk messages?
A: The protocol is designed _not_ to be scalable, to avoid this or
other misuse for UBE (it has to be impracticable to generate tokens
in bulk); but it's hard not to suspect that a few thousand
compromised systems working in parallel would tip the balance a bit.
Q: Will hashcash slow down legitimate mail?
A: The receiving process is only slightly slower, at worst a few
seconds to process the token.
Q: Has anyone calculated how much electrical energy this will cost
(particularly at the sending end)?
A: No, please feel free to calculate this yourself and let us know!
There may be energy costs at the sending end, but also savings at
the receiving end from less UBE being processed.

Authentication of sending MTAs is focused on the use of DNS RRs
which a receiving MTA can attempt to match against the domain in
the originator address. The work is taking place in the IETF MARID
working group (MTA Authorization Records In DNS); its mailing list
is open to all but high volume.

High volume is a feature of ASRG activity. Each technical proposal
is enthusiastically promoted by its originator, though it is not
clear (except to their devotees) that any combination of them can
yet be deployed so as to solve the problem.
The hashcash people, however, are 'fairly sane'. Fearghas says so.

MSN
No movement seen yet from MS. They may well regard the defence of
their own network as their priority.

SURBL
Mally McLane briefly outlined the SURBL, described at
http://surbl.org/.
It particularly looks at URLs in message bodies, rather than
headers. Naturally, people who use it report a very good hit rate.

sTLD 'mail'
There is a proposal to establish a top level domain 'mail.' (among
others).
Spamhaus have a very good record in identifying UBE operators and
helping mail users to reject their output, and it is they who are
sponsoring the TLD through the Anti-Spam Community Registry, a
neutral body to be set up to manage it to identify e-mail operators
who comply with good practice as agreed between the ASCRegistry and
its community (which is not the same as its intended customer base).
The proposal is not as crude as you might imagine; it uses the TLD
not to hold mail addresses (although that may be possible) but to
allow a receiving MTA to check the credentials of another MTA
trying to transfer mail to it. It is a sort of DNS whitelisting
service. More information at:
http://www.ascregistry.org/
and the FAQ page which has a link from there.

ICANN have extended the consultation period for the sponsored TLDs:
http://www.icann.org/tlds/stld-apps-19mar04/stld-public-comments.html

If Internet users come to believe that they can have confidence in
mail from '*.mail.', the UBE industry will go to great lengths to
infiltrate it. The integrity of the ASCRegistry and their ability
to deal with a rogue customer will be critical.

Q: How do we ensure this 'mail.' TLD is not misused?
A: You could make a registry process sufficiently public and
expensive to put spammers off, though it is hard balance to strike.
You could issue certificates with the domain name; but that only
makes any difference if a lot of infrastructure is deployed in MTAs
or mail client software.
Q: The cost and complexity could put off smaller businesses who
don't have a lot of money.
A: You could do it so that for a large price you receive the domain
immediately, while the charge for a domain a month (say) from now
can be much less.
Q: But how will this get around bots and viruses?
A: We don't know.

B4 Legislation
The EU the Directives give protection only to personal e-mail
addresses; business addresses are not covered.
In most cases the national legislation implementing the Directives
also only applies to personal addresses, but this does vary from
country to country.
Ireland: It is for home users and individual users. If you are
a company, university etc you are not included.
Netherlands: We recently passed a very similar law, but an amendment
relating to business is in the pipeline.

Q: Has the EU specified how to decide whether an e-mail address is
personal or business?
A: We don't know.

CAN-SPAM litigation (US)
Some cases are now coming to court. It's not clear what the outcome
will be. The impact of judgments in favour of recipients is unclear;
any judgments in favour of UBE operators would be disastrous.

SpamCop are threatened with litigation
A well-known UBE operator has filed a complaint against SpamCop and
IronPort (who host and now own SpamCop):
http://www.linxnet.com/misc/spamscottrichter/ScottRichterComplaint.pdf
The business concerned is 'OptInBig', though you may consider the name
misleading:
http://www.optinbig.com/
There is a ROKSO entry (actually two) with a link labelled
"Scott Richter - OptInRealBig"
on the page:
http://www.spamhaus.org/rokso/

B5 Products
ASSP, Anti-Spam SMTP Proxy
Something that could perhaps front-end Exchange or other products
which cannot directly use community resources such as DNSNBLs:
http://assp.sourceforge.net/

Q: Can anyone report on any other products to help Exchange?
A: Apparently not.


C Technical measures

C1 Sender verification
There is nothing in SMTP which enables you to identify the
IP address from which the message started with any certainty,
in typical UBE cases where there is reason to suppose that the
sender has tried to conceal the source. The MARID work is
intended to make such tracing unnecessary for at least some
messages.

Meanwhile Law Enforcement agencies have sometimes chosen to
'follow the money'. They buy the advertised product and watch
where the resulting bank transaction leads to:
http://customwire.ap.org/dynamic/stories/I/INTERNET_SPAM?SITE=FLTAM

This cannot be recommended for network operators.

C2 Filtering

Nothing recent to report (but see ASSP in B5).


D Interactions

D1 Marketers
D2 Bulk mailers
D3 ISPs
D4 Other RIRs
Nothing particular to report this time.

D5 ASRG
Covered above in B2.

D6 Other RIPE WGs

Database WG
Marco Hogewoning explained this current hot topic.
The database WG recognise the need to make the lookup
IPaddress -> point of contact
simple, unambiguous and reliable.

They have a proposal for an abuse-mail feature, but there
is not yet consensus on how to implement it. Candidates
include almost all possible combinations of:
Default whois behaviour;
IRT object;
Organisation object;
abuse-c attribute direct in address range objects.
The intention is to get something deployed soon.
The formal proposal from January is at:
http://www.ripe.net/ripe/mail-archives/db-wg/2004/msg00098.html
but list discussion has updated it substantially.

If you think this could help those who have to deal with UBE
complaints, you should follow the discussion on the db-wg
mailing list or in the archives.

EOF
There are often related subjects being discussed at the EOF.
Possibly we should make sure our WG is represented there?


E Advice

E1 Update ripe-206

The LINX are reviewing (next week) their BCP document at:
http://www.linx.net/noncore/bcp/ube-bcp.html
on which RIPE-206 was based.
Please look at RIPE-206 and suggest any changes. Rodney will
see that suggestions are made known to LINX, and it may be that
their update will also be acceptable as a new RIPE document
without major work here.

We might want to suggest an additional section making it clear
that activities supporting or depending on UBE are unacceptable
(eg hosting advertised Web sites, and to specifically say that
distributing address lists or bulk mailing software are normally
not good practice.

We might also want to set out the issues about the use of a Web
form for abuse reporting.
Q: Do we think this is an acceptable way to report abuse?
A: It should be offered but you should always accept mails to abuse@
as well and never require people to use a different one.
Q: Is an automated mail responder acceptable, saying 'fill in our
Web form'?
A: The RFC clearly states that the abuse@ mail address must be
supported. This should always have a human response and not just an
automated response.
[Actually RFC2142 doesn't say quite that. Its main recommendation
is that if anyone deals with 'inappropriate public behaviour' for
a domain, then the address abuse@ should reach that person or
persons.]
Q: How about ticket systems? Should a ticket be assigned to each
report and its number be included in any auto-response?
A: This is useful for the people sitting behind abuse@ but should be
a 3-way handshake to filter out all the spam being sent to those
addresses.
A: Having an auto-response is not a problem as long as a human
response is also sent and it is not ONLY an auto-response.
A: Allowing people to automate the reporting process can be useful
for the end-users.
E2 opt-IN lists
E3 Reporting UBE (standard format for reports)
No progress on these currently, volunteers welcomed!


X AOB

X1 Virus bounces
MTAs integrated with anti-virus software are sometimes configured
to return a report to the apparent sender. Since with current
viruses the apparent sender in both 'MAIL FROM:' and the 'From:'
header line is almost always an innocent victim, this is no
longer helpful and good practice is to suppress it.

This is not exactly UBE so is not entirely appropriate for RIPE-206.
It might fit in a slightly more general BCP.


Y Future tasks

Y1 WG direction
Should we cover all e-mail abuse?
(viruses, illegal content etc)
Should we cover other network abuse?
(not covered in any other WG)
Should we cover even wider network security issues?

It is time to review our charter. One thing we have never done
any work towards is a central facility for reporting e-mail
abuse.
Sabri: It has been recently estimated by a Dutch telecoms company
that to take care of all the abuse in the Netherlands would
require 60 employees!
If we are never going to do it it should be removed from the
charter.

All please look at the charter and suggest how it should be
changed. Comments to the mailing list, or to the co-chairs if
you are shy:
R.Tillotson@localhost
Sabri@localhost


Z Agenda for RIPE 49

Similar pattern, unless you suggest other items.
Offer tutorials?
(will need volunteers, topics)
Two sessions?
One session should then be a tutorial to encourage attendance.
If we offer tutorials we must be very clear who they are aimed at
as we have a very wide audience here.