postfix transport - "megoldva"

Web, mail, IRC, IM, hálózatok

Lenne egy olyan problémám, hogy beállítottam egy postfix servert, ami egyes domain-be irányuló levelek esetén átküldi a leveleket egy másik smtp servernek (sajnos ilyen hülye a hálózat, meg a security, hogy csak így lehetett megcsinálni)
Tehát így néz ki a transport tábla

ezadomain.org :[idemenyjen.com]

A probléma ott van, hogy a security szakemberek meg fogják szüntetni a kapcsolatot az idemenyjen.com szerverhez. Ezentúl nem fogom tudni elérni. Kérdeztem, hogy akkor hol van egy olyan szerver a globális hálózatunkban, amit használhatnék. Erre a válasz:

You should use public smtp as if you are (Ex: hotmail), becouse the internal counication are over.

Ezt most hogy? Szerintem open relay-t block-olja a nagy céges levelező.
Hogy lehet megmondani a postfix-nek, hogy mondjuk a gmail-t használja user!passwd párossal a küldéshez? Egyébbként én nem akarom, de úgy néz ki ez lesz belőle.

Előre is kösz.

  • 1169 megtekintés

( golgota | 2008. 05. 09., p – 19:55 )

közben találtam rá megoldást

relayhost = [smtp.gmail.com]

az smtpd.conf-ban meg 


[smtp.gmail.com] valaki@gmail.com:12345678

de ez ugye nem valami fényes megoldás.

Egyrészt a Gmail miatt nem leszel boldog, mert a gmail átírja a from mezőt a gmail-es címre, másrészt mi akadályoz meg abban, hogy a szerver jelenlegi helyéről közvetlenül SMTP-zz, harmadrészt mi akadályoz meg abban, hogy a netszolgáltatód SMTP-jét használd?

Egyébként van egy rakás szolgáltató, aki kínál SMTP-t. :)

Egyébként nem értem a problémát, lehet hogy ha kicsit konkrétabban elmondanád az egyik domain másik domain esetét, főleg arra, hogy melyik domain biztonsági szakemberei mit csinálnak, akkor többet lehetne segíteni.

( golgota | 2008. 05. 10., szo – 12:07 )

Akkor részletesebben.
Van egy cég "A". Ez szolgáltatásokat ad el egy másik cégnek "B". Az A és a B hálózata teljesen szeparált. De a B hálózata az A-n belül van. Sok sok biztonsági megoldáson keresztül azonban eljut a B-be a levél, amit neki címeznek. Na szóval:

Ha B-ből akarok küldeni gmail-re (vagy akárhova), az megy.
Ha B-be akarok küldeni gmail-ről (vagy akárhonnan, akkor az megy.
Ha A-ból küldök B-be, akkor az megy.

!!! Ha B-ből küldök A-ba, akkor az nem megy. !!!

Az üzenet szerint nem tudja feloldani a fogadó szerver a B címét: 


May 10 11:54:16 itcdv004 postfix/smtp[18746]: 905AFF8396: to=<cim@A.domain>,
 relay=A.domain.relay.server [ip.ip.ip.ip]:25, delay=43, delays=0.01/0.02/43/0.35,
 dsn=4.1.8, status=deferred (host A.domain.relay.server[ip.ip.ip.ip] said:
 451 4.1.8 Domain of sender address cim@B.domain does not resolve (in reply to RCPT TO 
command))

Na? Ötlet?

Az általam látott megoldások:

- A rendszergazdája beállítják a saját DNS szerverüket hogy oldja föl a B domaint
- A B rendszergazdája beállítja a postfixet, hogy valami publikusan feloldható domain nevet mondjon a helo-ba.
- Fenti megoldások tetszőleges variációja és csavarása.
- B egy másik, nem az A hálózatában levő SMTP-t használ. Ez a "hekk" megoldás és pénzbe is kerül.
- A és B átgondolják a hálózati architektúrájukat.

Én az utolsó pontot tenném az első helyre. Az átgondolásba beleértem mind a DNS-t mind az SMTP-t. Ha B hálózata A-n belül van, akkor security ide, security oda, a 2 hálózat rendszergazdájának illene megoldást találnia... A mi smtp szerverünket is használhatják a hozzánk kapcsolódó intézmények. Szívesen kitenném Őket, de nem akarok kib.ni velük.

Mik

Kérdés, hogy elsődlegesen mi vezetett ilyen kialakításhoz, mert valszeg volt valami oka ennek és azt sem tudom, milyen security koncepció az, hogy egy hálózaton belül elrejtünk egy másik hálózatot. Szóval, nem értem. Nem tudom, mennyire beszélhetsz róla, de ha elmondod, lehet hogy tudunk ötletet adni.

Nez az...nem mondhatom el. :)
Adva vagyon egy nagy világcég. (amit most fogok mondani, abból kiderülhet melyik)
Ez a világcég más cégeknek végez IT szolgáltatásokat. Van egy nagy hatalmas WAN-ja. Ebben benne van számos kicsi LAN, ami az egyes ügyfelek sajátja. Ezek egy ideig valamilyen szinten látták/kapcsolódtak a WAN-ra így nem volt gond. Most úgy néz ki a dolog, hogy ezek a LAN-ok nem elérhetőek a WAN-ból, és ezek sem érik el a WAN-t. Tehát ha megy a mail, akkor először "kimegy az internetre", majd valamilyen úton módon becsorog a célállomás LAN-jába. Na már most ha a LAN-ból küldök levelet, akkor az "visszafele" beleütközik egy security content scanner fürtbe (gondolom ISA-k, mert a cég erős MS partner), amik ugye nem mail serverek, de ha a WAN-ból rájuk telnet 25-özök, akkor úgy viselkednek, mint egy mail server, ha meg 80-azok, akkor úgy mint egy webszerver, stb. Na most mikor megy a levél a WAN-ba a LAN-ból, ezek az ocsmányságok nem tudják a LAN domain-jét feloldani.
Azt mondják ha éppen nem timeout-olnak le: 

451 4.1.8 Domain of sender address cim at lan.domain does not resolve

Értem én, hogy valamiért fogalmuk sincs a lan.domain-ről, csak momdjuk a google/hotmail/freemail/yahoo mind tudnak róla.

Szóval csak annyi kellene, hogy ezek a szarok végre valahonnan értesüljenek róla, hogy van ilyen domain.

Szóval én tudom hogy a mail szerverem tök jó. De az ügyfél levelet akar küldeni a partnerének/szolgáltatójának és nem tud.

Szóval ez a helyzet.
Majd kedden biztos jön a sok üvöltöző majom a telefonomba amerikától olaszokig belgákkal bezárólag, hogy mér' nem megy má, én meg majd mindegyikkel megvívhatom a csatát, hogy megértsék.

mindegy.

köszi a hozzászólásokat.

Anyám! Értem én, hogy világcég, de ez így egy eléggé elbaszott kialakítás... Gratula az IT vezetésnek. Tudom, rajtad ez nem segít :( Biztos vagy benne, hogy a DNS OK? Sokan vannak akik azthiszik hogy hogy, pedig dehogy! Ha privátban megkeresel, szívesen segítek. Hozzánk is csak azok a levelek jöhetnek amelyek a DNS, HELO teszteken sikeresen átjutnak.

Mik

gondolod, hogy a DNS-hez hozzáférek...hahahaha....a LAN DNS-t olasz hálózati szakemberek állítják (hozzáteszem szarul, úgyhogy inkább felraktam egy forwarding cache-t és kérvényeztem a DNS forgalom kifele engedését a külvilágba és ne csak a LAN DNS-e felé, így megtalálom a külső dmain-eket. Van valahol mége egy DNS szerver, ami a külvilágnak megmondja, hogy hol a LAN.domain, de erről még annyi fogalmam sincs, mint arról az elcseszett DNS-ről, amiről az imént beszéltem)....a content filter szervereket megint más üzemelteti, és fogalmam sincs kicsoda. Ennél még jobb, hogy a belga project manager sem tudja.

A DNS tuti jó, mivel a gmail, yahoo, meg mindenki más is megtalálja a LAN.domain-t és szépen bejönnek a levelek. Sőt már a spam-erek is próbálkoznak, de reject-en vannak a nem létező domain-jeik miatt meg még ezer másik ok miatt.

Szóval nem is akarok én már senkit zavarni ezzel. Azért is írtam, hogy "megoldva".
Felejtsétek el! Én is azt fogom tenni, csak írok egy hosszú levelet a line manager-emnek. :)