Mail Security Testing Framework is a testing framework for mail security and filtering solutions.
The mail security testing framework works with with Python >=3.5. Just pull this repository and go ahead. No further dependencies are required.
The script mail-tester.py runs the tests. Read the help message with
./mail-tester.py --help and check the list of test and evasion modules with
./mail-tester.py -l to get an overview about the capabilities and the usage of the script. Some hints:
- At least the parameters
--toshould 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
./mail-tester.py @tester.conf(configuration contained in tester.conf).
- Multiple recipients can be configured with
--tofor testing of different filter configurations.
- Some mail filtering solutions may reject messages after a while. Use
--auto-delayfor automatic throttling of the mails. This can be fine-tuned with
- Some tests (Spam and Malware) require samples. Put these in directories and configure these directories with
--malware-folderparameters. The samples are not included in this repository (and will not be). Good places to get malware are theZoo, Das Malwerk or other collections. Spam can be exported straight from yout Spam folder, but must be in EML format.
- Blacklists can be supplied with the
--blacklistparameter 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 Thinkstfor 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
--outputas 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.
Own tests can be implemented with a class in one of the iexisting or newly created Python files in the
tests/ directory. The class must be a subclass of
MailTestBase located in the module
tests.base of this project. Newly implemented tests are discovered automatically when the class variable
active is set to
True. Further (if you plan to contribute tests back to the main repository), the class variables identifier, name and description should be set appropriately.
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.