mail-security-tester: testing framework for mail security and filtering solutions

Mail Security Testing Framework

A testing framework for mail security and filtering solutions.

IMPORTANT: Don’t do anything evil with this! Tests of cloud or otherwise hosted solutions should always be approved by the tested provider. Only use your own test accounts and don’t annoy anyone with a load of test mails.


git clone


The script runs the tests. Read the help message with ./ –help and check the list of test and evasion modules with ./ -l to get an overview about the capabilities and the usage of the script. Some hints:


  • At least the parameters –smtp-server and –to should be given for a minimal test run.
  • All parameters can also be stored in configuration files without the prefix . These configuration files can be used by invoking ./ @tester.conf (configuration contained in tester.conf).
  • Multiple recipients can be configured with –to for testing of different filter configurations.
  • Some mail filtering solutions may reject messages after a while. Use –auto-delay for automatic throttling of the mails. This can be fine-tuned with –delay-step, –delay-max and –delay.
  • Some tests (Spam and Malware) require samples. Put these in directories and configure these directories with –spam-folder and –malware-folder parameters. The samples are not included in this repository (and will not be). Good places to get malware are theZooDas Malwerk or other collections. Spam can be exported straight from your Spam folder but must be in EML format.
  • Blacklists can be supplied with the –blacklist parameter and are used as sender addresses.
  • The Shellshock and subject XSS test cases should have a valid backconnect domain, where you are able to see any backconnects (especially DNS requests). The free Canary Tokens service can be used for this purpose. Thanks to Thinkst for providing this awesome service!
  • Some neat attachment recognition evasion tricks can be enabled with –evasion content-disposition. These were used in the past to confuse AV/sandboxing solutions and let them pass malicious mails.
  • Don’t forget to log the test results with –log. Mail filtering providers often reject mails in the SMTP dialog, which is reflected in the generated log.
  • Test cases can be dumped with –output as plain files in a directory, in MBox (–mbox) or MailDir (–maildir) format. This is useful to test mail user agents without sending any mails, to document or review generated test cases.


Copyright (C) 2018 thomaspatzke