Presentation on theme: "1 Mailing list software in the war against spam May 2005 Serge Aumont serge.aumont cru.fr."— Presentation transcript:
1 Mailing list software in the war against spam May 2005 Serge Aumont serge.aumont cru.fr
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 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
4 1.Todays panorama of ML software defenses 2.OPT.in OPT.out traceability 3.Applying new MASS (Message Authentication Signature Standard) into ML Software Proposed discussion
5 Threats related to spam Capture of addresses : –Subscription lists, –Addresses in archives Use of MLM as a mailer for spam distribution –Spoofing of moderator or subscriber 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 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 addresses. –Nowadays, it is not rare that a spam or a virus are submitted to a list using a subscriber or the moderator 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
9 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.
10 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
11 OPT.in traceability Store required information in order to prove OPT.in : subscription message and confirmation 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 because your 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 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). 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 Mailing list Where to use MASS ? Is the ML just a relay ? Subscribers End to end authentication From:
20 List policy ML service Distribution process Moderator validation List policy applied by authenticated and accredited person Assumes responsibility for distributing this , signing it with MASS technology Sanitization and authN may include method specific to ML
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 : 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 DK does not specify if a mailing list server should or should not sign relayed messages.
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 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 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.