Mailing list software in the war against spam

1. May 2005 Serge Aumont serge.aumont cru.fr Mailing list software in the war against spam

2. Spam is a major issue for ML • Will SPAM be the disease that could shoot the electronic mail services? • Perhaps not, but we need general mobilization : • Users • All mail administrators, • ISPs • IETF, • Software editors and Security companies • Governments (legislators) • ML (mailing list) are the main application of mail services (far behind spam though) . What about ML software “war effort” ?

3. Why mailing lists are surviving • Main goal of SPAM is massive distribution and attack. A target is interesting if it’s 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

4. Proposed discussion • Today’s panorama of ML software defenses • OPT.in OPT.out traceability • Applying new MASS (Message Authentication Signature Standard) into ML Software

5. 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 ?

6. 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.

7. 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

8. 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

9. Message filtering • Various message filtering technologies can be used : • Antivirus • Spam filters (Bayesian algorithm) • Blacklist, … • Filters applied by the ML software itself • Filters analysis done by the MTA and action taken at ML level. The ML software must be able to check any SMTP header.

10. OPT.in / OPT.out • Many spammers claim that they use OPT.in • actually they don’t. • 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

11. 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 ?

12. 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) • …

13. 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.

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

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

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

17. 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

18. 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

19. 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

20. List policy applied by authenticated and accredited person Moderator validation Distribution process List policy Sanitization and authN ML service may include method specific to ML Assumes responsibility for distributing this email, signing it with MASS technology

21. 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) ?

22. Focus on 3 proposed standards • DK • IIM • META

23. DK does not specify if a mailing list server should or should not sign relayed messages. DK : DomainKeys 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

24. 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

25. 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.

26. 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

27. 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 don’t 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

28. 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.