Mondja nekem a user, hogy vár egy levelet amazontól és nem jött meg. Mondom biztos greylisted, várjál még. Megint szól hogy de még mindig nem jött meg. Nézem a logot és ezt látom:
Sep 27 06:49:13 server postfix/smtpd[29484]: NOQUEUE: reject: RCPT from a13-15.smtp-out.amazonses.com[54.240.13.15]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 06:54:49 server postfix/smtpd[29562]: NOQUEUE: reject: RCPT from a13-34.smtp-out.amazonses.com[54.240.13.34]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 07:04:17 server postfix/smtpd[29864]: NOQUEUE: reject: RCPT from a13-7.smtp-out.amazonses.com[54.240.13.7]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 07:45:39 server postfix/smtpd[30641]: NOQUEUE: reject: RCPT from a13-22.smtp-out.amazonses.com[54.240.13.22]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Sep 27 08:26:23 server postfix/smtpd[31288]: NOQUEUE: reject: RCPT from a13-40.smtp-out.amazonses.com[54.240.13.40]: 450 4.2.0 : Recipient address rejected: Greylisted for 60 seconds. (see http://postgrey.scweikert.ch/help/server.hu.html); from=<201609271049062037b524d49f4f95a9efd829a4d0p0na@bounces.amazon.com> to= proto=ESMTP helo=
Kap egy greylist-et, erre 5 perc múlva megpróbálja elküldeni EGY MÁSIK smtp szerverről, és ezt ismétli.
Szerintetek normális? :-)
Ilyenkor mi van? Berakhatnám whitelist-re, de az rövid út a spam áradat felé. (Sok spammer küld amazon nevében levelet...)
Hozzászólások
És mi lenne ha az IPtartományt whitelist-elnéd, nem az @amazon.com -ot?
ahh aztat nemlehet mert mivan ha majd meghekkelik az amazont es akkor ohozza beomlenek a spamek? (mondjuk atvenni en atveszem mindenkitol a levelet aztan ha nem eri el az adott score-t akkor megy ra a SPAM tag)
A spammolok amugy is rendesek (ok tartjak be a legjobban a szabalyokat szoval ellenuk a greylist annyi mint halottnak a csok)
Akkor reagálnék, és majd kijavítotok. :-)
#1. Nem tartok attól, hogy meghekkelik az amazont. Viszont van még egy pár másik cég (ahogy már más is említette pl. office 365) amik hasonlót csinálnak. Általában véve problémának számít ha greylist-elés után mindig másik IP-ről küldik el a levelet. Attól félek hogy más is átveszi ezt a "mindig más IP-ről küldök" gyakorlatot, és akkor annak az lesz az eredménye hogy állandó jelleggel kézi whitelist-eket kell írnom. Az most mellékes hogy IP cím tartományra vagy domain név tartományra. A lényeg hogy én ezt nem szeretném.
#2. Nagyon sok spammoló betartja a szabályokat, de nagyon sok meg nem. Nem csodaszer, de hatékony fegyver.
Amazon bármikor átírhatja az smtp szerverek ip cím tartományát (pl. átköltöztetik a gépeket) vagy a domain nevét is, mert semmi nem kötelezi őket. Ezzel a fajta viselkedéssel teljesen lehetetlenné teszik a szürkelistázást, és megfosztanak bennünket egy nagyon hatékony fegyvertől. Hát kinek jó ez?
Véleményem szerint a feladó hülyesége hogy egy 450 greylist-es válasz után nem ugyan arról az IP-ről próbálkozik. Mert a feladó is éppen olyan jól tudja, hogy mi az a greylist, mire lett kitalálva és hogy működik. A problémát nem a címzett oldalán kellene megszüntetni, mert egy olyan feladóhoz mint az amazon vagy a microsoft sok millió címzett tartozhat. A feladó oldalán kellene ezt elérni, és nem is lenne olyan nehéz: ha egy smtp szerver elkezdett foglalkozni a kiküldéssel és temporary failure-t kap akkor ugyan legyen már szíves és próbálkozzon újra.
De neeeem az amazon nem így csinálja, mert ő ezt is megteheti. Elegem van belőlük, és nem csak emiatt.
Hat igen ez sajnos ilyen. Minden nagy mail szolgaltato kiepiti a sajat rendszeret es probalja ugy uzemeltetni ahogyan neki jo/ahogyan kitalaltak a terheleselosztast etc etc.
Sokszor a hatekony eroforraskezeles felulirja a logikat ;)
Nem latsz bele hogyan vannak beallitva a backend/frontend rendszereik es hogyan kene queue-ban tartani "par millio" kimeno levelet.
Szoval mielott kiabalsz erdemes lehet elgondolkodni hogy lehet hogy nem kibaszasbol csinaljak vagy lustasagbol ;)
Azt szokták mondani, hogy a spammer általában betartja azokat a szabályokat, amik nem ütköznek azzal a céllal, hogy nagy mennyiségű levelet küldjön ki rövid idő alatt, lehetőleg nem túl nagy energiaráfordítással.
Ha várni kell pl. az SMTP protokoll párbeszédére, ha tartani kell az elsőre el nem küldött emailt valamiféle queue-ban, az mind lassít vagy erőforrást zabál.
Ezért a spammerek egy része ezeket nem csinálja.
Megnézve a logot, van sok spam, ami szépen megvárja az időt és bejön a greylist várakoztatás után, és van olyan, ami egyszer próbálkozik, greylist visszautasítja és nem jön többet.
Egyetértek! Ami azt illeti, nekem úgy van beállítva a válaszadás hogy bizonyos fajta hibák esetén csak néhány másodperc késéssel küldi el a hibakódot a kliensnek. Sokan már azelőtt lekapcsolódnak hogy megkapnák a hibakódot.
Ja az IP tartomány whitelist-re van még egy ellenérvem. A logból úgy látszódik, hogy ezek a szerverek egy tartományban vannak. De milyen széles ez a tartomány? És ha ott elfogynak a címek akkor a következő smtp szervert milyen címre teszik? Valójában az ip tartomány nem határozható meg. De ha nagyon erősen próbálkozom vele, akkor is csak nagyjából és ideiglenesen. Szóval eltölthetek egy fél órát a címtartomány kitalálásával, amit lehet hogy egy hónap múlva kidobhatok a kukába. De csak az UTÁN, hogy a következő user fölhívott és panaszkodott.
Szóval ez se nyerő.
--lookup by-subnet strip the last 8 bits from IP addresses (default)
Ez be van kapcsolva? Ez alapján át kellene engednie.
amazon ses ip-k
A szürkelistát sok éve szelektíven illik alkalmazni, pl. nemlétező reverzre és dinamikusan osztott címekre utaló reverzre. Ugyanígy az *.amazonses.com -ot pedig lehet whitelistelni.
Lehetni lehet, csak majd amazon úgy dönt egy év múlva hogy nem amazonses.com -ról küld hanem amazonsmtp.com -ról és akkor lehet átállítani a whitelist-et. Ha pedig a yahoo, a google a microsoft meg még pár cég átveszi ezt a gyakorlatot, akkor sok millió címzett szerverén lehet sok ezer whitelist állítgatást csinálni éjjel nappal. Vagy kompletten megszüntetni a greylist-ezést, de az se jobb.
Persze értem én: hiába hisztizek akkor is az lesz amit ők akarnak. Csak nem tetszik. És szerintem nem vagyok vele egyedül.
Ha szelektive greylistelsz a nagyreszuk nem fut ra erre. Tetszeni nekem se tetszik a folenyuk, de ez van.
Hasonlót láttam a logokban valami microsoft office365 vagy micsoda nevű email szolgáltatástól. Majdnem mindig új IP címről próbálkozik, de azért általában pár óra múlva sikerült egy korábban már használt IP címről próbálkoznia.
Az egész nyomozás onnan indult, hogy egy napot is késtek az emailek, de szerencsére kiderült, hogy ez az email szolgáltatás miután megkapta a levelet, meg se próbálta kézbesíteni sokáig. Szóval a greylist csak a tizenakárhány órás késlekedés után tett rá még 1-2 órát.
Ja, és az office365-ből az office 365-öt megvásárló gyanútlan felhasználók küldenek levelet csilli villi outlookal. Pár óra késéssel meg is érkezik a levelük, de milyen jó mert microsoft!
Szerintem ez semmiképp sem a felhasználó hibája.
Hacsak a hiszékenység nem számít hibának.
Biztos úgy van, multinacionális nagyvállalatok usereinek 10 milliói sokórás késéssel leveleznek.
Pedig az office365 tényleg így küld, én is nyomoztam már egy napos levél késés miatt :)
Az összes nagy szolgáltató igy küld. Tehát nem a többtizmilliós office365-ös userek leveleznek sok órás késéssel, hanem a rosszul beállitott, kézzel barkácsolt email kiszolgálók felé akad pár usernek ilyen gondja.
Rosszul beállított - ezen lehetne vitatkozni. Én most is azt mondom, hogy a "mindig más ip-ről küldök" egy nagyon rossz gyakorlat, mert nehezíti a spam elleni küzdelmet. Persze ezen a szinten már nem fekete-fehér hogy mi számít rossznak.
A második része sem teljesen igaz - nagyobb email kiszolgálóknál is van ezzel baj. Csak ott azért nem derül ki, mert ha egy ilyennel felhívod a szolgáltatót akkor a first level support meg se érti a kérdést.
"Én most is azt mondom, hogy a "mindig más ip-ről küldök" egy nagyon rossz gyakorlat"
Akkor azt mondod az összes nagy szolgáltató rosszul csinálja, akik a végfelhasználók mondjuk 80%-át kiszolgálják.
Egyébként én meg azt mondom, hogy az összes nagy szolgáltatónak van spf rekordja, igy velük szemben greylistelni teljesen értelmetlen és mint látjuk kontraproduktiv is.
Tök jó, van SPF rekordja, soft fail...
(az include-olt spf bejegyzések nem számítanak, include-nál a fail nem matchel)
Viszont legalább a kugli site verikációt átestek, az outlook.com kétszer, az office365.com csak egyszer... :)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Pontosan. Az összes nagy szolgáltatónak softfail-os SPF-je van, és ezen nem is nagyon tudnak változtatni. Ha egy Gmail user thunderbird-öt vagy kitekintő gyorsvonatot használ akkor csak a helyi ISP smtp-jén keresztül tud kiküldeni levelet. Vagy esetleg tudna kiküldeni gmail smtp-n keresztül is megfelelő auth beállításokkal, de a userek 99%-a ezt nem tudja normálisan bállítani. Ha a google erre kényszerítené őket a soft fail eltávolításával, akkor állandó problémájuk lenne a tudatlan userek support kérései miatt.
Amúgy érdekes módon a Google meg tudta oldani felhős load balance-os küldés ellenére, hogy greylist esetén a retry azonos IP-ről jöjjön. Szóval nem a load balance a probléma hanem az amazon féle konkrét implementáció a hibás (de legalábbis nem körültekintően lett megtervezve).
Az Outlook-ot leszámítva már szinte minden MUA hallott a submission portról, tud STARTTLS-t és auth-ot (utóbbi ugye submission-ön kötelező is), az automatikus konfiguráció teszteli is ezt a beállítást ("rendes" Outlooknál meg egy DNS rekord és egy xml konfig fájl kérdése, hogy működjön, hogy a user beírja a mail címét és a jelszavát és az Outlook megtalálja az IMAP/SMTP beállításokat).
A softfail szvsz. inkább az átirányítgatások és levlisták miatt bevett szokás, azok azok, amiről le kéne már szoktatni mindenkit :)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Ki mondta, hogy dobd el, ha megbukik? Azt mondtam az spf-el whitelistelni tudod a greylistről a nagy szolgáltatókat. 99,999%-ban, már ha annyira greylistelni akarsz.
Értelmes rendszereken az spf is csak egy pontszámot ad hozzá a spam bizonyossági faktorhoz, nem önmagában kell használni.
Nem dobom el. De ez nem változtat azon a véleményemen, hogy a "mindig más ip-ről küldök" az rossz gyakorlat.
És amit írtál hogy "az összes nagy szolgáltató rosszul csinálja" szintén nem igaz. Google nem csinálja rosszul. Amazon igen.
Nekem egyikkel sincs gondom, ahogy o365-el sem. Akkor biztos én csinálok valamit rosszul.
> Nekem egyikkel sincs gondom, ahogy o365-el sem. Akkor biztos én csinálok valamit rosszul.
Én nem látom az ok-okozati összefüggést. :-)
Nem tudod, nem minden mechanism ad whitelistelhető hostnevet/címet. Egy ptr/exists mechanism és máris bukó a whitelisted (ha pozitív, akkor nem teljes a listád, ha negatív, akkor fehérlistáztál rossz nevet).
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Konkrétan melyik nagy szolgáltatóról beszélsz és mi a rekordja?
+1
https://ip-ranges.amazonaws.com/ip-ranges.json
Ne engedd ami EC2 es done ;)
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[]|select(.service!="EC2").ip_prefix'Szerintetek normális? :-)
letezik a jelenseg. Jobb greylisting cuccokkal lehet /24 cidr-re maszkolni a cimet, es problema volt, nincs. Ettol fuggetlenul az amazonses sem mentes spammerektol, de erre mar te is rajottel.
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
ja, és pláne undorító az amazonses-ben h nincs normális abuse címük/linkjük, ahová ezt jelezni lehetne. EC2-nél van, oda betoltam (hátha eljut a megfelelő helyre), de visszajelzés semmi, a spam pedig azóta is jön tőlük.
Én azon gondolkodtam, h nem whitelist-elni hanem blacklist-elni kellene őket.
Nem hülye, ilyen a felhős, többgépes load balancing. Mi pont emiatt kezdtük el likvidálni. Igazából nincs is nagyon már értelme.
Aki spammelni akar, az úgyis rendes SMTP-n keresztül teszi, nem egy scripttel.
--
The Community ENTerprise Operating System
> Nem hülye, ilyen a felhős, többgépes load balancing.
Ilyen az amazon load balancing-ja. Lehetne másmilyen is.
> Mi pont emiatt kezdtük el likvidálni.
Lehet hogy félreértem, de kizártátok az amazonses küldőt? Ezt sajnos én nem tudom megtenni. :-(
elkezdte likvidalni a greylistet
Aha és ez pontosan az amitől én is félek: az amazon meg az office365 (véleményem szerint) rossz gyakorlata miatt az emberek kikapcsolják a greylisting-et. Pedig tök jó eszköz lenne...
volt. egy-ket jo RBL-el tobbre mesz, es ha meg mindig greylistelhetsz szelektiven.
Amúgy néha a google smtp is rbl-re kerül, és nem is valami névtelenre. Pl. barracuda és hasonlók. A megbízható működéshez rbl whitelist + postgrey whitelist kell. (Bár most már gondolkozom azon, hogy a postgrey-t meg szüntetem...)
Akkor már csak a DKIM marad, szerencsére Google azt normálisan használja.
Nem csak az amazon, az office365, a gmail és a yahoo is pont ugyanígy csinálja. Mert máshogy nincs értelme.
--
The Community ENTerprise Operating System
gmail nem szokta más IP-ről küldeni. A greylist szépen illeszkedőnek találja a második próbálkozását és be is ereszti.
# cat /etc/postgrey/whitelist_clients.local
/^.*\.smtp-out\.amazonses\.com$/
/^.*\.smtp-out\..*\.amazonses\.com$/
/^(o[0-9]{1,2}\.sg|mail-(out|[a-z]{2})[0-9]{1,2})\.booking\.com$/
/^out(|app)mail[0-9]{3}\.[a-z]{3}2\.facebook\.com$/
/^mail-[a-z]{2}0-f[0-9]*\.google\.com$/
/^mail-.*\.outbound\.protection\.outlook\.com$/
/^mailout[0-1][0-9]\.t-online\.de$/
/^mail[0-9]{2}-[0-9]{1,3}\.srv2\.de$/
/^mout\.kundenserver\.de$/
--
Debian Linux rulez... :D
RIP Ian Murdock
Ez hasznos, köszi!
Számomra is hasznos volt, köszi!
(rossz szálba sikerült)
Mindenesetre köszönöm Swifty whitelistjét.