Exchange 2010: multi-wan failover en SMTP

[marcop82]

We hebben voor ons KMOtje een failover oplossing van onze internet provider voorzien, die twee verschillende media links gebruikt van 2 verschillende providers. Wanneer deze failover gebeurt, kan de mailserver outbound mails buiten domain niet meer verzenden. De ene ISP z'n SMTP werkt niet met de andere ISP z'n connectie lijkt me logisch.

Normaal zou je de failover functie in Exchange kunnen voorzien door meerdere send connectors te voorzien, met elk een eigen SMTP en de failover een hogere "cost". Echter werkt dit niet, tijdens een failover test bleek mail niet verstuurd te worden naar het failover SMTP adres.

Mijn vermoeden is dat dit gebeurt omdat de SMTP van de provider van de hoofdverbinding bereikbaar blijft in dit scenario, ongeacht welke link gebruikt wordt. Ik heb hier al naar gezocht maar vind niet meer dan dat dit zogezegd zou moeten werken "as intended" maar dit echter niet werkt. Mails blijven dan een tijdje steken, wat niet zo erg is, maar binnenkort verwachten we minstens 24 uur downtime en we zijn niet zeker dat er dan mails gedropped gaan worden.

Software: Exchange 2010 SP3 op Windows Server 2008 R2 SP1, beide volledig up to date.

[Dennism]

Kun je niet gewoon authentication gebruiken op de SMTP server(s) van de hoofd provider in dit scenario. Zo heb ik dit in het verleden ook enkele malen opgelost. Enige nadeel is wel dat als de ISP maar 1 SMTP server heeft en deze zou uitvallen je wel even handmatig de config moet aanpassen.

In Exchange geef je dan gewoon in de send connector onder delivery de gebruikersnaam en het wachtwoord op die de ISP SMTP server accepteert. Mocht je deze niet hebben is deze vaak wel op te vragen bij de ISP.

Een andere "Quick and Dirty" oplossing is op je firewall 2 deny regels maken dat Verbinding A outbound niet mag verbinden naar de SMTP server van ISP B en verbinding B outbound niet mag verbinden naar de SMTP server van ISP A. valt dan een van de connecties weg zal de SMTP server van de weggevallen ISP niet meer bereikbaar zijn en zou de failover binnen Exchange moeten werken.

Ook kun je natuurlijk geen SMTP van een ISP gebruiken in exchange en zelf je SMTP afhandelen mits correct ingericht.

[marcop82]

Bedankt voor de zeer complete uitleg !

Van Exchange en mail-routing in het algemeen hebben we niet zoveel kaas gegeten, waarom er ooit de SMTP van de provider als relay is opgegeven is ons onduidelijk. Misschien met het zicht op ingebouwde mail screening of betere beveiliging ?

Voorlopig lijkt het correct te werken met "rechtstreeks" (use DNS MX records to route mail automatically) te mailen.
Zijn er andere gotcha's hieraan verbonden ?

[Dennism]

Voor zover ik weet niet zoveel, enkel dat de DNS die exchange gebruikt up to date zal moeten zijn, maar met correcte en goed werkende forwarders in de AD zal dat geen probleem mogen zijn.

Wel een puntje is dat je er absoluut voor moet zorgen dat je niet op een of andere blacklist terecht komt en een of al je ip's. Zorg er dus wel voor dat commercie niet ineens een mailing oid eruit gooit naar duizenden klanten die deze mogelijk als ongewenst kunnen opvatten en meer van dat soort fratsen.

ISP gebruiken voor betere screening of beveiliging weet ik zo niet, maar zou mogelijk kunnen. Maar goed het is natuurlijk altijd beter om zelf een goed in en uitgaand spam filter / AV oplossing te hebben voor E-mail.

[marcop82]

Door rechtstreeks te werken kwamen er verschillende mails niet aan voorafgaand "Bezorging vertraagd". De oorzaak is me dus compleet onduidelijk:

De bezorging van uw bericht bij de volgende geadresseerden of groepen is vertraagd:
[...]
Dit bericht is nog niet bezorgd. Er wordt nog altijd geprobeerd het bericht te bezorgen.

Door de server wordt geprobeerd dit bericht de komende 1 dagen, 19 uur en 55 minuten te bezorgen. U ontvangt een bericht als het bericht na die tijd niet kon worden bezorgd.

Dat verklaart dus waarom er in het verleden via de provider zijn SMTP adres gewerkt werd, maar het verklaart niet waarom dit oorspronkelijke probleem er is. Onze provider weet dit ook niet ik verwacht niet dat het spam-related zou zijn, dan zou bovenstaande bericht niet verstuurd worden.

Via authentication hebben we het nog niet werkend gekregen.

[ Voor 9% gewijzigd door marcop82 op 03-05-2017 09:52 ]