Az ember azt gondolná, hogy ezek a receive konnektorok olyan kicsi, ártalmatlan lények. Aztán ádehogy. (Nem véletlenül szoktam mondani, hogy a konnektorok közül ők a nőneműek. Elvégre az ő dolguk a behatolási engedélyek kiosztása.)
És ha olyan egyszerű lenne behangolni őket! De nem. Hiába tudod, mit szeretnél, ha egyáltalán nem olyan egyértelmű azt összekattogtatni. Az első két fül (general, network) még hagyján, itt minden érthető. De hogyan is kell értelmezni az authentication, illetve permission group fogalmakat? Hiszen mind a kettő ugyanazt jelenti, nem? Nem. Az autentikáció azt mondja meg, hogy a konnektor milyen autentikációs módszereket, milyen technikákat fogadjon. A permission group pedig azt, hogy – az autentikációs technológia alkalmazása után – kik, milyen csoportok férhessenek hozzá a konnektorhoz.
Hogy egy hasonlattal éljek. Odamész egy bankautomatához. Rá van írva, milyen kártyákat ismer. Pl. Visa és ECMC. Ha csak American Express kártyád van, akkor ez nem a te automatád, biztosan nem vehetsz ki pénzt belőle. Ha van ECMC kártyád, akkor bedugod, az automata felismeri, mehetsz tovább. (Ami persze nem jelent automatikusan pénzt, kell a pinkód, kell, hogy legyen zsé a kártyádon, kell, hogy legyen zsé az automatában, stb.)
From Segédlet |
From Segédlet |
Játszunk el egy kicsit a beállításokkal.
1. kísérlet
Authentication: Externally secured
Permission Groups: anonymous, exchange servers
Ez egy kikényszerített beállítás. Igazából azt szerettem volna elérni, hogy a konnektor teljesen nyitott legyen (ribanc), azaz mindenhonnan mindenkitől befogadjon minden levelet, függetlenül attól, hogy azok neki szóltak, vagy más, akár külső címzettnek. Ezt nevezik egyébként open relay-nek. Ehhez csak az anonymous-t akartam megadni, de a varázsló ragaszkodott hozzá, hogy be legyen kattintva az exchange servers jogosultsági csoport is. Őszintén szólva, fogalmam sincs miért. Hiszen az autentikációs módszernél azt mondtuk, hogy nem foglakozunk az autentikációval, eleve megbízunk a feladóban.
Eredmények:
Levélküldés bentről kintre: sikerült
Levélküldés kintről bentre: sikerült.
Levélküldés kintről kintre: sikerült.
(A tesztről pár szót. Telnet-tel kapcsolódtam a szerverre, a bent és a kint az gyakorlatilag belső, illetve külső feladót jelent. A siker pedig azt, hogy a szerver befogadta a levelet az smtp queue-ba. A továbbküldés – mely már a send konnektor dolga – most nem érdekelt.)
2. kísérlet
Authentication: semmi
Permission Groups: anonymous
Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.
Fura, nem? Az ember azt gondolná, hogy ez aztán az igazi open relay, nem autentikálunk és csak anonymous hozzáférést engedélyezünk. Ehhez képest igen durva az eredmény, a szerver csak befelé jövő levelet fogad. Már kifelé sem tudunk küldeni, még létező belső felhasználóval sem.
3. kísérlet
Elegem lett a kotyvasztásokból, gondoltam, megnézem, milyen lehetőségeket adnak a beépített tipusok. (Amikor létrehozunk egy receive konnektort, akkor sablonokból választhatunk. Az előző kettő custom sablon volt.)
From Segédlet |
Authentication: TLS
Permission Groups: anonymous
Ez az internet sablon volt.
Eredmények:
Kintről bentre: sikerült.
Bentről kintre: unable to relay
Kintről kintre: unable to relay.
Gyakorlatilag ugyanaz történt, mint az előbbi esetben. Ami nem baj, hiszen pont ezt is akartuk: a receive konnektor mindenkitől elfogad levelet, feltéve, hogy a címzett belső ember.
4. kísérlet
Authentication: TLS, exchange server authentication
Permission Groups: exchange servers
A fenti kombináció az internal sablon.
Eredmények:
Hát, az most nincs. Rögtön az első próbálkozásnál, már a ‘mail from’ paraméternél ezt kaptam vissza: client was not autenticated. Ami teljesen rendben is van, hiszen nem vagyunk Exchange szerverek.
Mindenesetre éles rendszerben használva a konnektor remekül működik, a szerver elfogadja a kifelé menő leveleket.
Oké, játszottunk. Most viszont, a kísérletek fényében, rakjunk össze működő receive konnektorokat, különböző esetekre.
Edge Transport szerver
Én a magam részéről törölni szoktam az automatikusan létrejövőket, mert gyakorlatilag nem működnek. Ehelyett a következőket használom:
from corenet
Azok a levelek, melyeknek a címzettje kint van a nagyvilágban. A sablon, amelyikből a konnektor készül, az az internal(!), a network fülön csak a belső Exchange szervereket adom meg.
from internet
Azok a levelek, melyek kintről jönnek és a címzettjük a cégen belül van. A sablon, amelyikből készül, az internet, a network fülön a teljes IP tartományt (0.0.0.0 – 255.255.255.255) kell megadni.
relay
Mindenki, aki a DMZ-ből az Exchange SMTP szerverét használva próbál levelet küldeni. A sablon a custom, a beállítások az 1. kísérletben leírtak. A network fülön csak azokat az IP címeket adjuk meg, amelyek küldhetnek. (Ezzel azért bánjunk óvatosan, hisz ezekre az IP címekre nézve az Exchange szerver open relay lesz.)
Hub Transport szerver
A különbség az, hogy ez a szerver már bent van a belső hálózatban.
client
Gyári konnektor. Ha megnézed, egész érdekes portot használ (587). Ez az SMTP Submission protokoll portja. A történet arról szól, hogy ha van olyan felhasználónk, akinek van belső postafiókja (exchange users permission group), de nem Outlookból levelez, hanem bármilyen más levelezőklienssel (Thunderbird, Eudora, Pine, Pegasus és egyebek), akkor nem RPC-n adja fel a levelét, hanem azon a bizonyos SMTP Submission protokollon. Ha nincs ilyenünk, akkor nyugodtan tiltsuk le a konnektort, ha van, akkor pedig értelemszerűen állítsuk be az IP címeket a network fülön.
default
Ez a – szintén gyári – konnektor leginkább az internal sablonra hasonlít. Ezen annyit szoktam változtatni, hogy nem engedem a teljes IP tartományt, hanem csak a létező Exchange HTS/ETS szerverek IP címeit engedélyezem.
relay
Nagyjából megegyezik az Edge szervernél írtakkal. Annyi az összes különbség, hogy itt már a belső hálón vagyunk, ergo itt azon belső, de nem Exchange szerverek IP címeit adjuk meg, amelyeknek levelezési kényszerük van.
Recent Comments