Still missing functions in version 2

[zeusdk]

Hi MailEnable

We have been going through the enterprise edition version 2 and we have found some important functions that (still) are missing:

1) The view of the mail server is great, but we are still missing the possibility of sending the important warnings to us (the responsible guys for the mail server) via email or even better via SMS to indicate that there is something urgently that must be looked into. We still have to log into the server to check if everything is (still) running as it should.

2) There is no filter action that blacklists (nor whitelists) the IP-address of the sending mail server - in this way we cannot for example do an action of blacklisting the mail servers that sends to our spam-honeypot. In this way spam mails keep getting through even though we KNOW that they are spam! We can only wait of the bayesian filter to learn and later on reject the spam. But at the bottom line this is to late!

3) It is great that the URL DNS blacklist is finally here – I recommend it for over a year ago: http://forum.mailenable.com/viewtopic.php?t=7595

But there has not been put any effort into inserting the URL DNS blacklist services around the world. In this way beginner postmasters have to spend a lot of time asking around for the services needed.

And there is no distinction between URL DNS blacklists and IP (SMTP) DNS blacklists… when you click ADD you can pull services from the same list.

4) There is no “Open Relay” test in the version 2!!! So we still have to use 3’Th part software to test our settings for “Open Relay”. Open Relay is not just something that happens for beginners… if you use combine mail proxies and privileged IP-addresses (in the wrong way) then you have it. We had an open relay via one proxy for 2 days and Mail Enable came with no warnings.

5) The mail server can still blacklist it self. If you don’t remember to insert our new IP-addresses in the whitelist than you are in risk of blacklisting your self if you have services installed on the server that use Mail Enable (in a wrong way). Mail Enable already knows the (local) IP-addresses from the list of binding IP’s, so it shouldn’t be a problem… but Mail Enable is not using the info it already knows…..... It shouldn’t even be relevant to remember to insert your own IP’s in the whitelist.

We are looking forward to the response from Mail Enable and you guys out there using the mail server

[MailEnable]

Please see answers/comments below:

1. This is somewhat peripheral to the core role of the Mail Server itself - and is something that it is very unlikely that MailEnable will/should provide an end-to-end solution for as much as facilitate integration with dedicated products. Windows itself will provide a framework for taking actions when errors occur with services, disk space is low, etc; and there are specialized applications that can make similar warnings about IO, threading and memory usage. ie: MailEnable should generate events or alerts in a format that allows other applications (eg: SNMP monitoring applications) to generate alerts or execute actions/workflow.

Agreed though, there is room for improvement here and MailEnable could be modified to notify when services stop or queues exceed nominated thresholds, but a better alternative could be to simply write to the event log and rely on SNMP monitoring agents to pickup on such events.
A recent push in this direction has resulted in the diagnostic report identifying critical errors and reporting them, this will be improved over time to hopefully allow those who wish to use event monitoring software to be able to generate alerts.

2. Yes some general guidelines on which providers to use should at least be made available in the knowledge base. Its hard to prescribe though since historically such providers change names, or cease to exist. KB is best since it can be updated accordingly.
Work is being done to provide different classes of blacklisting dns service providers.

3. Filter criteria and actions do need to be extended and there is work being done to provide filtering at the connector itself.
Scripted filtering does provide much more power over the basic filtering formerly provides - so things have changed for the better in this area - it will of course be extended over time, its simply a matter of priorities.

Something similiar to what you mention is possible with current releases, but has not been documented as such.
Specifically, when someone sends to a honeypot address, they can immediately be added to the IP Address Banned list for the server.

Root: HKEY_LOCAL_MACHINE\SOFTWARE\Mail Enable\Mail Enable\Connectors\SMTP
Value: Block Honey Pot Senders
Type: DWORD
Value = 0 (default=off), 1 = enabled

4. This is hard to do, since the IP address of the server itself will almost certainly be permitted relay.. hence voiding any local test.
MailEnable does provide such a test as a link from the diagnostic report. ie: at http://www.mailenable.com/tools

5. True. MailEnable does attempt to do this before entries are added to the blacklist (it checks if the ip address is in the Inbound Server Bindings registry key). Obviously, if it is occuring and entries are being blacklisted, then there is a situation occuring where somehow they are getting added (perhaps it could be possible if you were binding to all IP addresses and the outbound interface had been forced to use a different IP address to the local loopback). This probably warrants investigation as to how it could happen.
I have raised an issue for such investigation/review.

[zeusdk]

Thank you

One more thing that we are missing is:

6) The possibility of blocking the mail based on a country IP-level, so we can reject two of the most spamming countries: Russia and China. Of course we can use the firewall for this, but again centralized administration is better and what if you don’t have a (advanced) firewall (that can do this) then you at this time cannot block spam (in this way).

Will we also have a country-blocker in the next version?

[zeusdk]

7) And what about blocking the e-mails that pretend to be from one on the same domain – like:

FROM: noneExisting@ourDomain.com
TO: isExisting@ourDomain.com

A lot of spam get in this way.

[fmaxwell]

Something similiar to what you mention is possible with current releases, but has not been documented as such.
Specifically, when someone sends to a honeypot address, they can immediately be added to the IP Address Banned list for the server.

Root: HKEY_LOCAL_MACHINE\SOFTWARE\Mail Enable\Mail Enable\Connectors\SMTP
Value: Block Honey Pot Senders
Type: DWORD
Value = 0 (default=off), 1 = enabled

That is REALLY dangerous. I could log on to aol.com and send messages to the honeypot address on your domain. That would get legitimate AOL servers added to the banned IP blacklist. Then, suddenly, your users would not be able to receive mail from AOL users. I could then do the same from Yahoo!, Hotmail, MSN, etc. and get major service provider e-mail servers blacklisted at your domain.

[zeusdk]

But normally you don't know others honny pots...

[fmaxwell]

But normally you don't know others honny pots...

Ah, the old "security through obscurity" strategy. Sorry, but with my security background, that's not a strategy that I'm comfy with.

It's often easy to find honeypot e-mail addresses (for example: http://www.delete.net/) and I can find a bunch of them on the Internet. I'm sure that you could, too.

Now if ME wants to implement greylisting automatically, where attempts to send to honeypots gets the sending IP greylisted, that would be great. Then the sending IP would get a 'try-again-later' from the SMTP server. The worst you do is delay legitimate mail. After so many legitimate messages (try, wait, retry), the IP could be automatically pulled from the greylist.