1. The Anti-SPAM service from Forskningsnettet - What is new about it? TF-MSP meeting 4/2-2010 Martin Bech, UNI-C martin.bech@uni-c.dk

2. Fighting SPAM A well-known problem Well-known solutions We all deal with spam Lots of home-built solutions Even more commercial services Is there anything more for us as an NREN to do in this field?

3. Motivation for a common Anti- spam service All universities are centralizing mail handling All Universities are using considerable resources fighting spam Maybe some kind of economy of scale may be achieved And we may even have a few new ideas to make the whole service better and innovative…

4. The basic idea Make the storage of spam mail the sender’s problem While still preserving the benefits of having received the mails

5. RFC 2821 SMTP client required to wait 10 minutes before timeout for DATA completion After we have received the final “.” in the mail we scan it while keeping the connection open. If scanning is succesful, we return the “250 OK” message otherwise the “550” message is issued Our “550” message contains a URL that a “human” sender may use to push his email through

6. Standard reception flow Sender MTA HELO local.domain MAIL FROM: mail@send RCPT TO: mail@rec.dk DATA Subject: bla bla More bla bla Immediately reject mail: 550 Mail delivery rejected Open TCP connection Greylisting In a blocking list? Yes Immediately accept mail: 250 Message accepted for delivery No And give the mail the standard filter treatment Bayesian filtering …and whatever Virus scan Non-delivery mail to “sender” Standard delivery

7. Our approach Sender MTA HELO local.domain MAIL FROM: mail@send RCPT TO: mail@rec.dk DATA Subject: bla bla More bla bla Reject mail: 550 Mail delivery rejected Open TCP connection Greylisting In a blocking list? Yes Immediately accept mail: 250 Message accepted for delivery No Bayesian filtering …and whatever Virus scan Standard delivery Apply filtering while TCP connection from MTA open

8. Advantages in our approach It is the obligation of the sender to store the rejected mail We don’t issue any non-delivery messages – they are the obligation of the sending MTA Blocked and rejected mails may still be stored as desired by the user

12. Ability to rescue all important mails from deletion Honest (or at least human) senders may push their mails through – provided they don’t contain virus Users may rescue rejected mails because we can configure the system to keep a copy even when it is the responsibility of the sender to store the rejected mail For instance: You want a mail from a robot whose MTA is on a blocking list

14. Several ways of recipient validation LDAP Radius AD “SMTP Interruptus” which means sending RCTP To: user to the mail-server and breaking the connection

15. Configurable on domain and user level

18. Anti-SPAM production configuration This figure is not very fancy, but the aim is to transmit the message that we have designed this with scalability in mind

19. Would a similar service be relevant in your NREN? A tremendous interest from the users All built using open-source components No licences – only costs are our developers and the operations of the servers We could help you build a similar setup – call me! martin.bech@uni-c.dk

20. Hvis du arbejder med mailscanning (Anti-SPAM) Så vil du være glad for at vide at der er en Mail-scan erfa-gruppe Mail-scan mailliste (som man tilmelder sig på mailerfa-request@unilist.dk) Nyhed om dette som kommer i Forskningsnettets e-nyhedsbrev (som man tilmelder sig på www.forskningsnettet.dk)