exim4 hiba, unrouteable address

 ( AndrewBoy | 2010. december 17., péntek - 18:32 )

Sziasztok!

Gondom van, nem történt semmi változtatás a config fileokban és egyik percről a másikra az exim nem hajlandó a leveleket sem lokálisan sem smarthost útján célba juttatni.
Az első hiba jelenség: no IP address found for MAIN_RELAY_NETS. Minden bejövő és kimenő levelet eldobott. A main_relay_nets nek beállítottam a lokális hálót. Küldeni már enged,
de most unrouteable address hibát ad.
Nem változott semmi a config fileokban, nem változtattam sehol, egyik pillanatról a másikra megállt az élet. 5 éve működik hibátlanul az exim, most nem értem ezt miért csinálja.
Mit nézzek meg? Mi lehet a gond?

Még lokálisan sem akarja a kézbesísi hibát elküldeni:

2010-12-17 17:24:31 1PTd6d-0000xH-Em <=

H=(ANDREW01) [192.168.0.11] P=esmtp S=2597 id=002701cb9e06$e1bfb1e0$a53f15a0$@andrewboy.com
2010-12-17 17:24:31 1PTd6d-0000xH-Em **

: Unrouteable address
2010-12-17 17:24:31 1PTd6d-0000xL-GZ <= <> R=1PTd6d-0000xH-Em U=Debian-exim P=local S=3422
2010-12-17 17:24:31 1PTd6d-0000xH-Em Completed
2010-12-17 17:24:31 1PTd6d-0000xL-GZ **

: Unrouteable address
2010-12-17 17:24:31 1PTd6d-0000xL-GZ Frozen (delivery error message)

Mit nézzek meg és hol? merre lehet a hiba?

Köszönöm.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"nem történt semmi változtatás a config fileokban"
"nem hajlandó a leveleket sem lokálisan [...] célba juttatni."
Elsőként, még mielőtt szerkesztenéd, nézz rá az exim.conf-ra, majd tekints rá a /tmp, majd a /bin, /sbin és /usr/bin környékére is. Jelenleg elég intenzív tevékenység folyik az interneten Debian és Exim ügyben.

"5 éve működik hibátlanul az exim, most nem értem ezt miért csinálja."
Ugye naprakész a rendszer, és volt frissítés az elmúlt néhány napban.

Mit keressek? exim configot visszamásoltam egy régit (mindig mentek mindent) de ugyanaz a méret és dátum volt.
Pont ma frissítettem.

Viszont most nézem hogy a külső levelek beérkezését eldobja relay not permiteddel.

2010-12-17 17:56:12 H=mail01a.mail.t-online.hu [84.2.40.6] F= rejected RCPT : relay not permitted
2010-12-17 17:56:12 H=mail01a.mail.t-online.hu [84.2.40.6] F=<> rejected RCPT : relay not permitted

Tehát totális bmeg van;) Kezdem tényleg azt hinni hogy valaki járt itt......

"Mit keressek?"
Erre így a távolból nem tudok konkét választ adni. Alapvetően három változat van. Az egyik, hogy a frissítés során történt valami. A másik, ami kevésbé szívderítő, hogy a napokban vihart kavart Eximmel kapcsolatos hibát kihasználva ténykedtek a gépen. A harmadik pedig az egyéb kategória.

Az utolsó jól működő állapot környékétől logok átnézése, a hiba első megjelenéséek időpontjának megtalálása, ekörül file módosulások keresése, "rejtett" process keresése stb. Nem akarlak elvinni abba az irányba, hogy bejuttot valami a gépedre, de ez is egy lehetőség.

Praktikus javaslat: a hiba elhárításáig tűzfallal szűrd ki a bejövő SMTP-t, hogy ne pattanjanak vissza a feladóhoz a levelek.

Átnéztem a config fileokat, a hiba tegnap este 20:08 tól van, előtte még küldtem levelet, de az utána béerkező levelet már nem kaptam meg, eldobta a gép.
Frissítést most csináltam meg nemrég, tehát a frissítésből nem lehet hogy van hiba. Gépet indítottam újra, de nem javult meg semmi. Átnéztem a könyvtárakat, tegnapi dátumra utaló mozgás nem volt.
Átnéztem a logokat, semmi szokatlan nincs tegnap egésznap.
Rejtett processt hogy lehet keresni? :)
Oks, azt kilőttem. Köszi.

Na rossz hírem van, éjjel 2kor valaki felmásolt egy dropbear nevezetű dolgot és az fut, letörölni nem tudom.
Megoldási javaslat esetleg?

"valaki felmásolt egy dropbear nevezetű dolgot"
A netstat valószínűleg mutatni fogja.

Immutable flag levétele, procps csomag újrainstallálása, az xfs3 kiiktatása és törlése az rc-ből, exim.conf törlése (elsőként elmozgatása), /dev/null helyreállítása, ebben az időszakban módosult vagy létrejött file-ok keresése. Zárójelben, de fontos: ez csak a működőképesség helyreállítása. A gép ilyenkor kompromittáltnak tekinthető.

Van róla szó itt és itt, és várható, hogy a Google egyre több találatot fog rá adni.

Köszi, reinstall, jobbat nem tudok sajnos:(

kész vagyok a reinstallal.... :)
legalább szép clean, bár 10 éve nyúztam azt a rendszert:( sajnálom:(

aztaa, én is sajnálom. attól félek, hogy előbb utóbb én is beleszaladok...

Ilyenkor minden user kap egy uj jelszot?

+1 a gyalu+újratelepítés megoldásnak, pláne, ha nem kimondottan security/*nix expert/időmilliomos a rendszer gazdája...

Ebbe mi is belefutottunk, valami csunya buffer overflow dolog van a háttérben.
A lényeg, hogy addig tolta a sorokat a delikvens a mailbe, amig az exim ugy nem kezdte érezni, hogy jobb lenne neki ezt shell scriptként futtatnia, mert ez a rendszer konzisztenciájának és az üzembiztonságnak is jót tenne...

A probléma felületkezeléséhez az exim4 config main szekciójába a következő két sor javallott. Ennek hatására az exim azelőtt figyelmen kívül hagyja a beléje pumpált maszlagot, mielőtt megtörténne a baj...

header_maxsize = 8k
header_line_maxsize = 2k

Meg egy ilyen javaslattal talalkoztam:
log_selector = -rejected_header

Továbbá:
CentOS 5: bug 0004671
Redhat EL4: RHSA-2010:0970-1