Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » Spam and Backup/Secondary Server - Perceived Wisdom
  •  
the_creative_partnership

Messages: 57
Karma: 0
Send a private message to this user
Hi,

Wanted to get a few opinions on this and try to draw together notes gleaned from a few other threads.

We have two sites with their own individual mail domains (no sub-domains) and each site has their own KMS to serve these. Being that we have this setup, it seemed sensible to have each site serve as back up for the others MX, thus: -

domainA.com IN MX 10 mail.site1.com
domainA.com IN MX 20 mail.site2.com

domainB.com IN MX 10 mail.site2.com
domainB.com IN MX 20 mail.site1.com

Now each server is configured to trust the other as a relay but the undesirable effect of this is that spam for domainA rejected from site 1 then routes through site 2 and is pushed back over to site 1 without being checked. We preferably don't wish to be in situation where site 1 can reject mail relayed by site 2 as this could be 'A Very Bad Thing'TM, but we also do not wish to receive all this junk via a now very popular backdoor for spammers, namely 'the lower priority MX'.

Are we, a) wasting our time with secondary MX's considering retry timings, b) being sensibly cautious, but need to accept that some will always get under the wire, c) missing a trick in the configurations of each server and their relationships?

I suspect with some careful thinking and configuration it may be possible to get this set up so that not too much gets through, but we still benefit from having a secondary in 'Bad Times'.

Does anybody have any sage words of wisdom/advice for us on this topic?

Cheers
Dan
  •  
BudDurland

Messages: 348

Karma: 10
Send a private message to this user
A common trick for spammers is to try the secondary MX first, under the presumption that it as less spam protection. If both Kerio machines have identical anti-spam settings, though, I wouldn't expect to see the situation you described. For example, if a message is rejected at sitea.com for being in SpamCop, I would expect siteb.com to reject it for being in SpamCop as well.

FWIW, we have a small (P3/1Ghz/512MB) machine running Windows 2000 and IIS/SMTP server with the Vamsoft ORF add-on as our anti-spam front end, and it works really well. ORF cost $199, unlimited domains / mail boxes.

Good is better than evil because it's nicer
--Mammy Yokum
  •  
freakinvibe

Messages: 1554
Karma: 62
Send a private message to this user
I would not use a secondary MX. If you are sure that you will fix your broken mail server within 24h, no messages will ever be lost, because the sending mail servers will try again if they can't reach your server (some configs retry even for 5 days).

For small installations (500 users or less), more than one MX record means more hassle than benefit. For bigger companies, it makes sense also for load balancing reasons.

[Updated on: Fri, 05 October 2007 10:10]


Dexion AG - The Blackberry Specialists in Switzerland
https://dexionag.ch
Previous Topic: Office 2003 SP3 supported?
Next Topic: backing up the backup files - to AIT drive - false
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Fri Nov 24 08:44:39 CET 2017

Total time taken to generate the page: 0.00350 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.