Silicon & Software Systems (S3)‏ Copyright © Silicon & Software Systems Limited Antispam protection IT Department 20/03/2008 Ondrej Valousek

Copyright © Silicon & Software Systems Limited Slide 2 S3 Antispam protection Main Engine based on Greylisting technique –What it does? It works by temporarily rejecting incoming messages –Where it works? It is installed on S3 main gateway –How it works? It does NOT do any processing of the message body It tells us whether the sender party IS a RFC-compliant MTA, not if the sender is a spammer –Which software is used? Open-source milter which is communication with the existing sendmail MTA – –Many big providers and universities are using this package –Part of many well known linux distributions

Copyright © Silicon & Software Systems Limited Slide 3 How Greylisting works?

Copyright © Silicon & Software Systems Limited Slide 4 Explanation What is the „triplet“? –It is an delivery attempt identified by The IP address of the host attempting the delivery The envelope sender address The envelope recipient address Quick explanation If we have never seen this triplet before, then refuse this delivery and any others that may come within a certain period of time (DELAY constant) with a temporary failure If the triplet comes again after DELAY time period, the mail is accepted and so are all subsequent mails What are the constants employed in Greylisting? –D (Delay)‏ An initial delay enforced to deliver any new triplets –A (Autowhitelist expiration time)‏ Already Auto-Whitelisted triplets are removed from the database after this time –T (Timeout)‏ Any new triplet must be re-sent before this time

Copyright © Silicon & Software Systems Limited Slide 5 How our filter works? S3 Filter is based on the classic greylisting, but with some enhancements –The Autowhitelist database only contains IP addresses, not the whole triplets –SPF and TLS checks allow bypassing the Greylisting engine

Copyright © Silicon & Software Systems Limited Slide 6 Disadvantages Legitimate rejection in case of: –The sender is not willing to resend SMTP is considered an unreliable transport, the possibility of temporary failures is built into the core spec (see RFC 2821)‏ As such, any well behaved message transfer agent (MTA) should attempt retries if given an appropriate temporary failure code for a delivery attempt –The sender is using mail farm ( is resent from a different IP)‏ Big providers employing mailing farms use SPF Gmail is a good example –A SPF-signed sender is using forwarding SPF breaks mail-forwarding -> forwarders should use SRS (just like pobox.com)‏ Can cause unpredictable delays in delivery –RFC2821: The sender MUST delay retrying to particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes Can be quite memory demanding –The whole database is kept in memory for speed

Copyright © Silicon & Software Systems Limited Slide 7 Advantages Manageability: –No quarantine to maintain and check Given the volume of spam, it is nearly impossible to maintain it! –No “training” necessary –Simple to set up and understand all the consequences Functionality –Greylisting causes delays A delayed spam message is more likely to be caught by other (following) anti-spam methods –Long-lasting high efficiency Many antispam methods need to be regularly reviewed to cope with new spammer's techniques –No message is lost Message can be refused (SPF fail) or Sender did not want to resend it Either case, no message can be silently lost/deleted

Copyright © Silicon & Software Systems Limited Slide 8 Configuration # some sendmail macros we will use later on... sm_macro "tls_ok" "{verify}" "OK" sm_macro "tls_no" "{verify}" "NO" sm_macro "client_forged" "{client_resolve}" "FORGED" sm_macro "client_unresolved" "{client_resolve}" "FAIL" # And here is the access list racl whitelist list "my network" # Reject SPF hardfails racl blacklist spf fail msg "Rejected (SPF check failed), look at # Heavy-greylist those with too open SPF record (like +all)‏ racl greylist spf self delay 30m autowhite 7d # Whitelist SPF-compliant senders racl whitelist spf pass # Heavy-greylist those with possibly forged dns name racl greylist sm_macro "client_forged" delay 15m autowhite 7d racl greylist sm_macro "client_unresolved" delay 15m autowhite 14d # Heavy-greylist those with invalid HELO (does not contain a dot "." -> not a FQDN)‏ acl greylist not helo /\./ delay 15m autowhite 14d # Heavy-greylist SPF softfails (consider: reject them at once)‏ racl greylist spf softfail delay 30m autowhite 7d # Whitelist STARTTLS compliant senders – spammers can not usually do TLS racl whitelist sm_macro "tls_ok" racl whitelist sm_macro "tls_no" # Default rule racl greylist default delay 7m autowhite 30d

Copyright © Silicon & Software Systems Limited Slide 9 Statistics ( )‏ Conclusion –Nearly 91% of all delivery attempts has been blocked Is anyone missing any legitimate message? –Only 18% of s that passed greylisting, were delayed: 44% of delayed messages were re-sent within 20 minutes after the first attempt 94% of delayed messages were re-sent within 1 hour after the first attempt

Copyright © Silicon & Software Systems Limited Thank You