Kimenő levelek késnek

 ( kincza | 2018. április 27., péntek - 17:23 )

Sziasztok,

Van egy SMTP szerverem, ami egy alkalmazás által generált leveleket küld kifelé ügyfelek számára. Reverse DNS, SPF, DKIM, DMARC beállítva.
Van egy olyan probléma, hogy néha az alkalmazásból kimenő levelek 5-6 perc késéssel érkeznek meg a partnerhez (tisztában vagyok vele, hogy ez még bőven belefér a protokollba) azonban ha egy ilyen küldés után parancssorból pl. swaks programmal ugyanazon küldési beállításokkal küldök egy teszt levelet ugyanarra címre az abban a pillanatban megérkezik és utána néhány másodperccel az a levél is, amit az alkalmazásból küldtem.

Van esetleg tapasztalatotok, hogy mi okozhatja ezt a működést? Főleg gmail címek esetében tapasztalom egyébként ezt a működést.

Ja az SMTP szervert mindkét esetben elhagyja a levél a küldés pillanatában.

Üdv,

kincza

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ő.

Ha a szervered elhagyja az email a fogadó irányába közvetlenül, akkor ez az "ez ilyen" kategóriás dolog. A gmail általában értelmes hibaüzeneteket ad vissza, ha valamilyen gondja van veled.

A késés utáni azonnali megérkezésre valamilyen fogadó oldali küldő figyelő (minimum feladó + küldő IP + fogadó trió alapú) cache lehet a magyarázat. Ez persze csak találgatás, de a gmail forgalmánál valszin nem kevés cpu időt takarítanak meg vele.

A gmail általában értelmes hibaüzeneteket ad vissza

Egy esetben biztosan nem: Ha spam/vírus levelet próbálsz odaforwardolni, akkor 4xx-as hibaüzenetet kapsz, meg valami semmitmondó üzenetet, hogy "mostanában sok tőled a spam...", vagy valami hasonló, miközben _pontosan_ azzal az egy levéllel van a gond. De mivel 4xx-as a hibaüzenet, szegény MTA még próbálkozik jó sokáig. Idióták...

Erre van nekik guideline-juk. Egyrészt a továbbítást gmailre minimalizálni érdemes, másrészt ha jól tudom, akkor a [SPAM] a tárgyban jelzi, hogy csak továbbítasz. Ezzel együtt a továbbításokra, azaz nálunk technikailag külső aliaszokra, egy jóval szigorúbb spam pontszámot alkalmazunk, mint a lokális kézbesítésre. Természetesen mindenkinek igyekszünk a gmail és a pop3 letöltésre felhívni a figyelmét, akinek ez az igénye.

Ez a gmail-es álláspont: https://support.google.com/mail/answer/175365?hl=en

Egyrészt a továbbítást gmailre minimalizálni érdemes

Hát de na. Az a júzer igénye, hogy legyen továbbítás. Szembeszélbe pisálás, ha megpróbálom elmagyarázni neki, hogy a gmail szar, és ne azt használja. Mert ő szereti, és élvezi, és nem szeretné két helyen olvasni a leveleit (ez utóbbi mondjuk érthető), továbbá imapos klienst sem szeretne használni, mert mondjuk nincs értelmes fix asztali gépe.

A guideline-juk szar. Igazából azért (is) szar, mert nem létezik igazán jó megoldás a továbbításra. Ha as-is továbbítom, akkor egyrészt ha átengedek valami spamet, akkor nem az én domainem, hanem az én ip címem lesz feketeseggű, ami pont ugyanolyan szar (vagy még szarabb). Továbbá a szigorú SPF-ű site-ok levelei meg eleve nem is mennek át így a rendszeren, és gondolom egyre több az ilyen - hiszen az envelope sender domain szerint kell ellenőrizni az SPF-et, abban meg nem az én IP címem van. Ráadásul nem lesz benne a levélben a @gmail-es címzett sehol, ami nyilván további spam-pontokat ér (a default spamassassin esetén pl. így van).

Ezzel együtt a továbbításokra, azaz nálunk technikailag külső aliaszokra, egy jóval szigorúbb spam pontszámot alkalmazunk, mint a lokális kézbesítésre.

Ez szép, de ha két címzett van, akkor kétszer spamellenőrzöl? Vagy olyan okos a rendszered, hogy először elemez, beleírja az eredményt, és a kiértékelés későbbi fázisában, amikor már annyi szálra bomlott a feldolgozás, ahány címzett van, akkor megint megnézi, hogy limit felett van-e?

Elvileg az SRS átirányítás megoldás erre, de még nem foglalkoztam vele, valszin csak a levelező szerver upgrade után jön bármi ilyen.

Exim-et használunk. A spamszűrés ACL time megy és ott smtp data után csak a látványos spameket toljuk vissza 5xx-szel, ez valóban minden per email megy. Utána már router szinten szerintem bontja a maileket az Exim per recipient és a routerekben ott vannak a megfelelő szabályok. A helyi kézbesítéskor pedig globális SIEVE szabály pakolja a Junk/Spam folderbe a fejlécbe tett extra sor alapján. Nem mondom, hogy egyszerű a konfig, de nem is 5 perc alatt állt össze. :)

Többeknek többször leírtam nálunk, hogy ha Gmailen akarja a mailjeit, akkor vagy fizessen ott elő vagy szedje tőlünk POP3-mal a gmailje. Minden más megoldás fosul fog működni és lehetnek mindenféle változatos problémák. Van aki fogta, van aki nem. Ha bárki pattog, akkor megy a sablonválasz, hogy nemtámogatjuk, szedje le POP3-mal.

Nálunk is SRS forwarding van. Az első verzió nem volt elég frankó, mivel a leírás, amit találtam, azt tartalmazta, hogy pakoljuk bele az srs címbe az eredeti feladót. Ez nyilván nem megy, hiszen van felső korlátja a mailcím hosszának, és a gugli keményen el is hajt, ha ezt túlléped. Tehát nem tudod stateless csinálni a dolgot, de ettől nem esünk kétségbe, 30 nap után takarítjuk az adatbázist. Maga a technológia működik, attól eltekintve, hogy a mi spam/vírusszűrőnk sok szempontból engedékenyebb, mint a guglié (magyar megélhetési spammerek szempontjából meg pont fordítva: van olyan banda, aki nálunk feketelistás, a guglinak meg jók).

Nálunk is exim van, és reception time spamassassin van. Ami egyszer fut le bejövő emailenként (ergó nem tudom a címzettet nézni, mert több is lehet), kiszámolja a score-t, és a beállított limit felett be sem fogadjuk a spameket (ez volt a cél, hogy ha valamiért valami szűrve van, akkor azt a levelet ne mi töröljük - bazi nehéz debuggolni ugyanis az elvesző levelek útját), ami ezen a szűrőn átmegy, azt mindenképpen kézbesítjük. Ezen a "routerben vannak a megfelelő szabályok" témán elgondolkozom egy kicsit.

vagy szedje tőlünk POP3-mal a gmailje

Na ez az, ami nálunk kategorikus no-no. Jelszót nem adunk ki külső félnek, és ebbe a gugli is vastagon beleesik (arról nem beszélve, hogy a POP3 mekkora fos). A jelenlegi szívásnál is nagyobb szívásnak gondolnám azt, hogy a jelszavak valahol a nagyvilágban el legyenek tárolva cleartextben.

A kedves juzer tudja a jelszót, a nemfrissített kliense szerintem nagyobb veszély, mint egy gugli. Ezt hétről hétre sikerül bizonyítaniuk. Sajnos ez a POP3 is igen mélyen beégett a juzerek agyába, viszont amikor 234232323GB-nyi emailt tenne fel hirtelen, mert ő akkor most IMAP-ozik, akkor fizetni már nem szeret.

Eximnél csinálj egy routert, ami a nemlokális domaineket követi, valahogy így. Neked valszin elég az egyik spampontos szabály.


forward_exter_spamdeliver:
driver = dnslookup
condition = ${if and {\
{ eq{{def:authenticated_id}{false}} } \
{ >{$spam_score_int}{N} } \
{ <{$spam_score_int}{N+} } \
{ ! localdomainloookup } \
}{yes}{no} }
headers_remove = Subject
headers_add = Subject: SPAM $h_Subject:
transport = remote_smtp

Pont az a lényeg, hogy router szinten már szétszedi az Exim. Kénytelen, mert másképp egy store and forward szabályt se tudna kezelni. Tehát egy emailre nyilván egy spampontod lesz, de később dolgozod fel és lokális kézbesítő router nálunk nem foglalkozik a spamponttal, arra ott a SIEVE.

Logikusnak tunik!

Fogadó oldalon nincs véletlen valami greylist? Az okozhat ilyen tüneteket. A másodikat meg már azonnal engedi.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."