Anti-Spam Working Group Minutes from RIPE 48

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

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.