- specify (FQDN for) HELO/EHLO command to be used
- "Alert when incoming mail server does not receive mail within N sec" --> please allow FAR more than 60 s (180?)
Thank you!
missing features for test MailRelay
If you are using Advanced Host Monitor version 9.30, then there is update for you: www.ks-soft.net/download/hm930c.zipspecify (FQDN for) HELO/EHLO command to be used
You may replace hostmon.exe module, then add line like SMTPSystemName1=host.domain.com into [Misc] section of hostmon.ini file and start HostMonitor.
We think its better to set "Alert when incoming mail server does not receive mail before next checking cycle" test option instead of long intervals.Alert when incoming mail server does not receive mail within N sec" --> please allow FAR more than 60 s (180?)
Regards
Alex
Thank you, Alex, will try that tomorrow.
i.e. now we test every 6 hours. Now we know latest 6hours after the outage that the problem exists.
With your suggestion this doubles to 12 hours (test went OK, immediatly after is the outage. We check (send) in 6 hours and recheck (cannot receive) in another 6 hours).
That is why we think the "next cycle" is only useful for tests with a high(er) frequency.
We do not think so. Using "next cycle" would require double as many tests (half the time between tests) to give same response time.KS-Soft wrote:We think its better to set "Alert when incoming mail server does not receive mail before next checking cycle" test option instead of long intervals.Alert when incoming mail server does not receive mail within N sec" --> please allow FAR more than 60 s (180?)
Regards
Alex
i.e. now we test every 6 hours. Now we know latest 6hours after the outage that the problem exists.
With your suggestion this doubles to 12 hours (test went OK, immediatly after is the outage. We check (send) in 6 hours and recheck (cannot receive) in another 6 hours).
That is why we think the "next cycle" is only useful for tests with a high(er) frequency.
10-15min is WAY over the top!KS-Soft wrote:What is the reason to perform test every 6 hours if you can perform it every 10-15 min?
Regards
Alex
Besides that it floods (DOSes) the log files of all mail servers it is absolutely unnecessary to test the backup MX every 10 min (one could use the SMTP test that often but we do not even do that).
Our backup MX is the 3rd (hosted at www.zoneedit.com) and all we need to test is that they made no mistake configuring the paid service (as happened in the past).
I still do not see the advantage for you to limit the customer to an unpractical value (have you ever heard of MXes that operate 2 or even 3, 4 (primary, secondary, antiSPAM, AV) queues and polls these every 30 or 60 sec? A mail takes 2 min to go through that single server. Not to mention the real mail relays (what the test is made for) which are external systems and send the mail when they feel it appropriate.KS-Soft wrote:I still don't see the problem here. What is the problem to perform test every 3 hours instead of every 6 hours?
60s is OK for a single server within our own farm. But not for an internet relay test.
IMHO yes, absolutely. Especially as it takes more time to write these lines you wrote than to change the hard coded limit in the software.KS-Soft wrote:Am I wrong?
As long as a customer does not ask ridiculous features and it only takes seconds to implement: Why would one NOT do it?
Advantage - resource usage. HostMontor should be able to handle thousands test items and perform many tests simultaneously. When you have 20,000 (or more) test items it is very important to use as few system resources as possible.I still do not see the advantage for you to limit the customer to an unpractical value (have you ever heard of MXes that operate 2 or even 3, 4 (primary, secondary, antiSPAM, AV) queues and polls these every 30 or 60 sec
That's why we do not want to hold TCP connection and entire Windows thread for a long time.
Yes, its very easy to change this option but we think its a bad idea.Especially as it takes more time to write these lines you wrote than to change the hard coded limit in the software.
So its better to spend some time trying to convince you then save our time but make software worse.
Regards
Alex
Well this part is true and thank you for that!KS-Soft wrote:Yes, its very easy to change this option but we think its a bad idea.
So its better to spend some time trying to convince you then save our time but make software worse.
Well, that is /very/ unfortunate for us as we bought Enterprise (Lifetime) but only have (exactly) 200 tests so far. So we paid the price for Enterprise and now also pay the penalty for Enterprise resource usage...*KS-Soft wrote:Advantage - resource usage. HostMontor should be able to handle thousands test items and perform many tests simultaneously. When you have 20,000 (or more) test items it is very important to use as few system resources as possible.
One would not need to hold any TCP connection. One sended the mail and closed that connection (one had to anyway - how would you re-use a TCP/25 connection to connect to TCP/110 later??) and later make a new connection for pop3. That thread wouldn't matter in our environment.KS-Soft wrote:That's why we do not want to hold TCP connection and entire Windows thread for a long time.
How about 180s (or even 300!) and a MsgBox popping up when t>60s warning the customer? Yeah, that's another 10s to codeKS-Soft wrote: Yes, its very easy to change this option but we think its a bad idea.
So its better to spend some time trying to convince you then save our time but make software worse.
but it really would help smaller customers to get more use out of your software.* this is NOT a refund request!
