Mailing list software in the war

against spam

May 2005
Serge Aumont
serge.aumont

cru.fr

Spam is a major issue for ML

Will SPAM be the disease that could shoot the
electronic mail services?
?

t
r
Perhaps not, but we need general mobilization
:
ffo

e
r
a

Users
w

All mail administrators,

re
a
w
ISPs
t
f
o
s
IETF,
L
M
t and Security companies
Software editors
u
o
b
Governments
(legislators)
ta

a
h
MLW(mailing list) are the main application of mail
services (far behind spam though) .

Why mailing lists are surviving

Main goal of SPAM is massive distribution and
attack.
A target is interesting if its big enough. Example :
PC running Windows (there are millions)
NEWS network (killed by Spam a few years ago)

So ML are not yet in the field of interest of spammers

No RFC specifying ML services, so there are

hundreds of different ML softwares.

ML are survivors because they are

small dispersed islands,
not because services are robust

Proposed discussion
1. Todays panorama of ML software
defenses
2. OPT.in OPT.out traceability
3. Applying new MASS (Message
Authentication Signature Standard) into
ML Software

Threats related to spam

Capture of Email addresses :
Subscription lists,
Addresses in archives

Use of MLM as a mailer for spam

distribution
Spoofing of moderator or subscriber email
address
A very simple bot could break ezmlm, listserv, lyris,
mailman, sympa, simulating subscription and
message submission sequence to private list
Should we consider advertisement automatically added to message
footer by email provider and distributed around lists is as spam ?

MLM can not trust SMTP headers

anymore
So far it has been reasonable to
authenticate the message sender by
simply checking the sender header fields.
But Viruses and SPAMs are the main threat
of spoofed email addresses.
Nowadays, it is not rare that a spam or a virus are
submitted to a list using a subscriber or the moderator
email address.
Configuring a list as private or moderated is no
anymore an effective protection.
6

Authentication by challenge
Authentication using a mail challenge is used because of the
lack of deployment of S/MIME or PGP.
Not convenient : mail challenges are becoming important
sources of unwanted messages and may be a mean for
DOS attacks.
Authentication is needed for
Message distribution
Message validation by a list moderator
Command message for subscription, review, unsubscription

Unsubscription now an issue :

it must be secure enough but shall remain easy for inexperienced
users

OPT.in / OPT.out
7

Protecting email addresses

Most MLM provide web archives publicly available. Why?
access control isn't provided by the used software.
Archives are published by some external service or gateway
(mail2news)
Google indexing services are needed

s/@/.AT./ may not be a sufficient protection.

Use javascript, image scripting,
Change method from time to time.

MLMs should provide archive service themselves to keep

control
Archive services MUST respect the X-no-archive header fields
MLMs MUST add this header in most cases

Privacy :

MLMs should allow to remove messages from archives

MLMs should control Google indexing even for public archives
8

Message filtering

Various message filtering technologies can be

used :

Antivirus
Spam filters (Bayesian algorithm)
Blacklist,

1. Filters applied by the ML software itself

2. Filters analysis done by the MTA and action taken
at ML level. The ML software must be able to
check any SMTP header.
9

OPT.in / OPT.out
Many spammers claim that they use OPT.in
actually they dont.

Make ML behave differently from spammers

:
Always apply an authentication procedure for
subscription.
Make old subscriptions expire unless renewed
Train list owners and maybe replace the ADD feature
with the INVITE one.
etc
10

OPT.in traceability
Store required information in order to prove
OPT.in : subscription message and confirmation
challenge, @IP origin, date and authentication
element when using web form
Provide user access to these informations on the
web
Administrative list : OPT.in is not used, the web
interface should inform users : you have been
added to the list students@foo.edu because
your email is in foo student directory
Make a round table of ML developers about
OPT.in traceability ?
11

MASS : Message Authentication Signature

Standard

Message authentication is much needed for SPAM

war
A lot of propositions knocking at the door :

DK : DomainKeys (yahoo)
IIM : Identified Internet Mail (cisco)
META Signature (William Leibzon)
Postmarks (microsoft)
Entity-Entity (verisign)

12

MASS
Most of them are based on MTA signature
due to the traumatic PGP and S/MIME
experience
PKI are not required
SPF :
not a signature technology
but a way to recognize some forged
messages.
13

MASS complexity
Why so many proposals ?
Because of companies competition
Because of complexity :
Roaming usage
Auto Forwarder
ML services

14

3 usages of MASS in ML
Software
Receiving incoming messages
Issuing messages (welcome, remind, )
Relaying messages (distribution)

15

Receiving messages
MTA or MLM
MLM

1. Signature verification
2. Compare signature status with domain
signature policy
3. Optionally use reputation service
4. Use results from 1,2,3 as part of the
MLM decision process : what to do with
a message (distribute, moderate,
request challenge for a better
authentication, reject or reject silently).

16

Issuing messages
ML software produce a lot of messages :
Welcome, unsubscription, authentication
request,

Theses messages must respect new

MASS standards, so they must be IIM,
META or DK signed

17

Distributing/Relaying messages
Do not break existing signatures. Each MASS
proposition includes its specificities that MLM
MUST respect to preserve signatures.
Not new (PGP, S/MIME)

Today many mailing list servers are blacklisted

or penalized (for example by greylist) because
ML servers are massive mailers and look like
spammers.
There are opportunities for a better distribution
process based on MASS and reputation services
18

Where to use MASS ?

Is the ML just a relay ?
End to end authentication

End to end authentication

Mailing list

From:

Subscribers
End to end authentication
19

Distribution process
List policy applied
by authenticated
and accredited
person

Sanitization
and authN

ML
Moderator
service
validation

List policy
may include
method specific to
ML

Assumes responsibility for

distributing this email,
signing it with MASS
technology
20

Prove conformance to list policy

When signing a message ML software proves
the message was transmitted according to this
list policy.
Avoid hawking false news: without any
postmark, forged messages can be sent to any
subscriber bypassing the MLM and look like
messages validated against the list policy
Sign systematically (at the MTA level) or sign
only if validation process is good enough (at
the ML service level) ?
21

Focus on 3 proposed standards

DK
IIM
META

22

DK : DomainKeys
DK does not specify if a mailing list server
should or should not sign relayed
messages.
IF (sender authentication is good enough
and/or editor validation)
Remove DK signature (if it exists)
Add Sender: header and a DK signature

Else
Do nothing
23

IIM : Identified Internet Mail

IIM is very closed to DK with some
variation, in particular in the way public
keys are distributed.
IIM includes a section specific to ML
ML software can re-sign messages with
valid signatures or other indications that
the messages being signed are not
spoofed.
Original signature should not be removed
24

META Signature
META allows to add signature information at
each relaying MTA level.
META allows to sign each part of a message
some parts may be signed by the initial sender,
some buy the MLM

META uses a tag to specify who is the signer.

So it is not required to add a Sender: header.

25

BATV
BATV is a way to tag bouncing messages
in order to automatically ignore bounces
related to forged messages. BATV
techniques are similar to other MASS
proposals.
BATV can help in the process of automatic
bounce management by ML but seems to
me as an optional feature for a ML
software
26

No guidelines for developers

Each MASS proposal has poor or no description on
how ML software should use the specification
probably because :
Each MASS proposal ought to be as general as
possible
MASS proposals are in hard competition. Authors
probably dont want to run up against ML users
Poor IETF specification of ML :
Incomplete specification about SMTP headers usage
in ML (sender) Internet Mail Architecture draft-crocker
No RFC about message modification by ML
27

Conclusions
Authentication is a major issue for ML,
MASS is a opportunity for ML Software

ML developers do have a responsibility :

ML Software should not break MASS
proposed solutions.
Neither should they increase complexity of
proposed standards by ignoring these
technologies.
28