(No Ratings Yet)
Loading...The product also allows you to set a custom non-delivery report (NDR) which we use to guard against false-positives. Nothing worse than having your CEO complain about a missing E-mail that was blocked and sitting in a Junk E-mail folder or quarantine mailbox. Our custom NDR looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | <?xml version="1.0"?>
<!--
Tags:
smtp_sender: sender of the original email
machine_name: returns names in the format: foo.bar.com
machine_name_dns: returns names in the format: bar.com
machine_name_host: returns names in the format: foo
-->
<email>
<header>
<header name="to" value="[smtp_recipient]" />
<header name="from" value=""Postmaster" <postmaster@nelemod.com>" />
<header name="sender" value=""Postmaster" <postmaster@nelemod.com>" />
<header name="subject" value="Undeliverable: [subject]" />
</header>
<body>
Attention: [smtp_recipient]
In an effort to eliminate junk E-mail, Your message:
To: [smtp_sender]
Subject: [subject]
Sent: [date]
was blocked from reaching the following recipient(s)[cr]on [date][cr][cr]
</body>
<per-recipient>
[smtp_recipient]
[cr][cr] If you believe that this should not have been blocked or if you
require additional information about this message, please contact
postmaster@esilicon.com. Please be aware that a lot of junk mail
is sent using someone else's address, so if you don't know why you
received this, it's possible that someone tried to junk mail a user
on our servers using your address.[cr]
<mail.nelemod.com #5.1.1>[cr][cr][cr]
</per-recipient>
</email> |
Here is our module order list and a little bit about each one of them.
- Directory Harvesting – This is first because it catches about 90% of the junk hitting the front door of our mail systems. Since we are on the gateway and have multiple domains within our AD forest, we cannot use the native Active Directory lookups. However, we can use the LDAP lookups and point it at our Global Catalog using port 3268 or 626 for SSL. Again, because of our environment, we set the Base DN to be a single blank character (0x20). This is required since we want the GC to search the entire catalog for users in any OU and in any domain. Leaving the Base DN empty will not work. No NDRs are sent out.
- IP Whitelist – We were forced to use IP whitelists because of a serious bug in the product that GFI has simply refused to fix. The product incorrectly parses some sender policy framework (SPF) records and we were blocking a number of customers and clients from sending us E-mail. The only solution was to whitelist their IP blocks and prioritize this module ahead of the SFP module.
- Sender Policy Framework – As noted above, this has bugs in parsing some records, but for simple configurations it does the job.
- Email/Domain Whitelist (incl. Auto Whitelist) – These are a necessary evil. When you have to get business critical messages to the users, you don’t have time to sit around and customize the system and experiment. Try keeping it to a minimum if possible. It takes time to process this. We have a policy of not using the Auto Whitelist just in case a virus or malware gets inside our environment and sends out SPAM.
- Keyword Whitelist – We don’t use this and I see little use for it.
- Custom Blacklist – We protect certain distribution lists, like everyone@ourcompany.com and mailboxes that are for internal processing purposes only. No NDRs are sent out.
- DNS Blacklists – This has evolved over time and we have found problems with some of the supplied lists. We use “zen.spamhaus.org”, “bl.smapcop.net” and “sbl-xbl.spamhaus.org.”
- Phishing URL Blacklist – We turn this on and use the default settinngs. NDRs are sent out.
- Spam URI Realtime Blocklists – Here, we only use multi-subl.org since it encompasses a lot of the others. NDRs are sent out.
- Header Checking – Customize this one. We have found that the “Marks emails with different SMTP TO: and MIME TO: fields in the email addresses as SPAM” option is impossible to use. This will stop all kinds of legitimate mail. We also set the maximum number of numbers in a MIME to be 10 since we send/receive a lot of messages from cell phones. NDRs are sent because this can catch a lot of false positives at times.
- Keyword Checking – Turn this off in the general page, but leave it on for Subjects. It is just too difficult to set this in a way that won’t get false positives. Just checking for a word or phrase is too generic and too much trouble. We have had to tweak the subject filters at times, but it works well. NDRs are sent as a way to handle false positives.
- Bayesian Analysis – Here is where we ran into a really complicated problem. This module is configured to “learn” from outgoing mail as HAM (legitimate mail) that will enhance and modify the pre-existing database over time. In that way, a customer in the real estate industry will train their installation that the word “mortgage” is not SPAM, but it will be SPAM to a computer hardware manufacturer. While the algorithm is not based on numbers of E-mail messages per-se, the product tells the administrator how many messages make up the current database. We had been seeing a rise in the number of false-positive messages generated by this module, so we decided we would reset the Bayesian database and start new. According to GFI, and our own experience, this should take about 2 weeks of learning from the outgoing mail during which time the module should be disabled. However, within 1-2 hours of the installation, we saw a dramatic reduction in the size of the Bayesian database and the reported number of messages in the HAM and SPAM categories. This continued in a very fast progression and continued throughout the two week learning process. Even if we turned off learning, this was occurring. When we finally enabled the module, it was less than 35% of its original size and message count. Our fears were realized as we soon discovered that HAM was being blocked by MailEssentials at an unacceptable level — far more than we ever was with all previous versions of the product. We quickly contacted GFI and at first they wanted Troubleshooters and we simply asked them to duplicate our results in their lab (see item #1 in Technical Support section). We provided the data, even though it was useless, and we went around with them for weeks about this. My bosses were getting pissed about the missing messages and we had to run our entire staff 7×24 watching for blocked legitimate mail and forwarding them to the users. After two weeks of that nonsense, we had no choice but to disable this module which had the effect of letting hundreds of SPAM messages get through to our users. As you can guess, they are very unhappy about receiving all that garbage. Through all of this, we worked with GFI trying to get them to escalate the problem and help us resolve the database issues and what was going on. After two months, they finally told us that this was probably normal and that we should have it “learn” for awhile longer. Even though we were totally frustrated at this point, we decided that our past experience was so good that we would give it a shot. After 4 months of “learning”, we rearmed th emodule. We logged all occurrences and checked the log about 30 minutes later. We found that the false-positive rate was an alarming 50% and it was obvious that this module was useless. GFI was never willing to work with us and verify databases, information or escalate to management even though we requested it on several occasions.
