Anti-spam draft minutes
- Date: Fri, 20 Apr 2001 16:18:04 +0100
DRAFT 20 Apr 2001
Anti-spam WG RIPE 38, Amsterdam January 2001.
Double session, with about 40 people taking part in the first
part and about 20 in the second.
1. Admin
Dave Wilson, HEANet, kindly agreed to be scribe.
Agenda agreed as presented.
2. Update
2.1 Recent list discussion
2.1.1 SpamWhack
Modus operandi of spammers is to move from one dialup ISP to another
as accounts are closed following complaints. The idea of SpamWhack
http://www.spamwhack.com/
is to track the individual people who open these throwaway accounts
so that ISPs can refuse them new ones.
The SpamWhack service keeps anonymised checksums of customer
information provided on signup; no personal data is stored.
This probably does not breach Data Protection legislation, although
it is possibly to identify people from it if you happen to end up
with a customer who matches.
We don't know in detail what it is a checksum of.
In Sweden some names are quite common, so a trigger on name or
address could give false positives. Telephone numbers are more
interesting.
It would be wise to apply checks to the Caller-IDs people call in
from. Some service providers including most free ISPs validate their
accounts that way already, and will block troublesome customers
based on CLI.
Rodney's not convinced that it adds much to what a responsible ISP
would do anyway, with their customer database.
If you're going to sign people up properly, you probably know who
they are. If you're not going to sign people up properly, you're not
going to find out anyway.
2.2 Developments in spam
No major changes in the pattern of content or volume.
2.2.1 UUNET US
The chair singled out UUNET because they're the biggest source by far
and they conspicuously never reply to anything he sends them
(although they probably close a great number of accounts).
Not PSINet now; they seem to have fixed something.
Would like them to:
block outbound port 25;
seek out real-world individual spammers;
give us specific feedback on cases.
UUNET own a good proportion of the dialups in the US, and resell many
of them. They seem not to have a contract with their resellers that
imposes enough conditions to just cut them off, so the real work for
them is probably renegotiating a lot of contracts.
Questions for UUNET:
Do they intend to block outbound port 25?
What is their timetable for doing it?
When are they going to tell us what they're doing?
It was pointed out that there is a telephone route to the IRT, and
that they do answer (but don't give much feedback on spam incidents).
"Please call UUNET at 800.900.0241 (703.206.5440), option #2, then
option #3, then option #1 to reach our Internet Abuse Investigations
Team, 24 hours a day, seven days a week."
Despite all contacts (mail,phone,fax) nothing much seems to get done.
The local offices in NL and UK are both quite responsive.
US is the problem.
It was suggested that we nominate UUNET for the MAPS RBL.
This would be very drastic but the large operators should be the same
as the smaller ones. It would focus attention on the problem.
Chair: not sure what to nominate for the RBL. The bad practice is
fairly clear, but deciding what to block is difficult. MAPS might say
that, since we're talking about dialups, the DUL is the place for
them to be and they are.
There were no volunteers to compose a good RBL nomination for some
of UUNET.
In one reported incident Above.Net sent a customer a notice requiring
compliance with (Above,Net's) AUP. It turned out that the offending
spam was sent from UUNET; it raises the question whether Above.Net
have an AUP with UUNET and are enforcing it.
2.2.2 China, Korea, Japan
Eastern countries increasingly appearing as the source of spam.
Most spam through eastern relays seems to be on behalf of US
services. Concerned about the move to the eastern countries; think
they may have an entirely different viewpoint on this problem.
Does anyone know ways of getting responsible contacts in CN?
There are 2 bodies in China; the governmental part of the industry
and the universities.
Perhaps talk to APNIC about the division and contacts there.
There are some public multilingual messages that say "you have an
open relay, please look at the MAPS site" --
http://www.cybernothing.org/pub/abuse/relay/.
The Chinese ones are in a Chinese character set.
2.2.3 Collateral spam
Actual user addresses being used as MAIL FROM:, From: or Reply-to:
forged in spam. Real user lists appear to have been procured and
someone is mailing out using them as of 6 weeks ago; systematically
starting at A and working their way through the alphabet. One effect
is that complaints and bounces go to a real user address instead of
postmaster.
The chair wondered why they are doing this -- what's the benefit to
a spammer (or more realistically, to the author of a spamware
'product') from using a real name as opposed to a non-existent one?
The only thing we could think of is that they can market it as a
stealth feature.
2.2.4 MTA check originator addresses
Possible extension to MTA: on receiving an email, try to send a blank
mail to the From: address before completing delivery.
Like many such tricks at the destination MTA, this imposes some
processing overhead. In this case it also involves network
transactions with additional delay; and the spammers' easy
countermeasure is to insert (false) addresses which can be delivered
but are still misleading (as above).
2.2.5 The X.400 model
The chair pointed out the difference between the Internet direct
transfer arrangement and the X.400 specification of service
providers and cost-based mail. One or more cost-based email schemes
of that type (though probably not using X.400 technology) could
operate alongside present Internet mail and some of them could bar
spam from the start. There is a significant bootstrap problem.
2.3 Developments in anti-spam
No major news.
2.3.1 ORBS
The usual comments. Some consider their practice of scanning is an
abuse in itself, some think it is too easy for addresses to be listed
despite a reported 30-day warning period, some think it wrong to
announce a route which is a blackhole. Some ORBS information is useful.
2.4 Open relay products
We confirmed the status of Exchange. As shipped (version 5.5) it is
open for relaying; you have to apply SP2, then secure for relay, then
open up local Routing Restrictions.
We discussed ways to eliminate open relays from our customers'
networks. The key task seems to be to get customers' active involvement.
* "Money" and "Security" are useful keywords to persuade customers
to close relays.
* RIPE-206 is a BCP on relations to your customers. It urges you to
make sure your contracts allow you to take action.
* One should be able to scan one's own network, as part of the
relationship with one's customers.
* Active scanning and testing are delicate. The advantage of being
reactive is that customers can see the damage on the spot. Until
then, most seem to think that they won't be used as relays because
{small company|noone knows us|garlic hanging by router}.
Perhaps stress that relay testers are themselves harmless but are
the tools the spammers use in preparing a spam run.
For illustration, the chair described JANET's practice.
JANET doesn't scan its IP space except by agreement with a customer,
just looks at the top level of .ac.uk for anything that may be a
mailer (A records and MX records). This gives a list of about 2000
hosts, out of which at any particular time about 200 are open relays,
mostly failing the more subtle tests.
Discussion of particular scanning products, to be forwarded after
meeting.
3. Advice
3.1 Opt-IN lists (work item)
This advice is toward bulk marketers, establishing what is good
practice for direct mail. Won't stop the millions-CD stuff, but will
help people who think they're doing the right thing.
The LINX group have pretty much done a BCP on this, but the draft is
not public just yet, Chair presented page he wrote some months ago:
http://www.ja.net/mail/junk/save/lists.html
This is only a draft, not the same as the LINX BCP, but most of the
content is very similar. If there are any serious objections or
omissions, particularly from marketing people, please inform.
The meeting agreed that this is the right target audience.
It's important to explain the thinking behind the WG's advice,
otherwise we get bogged down in arguments about e-commerce and the
like.
3.2 Opt-OUT
Frequently it's the marketing organisations that lead the public
debate; traditional marketing only knows about opt-OUT, so that is
all that's discussed.
E-MPS is DMA's (opt-OUT) preference system. The DMA is trying to
get it mandated in Sweden. On the other hand, the Swedish Consumer
Rights organisation concluded in October that an opt-OUT solution
would never work, so they're now steering toward an opt-IN system.
3.3 Reporting spam
We discussed the importance of actually reporting spam; very few
people actually report every single piece of spam they get. It is
difficult to know how much of this is worthwhile, but clearly if
almost no spam is reported, the ISPs responsible will not take it
seriously.
Reporting spam takes time; this is not negligible if you have a
large number of reports to send.
"We should report as much spam as we can", whether we follow it
through afterwards or not.
A choice of direction: we could encourage end users to report spam
directly or to go through their own ISP's abuse desk.
SpamCop may make life easier, specially for end users.
http://spamcop.net/
It enables anyone to report spam if they have the complete header
in front of them. It's a bit of a scattergun approach. JANET was hit
when the spammer included an irrelevant JANET URL in the message
body.
Many people are more disturbed by the fact that someone has their
address than the time or bandwidth costs. This might be a reason
for reporting through ISPs.
There is some evidence that the issue is taken more seriously by
an ISP if the message comes from another ISP rather than from an
end user.
One ISP explained that they have 5000 users who report spam
internally. This is a high-cost activity but the users are very
happy to have somewhere to report their spam.
We discussed what to put in a spam report. The consensus seems to
be:
1. Subject, 'Spam' or 'UBE' followed by the subject from the spam;
2. One-line identification of the origin, relay or URL that offends;
3. The whole spam message with complete header;
4. Not much else.
SpamCop does roughly this but is more verbose in its identification.
We failed to mention including abuse desk contact details if
reporting on behalf of one or more customers, and we failed to
discuss suppressing individual user addresses in initial reports.
Usually you get only an auto-acknowledgment from the remote ISP in
response; this doesn't mean they've done nothing, but we don't know
whether they have or not. It would be good to have some real info
for our customers.
Keep some sort of stats so that if you don't report all spam, you
can state in your reports that you've also received a number of
other spams not reported individually.
3.4 Responding to reports
Not all spam reports are true or accurate.
Sometimes you can look at the POP logs to see if the suspect was
checking mail at the same time as the spam run was in progress.
RIPE-206 has recommendations about having contracts that allow you
to cut off customers; it doesn't say you have to do it every time.
Hard cases might be:
* someone spamming using a local address but with another ISP's
dialup;
* someone being joe-jobbed.
The BCP does not say that you should try to hunt down a real-world
individual who hops between throwaway accounts; this is beyond the
resources of small and medium service providers. However in, say,
the US, the chair believes that the major ISPs could do forensic
work tracking down abusive individuals and, perhaps, taking
commercial or legal action.
Spam about clearly illegal material? Some see as much as 10%; others
see very little. Report it to the local Law Enforcement agency.
4. Technical measures
4.1 Filtering
Hashbusters: we often see spam with gibberish characters on a line
at the end, or at the end of the subject line, to try to beat
checksum filters. It is not difficult to enhance filters to see
through this trick; but filtering on messages already transferred is
a kind of guerilla warfare where the techniques of each side can
improve indefinitely without bringing a solution any closer.
No new advances in filtering reported.
4.2 Port 25 (587) blocking
Many reasons why ISPs prefer not to prevent connections from dialups
to SMTP or SUBMIT ports in other networks. Chair recommends that
people do it as standard, and have special arrangements for those
who need it unblocked.
Alternatives described to port blocking were:
SMTP authentication.
Some experience in the meeting. Reported as not being difficult.
Fairly easy on Exchange; Microsoft clients just check a box.
Also available in a lot of the usual MUAs. Netscape (usually)
does it by default. Pine also, though it doesn't cache the
password.
POP-before-SMTP.
Less experience reported.
Zero configuration on client side; only needs an operating
procedure to check incoming mail before sending.
We should keep a list of useful contributed URLs on the RIPE web
page as a central resource for email security; request that
members of the group contribute to the list.
5. Interaction with CERTs
5.1 Reading mail headers (work item)
Haven't seen a workable description of what someone should look
for in a mail header. If anyone knows a good one that non-mail
specialists can read, that would be valuable. The O'Reilly book
attempts to say what to look for, but it doesn't seem to work for
most people.
Incident response teams are working in this kind of area.
6. AOB
6.1 ISPs doing something?
Daniel Karrenberg asked at the RIPE 37 plenary what ISPs are
interested in coming together and doing real work; so it is worth
reviewing what the group is actually doing.
* We have produced some BCP material.
* We have not devised any new protocols or written new software,
and this is probably right.
One of the problems with a Europe-based meeting is that we don't
see so much spam originating from Europe. Perhaps we should take a
more assertive stance (still recognizing we are solving a problem
we don't have) which would allow, e.g. other regional registries
to adopt or refine RIPE practices.
Other RIRs may value a platform to support this kind of work in
their meetings. This could be a good first step for them. We
should increase contact with other regions.
It may be possible to turn RIPE-206 from a BCP into a policy
document. It would have to be shorter, we may need to add
something extra. e.g. about filtering.
Read the BCP, discuss on the list, or send straight to Rodney.
Rodney will try to gather information on what other people are
doing and some list of contacts.
It's hard to have an impact in the US for legal or other reasons,
even when we get companies with a US presence at RIPE.
There should be some contact with ISPs in the US. Often it's not
in their short-term interest to help us and many ISPs, there as
here, are not professional enough to properly attack these issues.
6.2 Signing headers
At the RIPE 37 plenary Wilfried Woeber wondered if signing headers
of messages would help at all. Messages might be marked as "good"
because they've got signed headers and we know who signs them.
It is an interesting idea, somewhere between whitelisting
individual originator addresses and whitelisting peer mailers.
Rodney's feeling is that it doesn't solve the problem of mail from
people who have never written to you before; it depends on them
doing something extra and is back to the notion of mail service
providers; you pay them to send a message and they only listen to
people who also pay to send.
The questions are what trusted third party will sign something,
what will the signature mean, and who will pay for it?
XDNS is (or was) a similar idea, maintaining a whitelist of
originator addresses with a DNS or similar lookup. If someone sends
a message to your address, you can compare against a whitelist and
if the From: is not on the whitelist, the sender receives another
message asking them to confirm. The idea is to prevent mail from
false or unwanted addresses from being delivered. The price is a bit
of inconvenience and processing for legitimate chance emails.
Some people trying to advertise will feel it does not scale.
It nicely illustrates the difference between opt-in thinking, where
at least some confirmation is necessary, and the opt-OUT which many
marketers still expect.
[note: xdns.org has no information at present]
6.3 Other approaches
6.3.1 Filter on content of header or body
Concentrate on identifying spam and limiting the short-term damage
to our end users, because:
(1) A lot of ISPs don't know what they *should* be doing,
(2) You're never going to get anyone to join in.
Some organizations will think this means it's OK to send spam and it's
up to us not to let it through.
Building in spam filters to Mac OS and Microsoft Outlook? Surely this
would reduce the short-term problem for end users; so it would solve
a part of the problem. The consensus was that it would not solve all
of it. If people are no longer seeing things they may not complain;
it may inadvertently legitimise the sending of spam since "the problem
is solved".
There is an interesting economic argument. If we can stop people
complaining, that reduces a people cost, and how much of the economic
argument is left? Peak traffic?
6.3.2 Legislation
The legal route may be weak at the moment. The European Commission
is looking at it and may make it easier to bring a case. But (as
above) Europe is fixing a problem it hasn't got; we need a consensus
in more of the world, and it's not clear what community to contact to
establish that consensus.
6.3.3 Ask the DMA to sign up to a policy?
A lot of marketing people don't honestly understand when something
is spam and something isn't. The opt-IN BCP is intended to say some
of the right words if the right people read it - perhaps we should
read it to them.
As a starting point for writing a policy, we should define this.
We tried to make a complete list of types of spam, in case there are
solutions to parts of the problem:
Types of UBE
- UCE - failed-opt-IN
- bulk CD
- Forged origin - discrediting (joe-job)
- hiding (collateral)
- chain letters (and hoaxes) (tend to be fraudulent)
- malicious (virus)
- fraudulent (nigeria)
- (mailbombing)
- political
6.3.4 RIPE RBL
Should RIPE run its own RBL containing only RIPE addresses?
This solves a problem we don't have, and it is felt that RIPE should
not be the organization to do this. However, taking action such as
this may make a statement that it's not going to happen here.
Outsource a RIPE RBL to MAPS? Someone like MAPS without the politics?
But you can't get away from the politics. MAPS don't believe that
their machinery will stop spam; they believe it makes it harder for
businesses to operate using spam.
7. AOB
From the chair.
When the WG was set up its two targets were to produce advice and to
set up a European email abuse centre. When Rodney got to this, noone
was interested in the abuse centre. It could be struck off the
charter, but so far it hasn't been done.
There are a number of activities the WG could get involved in and it
is unwise to jump into the most controversial first. We should find
people to talk to and get involved with existing projects as much as
possible.
Spectre of real time spam (SMS, cell broadcast) - no discussion
since RIPE 37.
