Exim backup menekítés

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

Van egy exim levelezőszerverünk, ahol az egyik ügyfél számára backup mx szolgáltatást nyújtunk.
Az ügyfél levelezőszervere lerohadt pár napja, és nem tudja helyreállítani. Lassan kezd pánikba esni.
Van rá valamilyen mód, hogy a nálunk gyűlő leveleket ne egy MX-re továbbítsuk, hanem valamilyen harmadik e-mail címre, anélkül, hogy az eddig bejött leveleket kockáztassuk?
Persze manuálisan ki lehetne vadászni a queue-ból, de valamilyen egyszerűbb, egzakt, korrekt megoldást tud valaki ilyen esetre?

  • 1596 megtekintés

( stra | 2018. 07. 02., h – 10:57 )

Fogalmazzuk meg, hogy mi a probléma. Az, hogy most nem tudja elolvasni az eddig beérkezett leveleit, vagy pedig attól fél, hogy hamarosan visszapattannak a te szerveredről azok, amelyeknek a queue-ban tartási ideje lejár? A második esetben növeld meg a queue idejét, ez csak rajtad múlik.

Azt hiszem, a nagyobbik baja az, hogy most nem tudja olvasni.
Azért a queue idő növelése jó gondolat, mondani fogom neki, de úgy tűnt, szeretné már most is olvasni a leveleit.
Egyelőre az a megoldás rajzolódik, hogy külön felállítunk egy levelezőt, és átállítjuk az elsődleges MX-et az új IP-re. Reméltem, van ennél egyszerűbb vagy szebb megoldás is.

A megoldás mégsem lett megoldás.
Bár a timeout_frozen_after = 7d értéken volt, 5 nap után ( 3 órával az új szerver indítása előtt ) a logban megjelent a
"R=dnslookup_relay_to_domains T=remote_smtp defer (113): No route to host"
üzenet, majd közvetlenül utána a
"retry timeout exceeded"
És innentől szépen minden levelet eldobott, azt is, ami csak egy napja érkezett:
"all hosts for '...' have been failing for a long time (and retry time not reached)"
Ezek szerint van egy másik paraméter, ami 5 nap? Nem tudtam ilyenről, és nem is találtam ilyent.
Miért dobott ki minden levelet a 7 nap lejárta előtt?

Köszönöm, jó gondolat.
Nálam ez
* * F,2h,15m; G,16h,1h,1.5; F,4d,6h
Vagyis már túljutottam a 4 napon. Úgy tűnik, ez csak azt szabályozza, hogy milyen gyakran próbálkozzon. Nem találtam olyan utalást, hogy ettől törlődhetne levél a queue-ból.
Ráadásul ez levelenként értendő, itt pedig valami miatt az összes levél kb 1 óra alatt esett ki. A logban csak ** flageket látok, kézbesítésit nem.

Lehetséges, hogy tényleg valamilyen routolási vagy névszerver probléma miatt dobta el a leveleket?

Régen csináltam a konfigurációmat, akkor minden sorának utánaolvastam, de bevallom, minden nem maradt meg a fejemben. Ez sem, hogy mi történik a retry mechanizmus végén (az a frozen beállítás tuti azt csinálja, hogy ha máshogy nem tudja a levelet kezelni 7 napig, akkor freeze-eli - azaz nem pattintja vissza, hanem ott marad a queue-ban - ezt a mechanizmust én gyűlölöm, ergó nálam tuti úgy lett beállítva valahogy, hogy ne gyűljenek a queue-ban levelek).

Közben számolgattam, és lehet, hogy az az 5 nap nem is 5 nap volt, csak 4, ami azért elég gyanús ... Lehet, hogy tényleg ez dobta ki a leveleket?
A biztonság kedvéért felemeltem én is 7 napra az utolsót, de nem vagyok meggyőződve még róla, hogy ez volt az ok. Ráadásul emiatt minden levelet egyszerre dobott volna ki?

Na, ez az. Szerintem sem egyszerre dobná ki, ha ettől dobná ki. De itt 1 órán belül mindegyikre küldött egy bounce üzenetet, és ezzel ki is vette. A bejegyzésekből egyértelműen látszik, hogy 1-2 napos QT értékkel is kidobálta ezeket a leveleket.
A "No route to host" üzenet gyanús nekem, de nagyon.

( VincentV | 2018. 07. 03., k – 17:10 )

Ha pár feltétel nem teljesül, akkor az Exim a domainre vonatkoztatja a retry rule-okat. Szóval ha érkezett egy levél adott domainre mondjuk 7 napja, és azóta NEM tudta resetelni a countereket (azaz nem volt sikeres kézbesítése az elsődleges MX felé), akkor szépen lassan elkezdte leszámolni a 7 napot, majd lejárat után mindent visszadobott, ide értve pl. az 1 perceseket is.

Ajánlott irodalom:

https://www.exim.org/exim-html-current/doc/html/spec_html/ch-retry_conf…

Innét a 3-as pont, és a retry_use_local_part funkció tanulmányozása.

Aztán lehet hogy nálad más lesz a gond, de túl gyakran láttam már Exim adminoka belefutni ebbe (köztük magamat is, amikor elkezdtem vele foglalkozni hajdanán :) ).