The rest of the options are becoming less useful but could still be selected if deemed neccessary, as follows :-
1. Check originator address - for restricting mails based on email addresses eg. you company policy may require you not to accept mails from yahoo or hotmail.
2. Refuse messages containing pure HTML data - this would be one of the more useful option whereby emails that do not have plain text portion will be rejected. HTML emails poses to be a security flaw since there are many virus, trojan horses and security exploits that target the problems found in unpatched Microsoft Internet Explorer and Outlook Express client machines.
Spammers also like to encode their emails (hopefully Mercury will address in their next version' forcing users to open their mail in HTML format to view the contents thereby informing the spammers that someone is viewing their advertisements when the client software retrieves some graphics from the spammer\'s site.
3. Refuse non-MIME messages - As far as we are aware, there are very few non-MIME compliant email clients (one namely being ccMail) in the market, thus enabling this option will probably do more good than harm.
4. Refuse messages that have no \'subject\' field - Blank subject field are accepted but emails without subject field will be rejected. Turning this on will block some spamming software that does not include a subject field in the emails.
5. Refuse messages that have no or empty \'subject\' fields - Better to leave this untick since there will still be many busy users that may overlooked adding a subject title to their emails.
6. Refuse messages that have no \'date\' field - This is another field that only spammers\' mass mailing software do not comply with, so best to have it checked.
7. Exceptions - are useful if you know there are particular emails from certain people that may not comply with the policies stated above and you would like to allow them through. No harm having everyone you know in this list although it would be a chore to add them in.
The above are the main sections in Mercury/32 that we would specifically configure. The rest of it are sufficient enough leaving it at default.
Should you feel that there is a particular section that we should have covered but have not, please email us to let us know.