Gmail szerverek blacklisten

 ( neutrino | 2019. január 4., péntek - 11:53 )

Sziasztok,

Az egyik partnerünk panaszkodott, hogy nem kap meg leveleket gmailes cimekről (pl a mi gsuite-unkból se). Nyomozásom végére kiderült, hogy blacklisten van az a szerver ahonnan én küldenék levelet:
https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a209.85.128.51

Jól sejtem, hogy ez ellen az ég világon semmit sem tudok tenni?

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

Hát nemsokat. A fogadó oldalon tudnak ezzel érdemben bármit, pl. a partner nem tudja az emailcímeitek whitelistelni?

A headereket elemezve kiderül, hogy a levelek köztes szerveren állnak meg, az ellenoldalon nem képződik log a küldés pillanatában. Jó esetben 1-3 óra delay után átkerül a cél szerverre, rossz esetben soha. És a legrosszabb az, hogy nem keletkezik nyoma....
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Mihez képest köztes? A linken lévő IP guglis.

Én is szembesültem vele... Ráadásul sajnos több Google szerver is fenn van. Mivel a Google ezt pont lesz@rja ezért annyit lehet tenni, hogy kiszeded a listát... Ja és magyarázkodni az ügyfélnek, hogy nem mi vagyunk a sz@rok, hanem a Google (az intenkirálycsászár) az aki erről tehet, aztán vagy elhiszik, vagy nem, hiszen egy Google nem lehet hibás, mert ők a Google...

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

> Mivel a Google ezt pont lesz@rja

Meg lennék lepve, ha egy fizetős szolgáltatás supportja erre azt mondaná, hogy bicsibocsi, így jártál, nincs másik IP.

A Google ügyfeleinek csak egy (kis) része használja a fizetős szolgáltatást, a többiek az ingyenest, ahol nincs support, sőt semmilyen hibabejelentési lehetőség sem. Ha meg a másik oldalról nézzük (aki nem kapja meg a gmail-ről küldött leveleket), nekik meg még ingyenes gmail-juk sem biztos hogy van, tehát ha még ott lenne is rá esély (ami nincs), akkor sem tudnának hibát bejelenteni. Az van, hogy alkalmazkodjanak a kicsik...

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Azért %ban megnézném mennyi az a "kis" része használja a fizetős szolgáltatásokat. Nem teheti meg hogy nem foglalkozik a "kis" résszel. Ha pénzt kérsz valamiért és azért szolgáltatást adsz, akkor vannak kötelezettségeid. Tökmind1, hogy 10 darab ember / céget érint vagy 10 milliót.

Nyilván nagy számok törvénye érvényesülhet itt is, mert ha 10millió akkor "gyorsabban" reagálnak, de ez általában csak a garázsBT-k jellegzetessége.. Ahol tényleg arról van szó, hogy van X ingyenes szolgáltatás + X2 fizetős. X ingyeneset használja mondjuk 1000 ember, X2-t pedig 10 darab. Nyilván a garázsBT-nél nem túl gyors a reakció / support / egyéb arra a 10 darab fizetős ügyfélre...

Lehetne mesélni egy-két könyvelőprogram* gyártó magyar cégről ami ebbe a szarrágó kategóriába tartozik ... (bár ott nincs ingyenes verzió ez a slusspoén) N.v.t meg valami kulcsos a mátrixból ... Öröm ott support szolgáltatás igénybe venni ... fizetős ügyfélként :D

Arról lehet tudni valamit, hogy konkrétan milyen okból került rá a Google egyik szervere erre a listára?

--
https://iotguru.live

Mi rengeteg spamot kapunk gmailrol. Es orom szurni, mert DKIM, DMARC, SPF rendben, mivel tenyleg a gmailrol jon.
(outlook.com is hasonlo egyebkent)

--
http://blog.htmm.hu/

Nagyszerű, de ugye a spam, mint olyan egy eléggé szürke zóna, épp mit tekintesz annak, és ugye jelen esetben nem maga a szerver szórja, ezért ilyen esetben csak a content filter jöhetne szóba. Az egész IP alapú spam szűrést már évekkel ezelőtt el kellett volna felejteni.

--
https://iotguru.live

Úgy tűnik nem üzemeltetsz napi szinten levelező szervert... :-)

Ez a "rég túlhaladott" DNS/IP alapú szűrés a bejövő forgalom nagyjából 70%-át szűri ki első vonalként, mert az mind spam, és így a teljes bejövő levél forgalom csupán 30%-ra kell CPU időt számolni a tartalomszűrő esetén. Egy 5-10 címes kis házi szervernél ez nem lenne gond, de ahol sok több száz tartományban sok-sok ezer fiók van, ott aránytalanul sok CPU kapacitást vinne el a tartalomszűrő, ha már a feladóról/csatlakozó gépről tudni lehet, hogy spam-et szór... És aki ilyen rendszert üzemeltet, az sem ellensége a saját pénzének, és nem vesz 10x akkora vasat, hogy mindent tartalomszűrővel tudjon megfogni DNS/IP alapú előszűrés nélkül.

Sőt, mondok még durvábbat: a mai napig bevett gyakorlat IP feketelistát vezetni/aktualizálni, hogy a levelező szerverig se jussanak el bizonyos kliensek, hogy még csak az RBL szűrésre se kelljen időt és energiát pocsékolni.

"Úgy tűnik nem üzemeltetsz napi szinten levelező szervert... :-)"

De.

"Ez a "rég túlhaladott" DNS/IP alapú szűrés a bejövő forgalom nagyjából 70%-át szűri ki első vonalként, mert az mind spam, és így a teljes bejövő levél forgalom csupán 30%-ra kell CPU időt számolni a tartalomszűrő esetén."

És mennyi false positive mellett teszed mindezt? Ja, mérni se tudod, csak azt feltételezed, hogy fasza minden...

"Sőt, mondok még durvábbat: a mai napig bevett gyakorlat IP feketelistát vezetni/aktualizálni, hogy a levelező szerverig se jussanak el bizonyos kliensek, hogy még csak az RBL szűrésre se kelljen időt és energiát pocsékolni."

Ja. Sokféleképpen el lehet baszni.

--
https://iotguru.live

Remélem nem okozok nagy csalódást, ha elmondom, hogy monitorozom, összesíttetem, és naponta átnézem a jelentésben, hogy van-e olyan tartomány/IP/e-mail cím, ami gyanúsan nem spam forrás, és minden nap ezen felül átnézem a spam-nak jelölt és a karanténezett levelek listáját is (mert erről is kapom a jelentést). A napi 2000-4000 levél forgalmú szervernél ez napi 5-10 perc. Nyilván ha komolyabb forgalom lenne, több automatizmus és több ember lenne rá.
Ezen felül automatikusan gyűjtöm a túl sokszor sikertelenül próbálkozó/elutasított IP címeket, amikből időszakos tűzfal tiltás lesz (de nem fail2ban vagy hasonló automatizmus).

Ezek alapján eddig 2 tétel került whitelist-re mindössze, mert false positive volt, havi 100 ezer bejövő kapcsolat mellett.

De persze vehetnénk a mostaninál sokkal drágább gépet alá, és tisztán erőből (ész helyett) content filterrel is kiszűrhetnénk azt a havi 70 ezer spam-et a 100 ezer bejövő kapcsolatból.

"Remélem nem okozok nagy csalódást, ha elmondom, hogy monitorozom, összesíttetem, és naponta átnézem a jelentésben, hogy van-e olyan tartomány/IP/e-mail cím, ami gyanúsan nem spam forrás, és minden nap ezen felül átnézem a spam-nak jelölt és a karanténezett levelek listáját is (mert erről is kapom a jelentést). A napi 2000-4000 levél forgalmú szervernél ez napi 5-10 perc. Nyilván ha komolyabb forgalom lenne, több automatizmus és több ember lenne rá."

Nem okoztál csalódást, rögtön gondoltam, hogy fogalmad nincs a false positive részarányról, mert ez lófasz tejszínhabbal, nem false positive report.

--
https://iotguru.live

Ezt a hangnemet és stílust lehet tanulni valahol?

Vagy esetleg ha indítasz levelező rendszer üzemeltetési képzést, lehet jelentkeznék. A kommentjeid alapján rá kellett ébrednem, hogy annál sokkal nagyobb a lemaradásom szakmailag, mint eddig gondoltam.

pedig igaza van. Az rbl-ek velejaroja a fals pozitiv hiba, pl. azert is, mert rengeteg olyan (foleg hosting) gep van, ami legitom levelet is kuld ki a spamek mellett. Masik problema, hogy van egy legitim gep egy random halozaton, amit kompletten rbl-re tesznek a mellette levo spammer miatt. Szoval az igaz, hogy az rbl-lel kis footprint-tel ki tudsz szorni egy csomo spamet, de nem tudhatod, hogy hany jo levelet is kiszorsz.

A napi 2-4000 level meg gyakorlatilag kerekitesi hiba, elenyeszo levelforgalom. Ha nem spamassassin-t vagy mas hasonlo resource hog-ot hasznalsz, hanem egy jo tartalomszurot, az lazan ledaral ennyi levelet naponta...

--
O1G

2 levél/perc forgalommal még a spamassassin is megbirkózik valami öreg vason.

amúgy mi ajánlott manapság spamassassin helyett?

ha neked bevalt, es birja szusszal, akkor maradhat. Valaki irta az rspamd-t, ami kb. spamassassin szteroidokkal. En jelenleg postscreen + clapf kombot hasznalok...

--
O1G

Régebben üzemeltettem két mail szervert, amikre (kb. 98-ban vagy hogy) spamassassin került. spamc, ha jól emlékszem a C-ben újraírt megvalósítás nevére.

Mentek évtizedeken át, de aztán pár éve az egyik, majd tavaly a másik is megszűnt.

Most épp összeraknék egyet. Nem lesz nagy forgalom, de gondoltam, ha esetleg van valami ami ugyanazt megcsinálja kevesebb erőforrás felhasználásával, akkor miért ne azt tegyem fel.

Megnézem majd ezeket, amiket írtatok.

Én egyébként elítélhető módon egy kis forgalmú szerveremen átnyomom a levelezésem a Google szerverein (catch all incoming - forward - Google - forward - dispatch to mailbox). Szopjanak ők a spam szűrésével... :D

--
https://iotguru.live

Mindenféleképpen szólni fogok, ha indítok képzést akár hangnemből és stílusból, akár üzemeltetésből, jó?

Óránként 100-200 levélről beszélünk időszaktól függően (ez már majdnem egy levél 20 másodpercenként!), ha jól saccolom a számaidból... ezt egy havonta 2 dollárba kerülő VPS is képes megszűrni tartalom alapján és akkor még mindig marad ideje a vasnak egy csomó egyéb dolgot művelni... ne idegesíts azzal, hogy mekkora erőforrás megtakarításod van abból, ha content filter futtatása nélkül eldobod a levelet.

--
https://iotguru.live

Ironizálhatsz itt de teljesen igaza van. Nálunk a spam különben a gmaillel szűnt meg.
Itt nem a gmail lesz a hunyó, hanem a rosszul beállított spam filter.

erosen igyvan, csak blacklisttel sok a fals.

--
HUP te Zsiga !

Idézet:
A napi 2000-4000 levél forgalmú szervernél ez napi 5-10 perc

Feljebb még nagy forgalmú szerverről volt szó, nem egy ilyen piciről. Milyen vasat használsz, hogy napi 4000 levél spam szűrését nem képes elvégezni?

Valószínűleg Raspberry Pi 1-et :)

ha 4000 levél 6 óra alatt jön be, akkor 5 sec van levelenként a szűrésre. Sztem ezt az rpi1 még Kodi futtatás mellett is röhögve megcsinálja...

ha mar arrajartam, hirtelen megneztem az egyik assp statisztikat, az elmult oraban aszondja :

ASSP Proxy Uptime: 0 days 0 hours 59 mins 38 secs
Messages Processed: 2727 (65850.4 per day)
Non-Local Mail Blocked: 98.72%
....
CPU Usage: 2.29% avg

szoval nemhogy napi, de orankent 2-3000 levelnel sincs teljesithetetlen eroforrasigenye.

contabonal 13 euros vps :

ASSP Proxy Uptime: 60 days 5 hours 47 mins 3 secs
Messages Processed: 122832 (2039.0 per day)
Non-Local Mail Blocked: 95.7%
CPU Usage: 11.55% (5.70% avg)

--
HUP te Zsiga !

Idézet:
Ez a "rég túlhaladott" DNS/IP alapú szűrés a bejövő forgalom nagyjából 70%-át szűri ki első vonalként, mert az mind spam

Csak az a baj, hogy nem mind spam, amit kiszűr.

Van, ahol ennyi false positive belefér, van, ahol csak a pontozásba segít bele, máshol meg egyáltalán nem használják, mert félrevezető.

Bele kellene írni a szerződésbe, hogy csak gmail címekre garantálják az emailek megérkezését.

Vajon azt garantálják, hogy gmail címekre megérkezik?

Én úgy tanultam annak idején, hogy nincs garancia, hogy bármi email bárhova megérkezik, és azt se lehet tudni, hogy pár másodperc, pár óra vagy pár nap alatt érkezik meg, ha sikeres. Az egész amolyan best effort jellegű dolog, hogy mi megpróbáljuk, aztán vagy sikerül, vagy nem. Kb, mint az SMS.

Ehhez képest manapság mindenki sípol, ha egy email elvész, vagy ha már pár percet kell várni egy másikra. (Pont így az SMS esetén is)

Sajnos valóban best effort. De ahol valóban ilyen problémák merülnek fel még mindig ez a legjobb megoldás. Gmailről gmailre talán valóban megérkeznek az emailek.

Sajnos az RBL és IP szűrés manapság igen kevés.

Én rspamd-t használok, közepes mennyiség, kb napi 15k mail megy át rajta.
2 vCPU és 2GB RAM van alatta, de meg sem kottyan neki.

Elég sok tényezőből áll össze, hogy miből lesz spam.
Ez pl egy pontozás egy konkrét spam esetén. Egyedül a BAYES_SPAM az automata vagy user általi tanítás értéke. Kellő mennyiségű mail folyik át rajta, ezért a Neural netowk modulját is ki tudom használni, vam miből tanulnia.


URIBL_SBL (6.5) [avagroupindia.info]
ABUSE_SURBL (5.5) [avagroupindia.info.multi.surbl.org]
BAYES_SPAM (5.1) [100.00%]
IP_SCORE (3.686052) [ip: (9.47), ipnet: 68.183.160.0/20(4.92), asn: 14061(3.95), country: US(0.09)]
NEURAL_SPAM (3) [1.000,0]
FROM_EXCESS_QP (1.2)
URI_COUNT_ODD (1) [5]
RCVD_NO_TLS_LAST (0.1)
BAD_REP_POLICIES (0.1)
ONCE_RECEIVED (0.1)
DMARC_POLICY_ALLOW (0) [avagroupindia.info,none]
DKIM_TRACE (0) [avagroupindia.info:+]
HAS_REPLYTO (0) [ledfwqynaslampa@avagroupindia.info]
R_SPF_ALLOW (0) [+ip4:68.183.174.112]
ARC_NA (0)
MIME_TRACE (0) [0:+,1:+]
RCVD_COUNT_ONE (0) [1]
PREVIOUSLY_DELIVERED (0) [x@y.hu]
SUBJECT_HAS_EXCLAIM (0)
FROM_EQ_ENVFROM (0)
REPLYTO_ADDR_EQ_FROM (0)
TO_DN_NONE (0)
FROM_HAS_DN (0)
RCPT_COUNT_ONE (0) [1]
R_DKIM_ALLOW (0) [avagroupindia.info:s=dkim]
TO_MATCH_ENVRCPT_ALL (0)
ASN (0) [asn:14061, ipnet:68.183.160.0/20, country:US]
HAS_LIST_UNSUB (-0.01)
MIME_GOOD (-0.1) [multipart/alternative,text/plain]

Annyit fűszerezek még a dolgonk, hogy a renitens köldők pár tucat spam után IP tiltást is kapnak fail2bantől.

Ez egy másik, amit kétesélyesnek értékelt:


NEURAL_SPAM (2.999998) [1.000,0]
RBL_VIRUSFREE_BOTNET (2) [26.200.248.178.bip.virusfree.cz : 127.0.0.2]
HAS_INTERSPIRE_SIG (1)
AUTOGEN_PHP_SPAMMY (1)
HTML_SHORT_LINK_IMG_3 (0.5)
FORGED_SENDER (0.3) [info@spammer.hu,bounce@spammer.hu]
IP_SCORE (0.209966) [ip: (1.62), ipnet: 178.248.200.0/21(0.34), asn: 42864(-0.84), country: HU(-0.08)]
RCVD_NO_TLS_LAST (0.1)
BAD_REP_POLICIES (0.1)
MANY_INVISIBLE_PARTS (0.05) [1]
FROM_NEQ_ENVFROM (0) [info@spammer.hu,bounce@spammer.hu]
ASN (0) [asn:42864, ipnet:178.248.200.0/21, country:HU]
DKIM_TRACE (0) [spammer.hu:+]
MIME_TRACE (0) [0:+,1:+]
HAS_REPLYTO (0) [ne-ide-valaszolj-hanem-az-info@spammer.hu]
R_SPF_ALLOW (0) [+a:hirlevel.spammer.hu]
RCPT_COUNT_ONE (0) [1]
RCVD_COUNT_TWO (0) [2]
TO_DN_NONE (0)
GREYLIST (0) [pass,meta]
PREVIOUSLY_DELIVERED (0) [x@y.hu]
REPLYTO_DOM_EQ_FROM_DOM (0)
ARC_NA (0)
R_DKIM_ALLOW (0) [spammer.hu:s=hirlevel]
HAS_PHPMAILER_SIG (0)
FROM_HAS_DN (0)
TO_MATCH_ENVRCPT_ALL (0)
HAS_X_POS (0)
HAS_LIST_UNSUB (-0.01)
BAYES_HAM (-0.042393) [58.72%]
MIME_GOOD (-0.1) [multipart/alternative,text/plain]

Így van, egyetértek maximálisan. Csak RBL és IP nem elég, kell utána jó és karbantartott tartalomszűrő. De csak tartalomszűrővel csinálni DNS és IP előszűrés nélkül... Lehet, csak nem gazdaságos. Szerintem.

Igen, de én nem dobom el csak azért, mert szerepel egy listán.
Hozzáad a rossz minősítéshez és ha a a többi ellenőrzésen is kap fekete pontokat, akkor megy a reject.

Így az ilyen false listingek, hogy a Gmailt felteszik nem is kell foglalkoznom.

Nálunk a multi-rbl -es szolúció előpontozás alapú előszűrés jött be. Mögötte az SA és a ClamAV így is megőrül, mert szó szerint öntik be a fost a spamfarmok, feltört VPS-ek, zombigépek és minden hasonló.

Természetesen 1-1 reklamáció előfordul, de amikor a küldő oldal 2-3-4 rbl-en van fent és még csak normálisan se képesek beállítani a szervert, akkor mit kéne tegyünk? Az SA ugyanúgy fel fogja pontozni és a Junkba pakolja. Ekkor meg az a probléma, hogy "titokban" a Junkba került.

Ami igazán nagy gáz mostanság, hogy a fals negatívok száma érezhetően nőtt és ezek különösen malware-es, zsarolós történetek sajnos. Annyira sima emailnek néz ki, annyira 0-day (0-second) találnak meg néhány 100 vagy 1000 címet, hogy az RBL-ekig vagy vírusdb-kig el sem jut.

"Ami igazán nagy gáz mostanság, hogy a fals negatívok száma érezhetően nőtt és ezek különösen malware-es, zsarolós történetek sajnos"

Én is ezt látom, az elmúlt fél évben megnőtt a spam áradat, technikailag nem spamek, kézzel kellett a content filter pontszámokat növelnem, hogy megfogja őket.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

technikailag nem spamek

ez mi? :-)

--
O1G

hát valójában ők kérték ezeket a reklámokat :-)

Idézet:
Az SA ugyanúgy fel fogja pontozni és a Junkba pakolja. Ekkor meg az a probléma, hogy "titokban" a Junkba került.

Én mindig úgy állítottam be, hogy az SMTP kapcsolat közben ellenőrizzen, és ha valami nem tetszik neki, akkor SMTP reject, nem veszi át kézbesítésre. Semmit nem tesz a junk-ba, hanem a küldőnek a saját mail szervere majd küld egy választ, hogy sikertelen volt a kézbesítés.

Szerintem ilyen esetekben már tényleg csak az a jó megoldás, hogy a userek reportolhatják a levelet (ld. protonmail phising report), amire te így-úgy-amúgy reagálsz. Mondjuk 3-5 ugyanolyan levélre érkezett report után az összes hasonlót tiltod/késlelteted manuális ellenőrzésig. Persze technikailag sohasem csináltam még ilyet, fogalmam sincs, hogy egyáltalán könnyen meg lehet-e valósítani, hogy tényleg használható lesz-e stb., csak elmélkedem.

Illetve még az a furcsa ötlet jutott eszembe, hogy a már verifikált, hasonló levél után még be lehetne nyúlni a fiókokba, és az illeszkedő mintákat "utólag" kivenni, törölni. Spam/phising utógondozás :D

A Gmail spam szűrése alapvetően így működik. Amire sokan nyomják meg a spam gombot, az spam lesz. Ha nagyon-nagyon sokan nyomják meg, akkor meg se kapod.

--
https://iotguru.live

Ez oké, tudom, vagyis feltételeztem az eddigi tapasztalataim alapján, a kommentem inkább arra irányult, hogy ez a funkcionalitás a nagy játékosokon kívül a földi halandó, kis-közepes levelező szervert üzemeltetőnek megvalósítható-e, és ha igen, akkor mik azok a toolok, amikkel ez megvalósítható és amik ezt támogatják. Tudtommal nincs ilyen univerzálisabb tool, amit simán alácsapnál az MTA-dnak meg a frontendednek, és voilá, kész is a user report+karantén workflow-val, mindennel funkció az egész levelezésedben.

Nincs. Itt a piaci rés, hogy ilyen IP alapú baszkolódások helyett be tudj küldeni levelet, mint spam, illetve be tudj küldeni content-et, amire pontozni fog. :)

--
https://iotguru.live

A Razor/Pyzor ilyesmit próbál és talán a DCC is (ha ez még létezik). :) Amilyen tempóban változtatják ezeket, igen nehéz ügy.

guglis motyo torzseben szerepel-e link holmi track-server-100.com -ra ?

--
HUP te Zsiga !

Nem.

Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66])

--
http://blog.htmm.hu/

nem a fejlec volt a kerdes.

--
HUP te Zsiga !

Akkor nem ertettem meg a kerdest. Mit kellett volna ertenem?

--
http://blog.htmm.hu/

>> torzs <<

--
HUP te Zsiga !

Ott a vizsgalt spamban nem volt semmi ilyesmi.

--
http://blog.htmm.hu/

Kell egy SA meta szabály, ami a BAYES_50+ -nál kvázi nullázza az SPF és társait. :)

ha raklikkelsz a details gombra, akkor szokott lenni egy link a spamlista sajat lookupjara, ahol megnezheted bovebben hogy miert tiltottak le. es szokott lenni info hogy van a delisting.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Rakd fel whitelistre a google ip címeit, valami sugojukba fent van az összes nekik. Többet nem igen lehet tenni. És ez nem új, már pár éve találkoztunk ezzel először.

Amúgy mit tehet ez ellen a GMail? Tudtommal nem lehet robot módjára tömegesen körleveleket kiküldeni pl. v1agra reklámmal. Azt nem tudom, hogy van-e a kimenő leveleken is olyan AI-s spamszűrő, mint a bejövőn. És az normális-e, ha valami vicces/rosszul gépelő GMail user küld egy levelet egy spamtrap címre, és ez miatt kb. 1 milliárd ember kerül blacklistre? Az a blacklistet minősíti.

Mi is időnként szembesülünk hasonlóval, G Suite és előfizetés ide vagy oda. Komolyabb RBL-eken nem szoktak fent lenni (bár látom, ez épp itt nem igaz, a SORBS-on lenni már tényleg szopás :( ), de akad pár ahol felbukkannak időről időre vagy éppen permanensen fent vannak. Szvsz az utóbbi 3-4 évben kevesebb erőforrást fordítanak erre Google-éknél, legalábbis a nem meghatározó listák esetén a delistre tuti, és ez olykor okoz gondokat. Ez egy elég kimerítő és tényleg hasznos válasz a témában: https://support.google.com/a/answer/27642?hl=en

Amit ilyenkor tenni lehet, az mindenképpen az, hogy jelzed a G Suite adminjai felé a szokásos helyen (admin.google.com -> jobb fent kérdőjel, contact support), illetve én még írni szoktam az érintett domain postmaster@ és abuse@ címeire is. Ugyebár ezeket monitorozza a Google, szóval eljut hozzájuk az info (btw. érdemes ezekre "feliratkozni": https://support.google.com/a/answer/33389). Ez alapján még csak egyszer jött számomra válasz (kb. tízből), de úgy érzem megéri így is.

Hát a SORBS alapján pont nem jó gyakorlat automatikusan elutasítani, mert a saját bevallásuk szerint is túl szigorúak, és azt ajánlják, hogy csak a content filterben való felpontozásra használják a találataikat, ne automatikusan elutasító blacklist-ként.

A nagy volumenű ismert küldők (Facebook, Outlook, Google, Yahoo, stb.) IP címeinek nagy része fent van a SORBS-on (a kisebb szolgáltatókról nem is beszélve), így az alapján eldobálva a kapcsolatokat nagyjából sehonnan sem fog levél bejutni tapasztalatom szerint.

SORBS... Annak idején hónapokig mindenre pozitív választ adott. Egy hulladék, csak a bajt csinálja.

Félre ne értsetek, de ha én meglátom egy cég saját domain-es weboldalán a kapcsolatok között, hogy gmail -t használ levelezésre, rendesen felröhögök...
Van saját domain, van tárhelyszolgáltató... Mi állítja meg, hogy a saját domain nevét használja levelezésre?
Kicsi a tárhely? Akkor a gmail sem lesz sokáig elég!

s ha freemail vagy t-online van ott akkor mit teszel ?

btw kis cégnél lehet hogy régről megmaradt bejáratott email cím (fentiek) megmaradtak. Nem egy ilyen céggel találkoztam. Azt ismeri minden ügyfél, stb.

Nem ördögtől való azért ez.

Felmatricázott dobozos kisteher:

Dárga a matrica... :-P

Az aki freemail-t használ üzleti levelezésre meg is érdemli.
A t-online címet padig nem is minősítem inkább. Még szolgáltatásnak sem nevezném.

"Azt ismeri minden ügyfél, stb."
Értem én, de attól még hogy a gmail cím a bevezetett, pl a gmail címet lehet használni ingyen is úgy, hogy a saját domain látszik.
Szépen lassan rászoktathatók a saját domain-re.

> pl a gmail címet lehet használni ingyen is úgy, hogy a saját domain látszik.

Hat fogadni meg csak-csak lehet valami ingyenes redirect MX szolgaltatassal, de kuldeni mar nem nagyon. Es az sokkal ganyabb es megbizhatatlanabb mint egy rendes gmail.

Ebben tévedsz: anno volt ingyenes g-suite regisztráció, amihez lehetett akár több domain-t is kapcsolni. Az ingyenes regisztráció egy idő után megszüntetésre került, de akiknek már volt, az továbbra is ingenesen használhatja saját domainekkel a szolgáltatást.

Igen, én is aktívan használom még. De jó ideje már megszűnt, szóval maradjunk annyiban, hogy 2019-ben elég félreérthető ezt így leírni :)

Te mennyiért szolgáltatsz? Kellene mondjuk 1 TB mail és drive tárhely, 7/24 support, drive szinkronizálás mobilra, laptopra. Ez mennyi nálad?

--
https://iotguru.live

Én nem szolgáltatok pénzért senkinek, bár néhány barátnak nálam van a levelezése és weboldala.
Nem adom meg melyik tárhelyszolgáltatónál de ennyiért lehet jó szolgáltatást kapni 7/24 supportal "csak" tárhelyet levelezéssel:

1 domain/10 aldomain
100 GB tárhely
korlátlan adatforgalom
korlátlan email
korlátlan adatbázis
SSL tanusítvány
Shell konzol (+ előfizetés, de van!)
DNS hozzáférés, saját adminisztráció

6900Ft/hó+áfa

2015-óta vagyok az ügyfelük.
Van a tárhelyemen saját felhőm (nextcloud), ezért nem kell a google szinkronizálást használnom.
Ott tartok mindent, a gépeimen alig vannak adataim. Csak amit még nem szinkronizáltam.
Minden segítséget megadtak, amire szükségem volt eddig.

Egyébként ha neked ekkora tárhely kell, akkor inkább VPS-re van szükséged. Azt pedig más árkategóriában kell keresned.
Céges tárhelynek használni a GDrive-ot szerintem eléggé veszélyes.
Akkor is ha fizetsz + tárhelyért.

"6900Ft/hó+áfa"

Na, ez egyrészt nem elégséges szolgáltatás, másrészt pedig drága.

"Egyébként ha neked ekkora tárhely kell, akkor inkább VPS-re van szükséged."

2 TB storage az most $10 pénz. Mondanál egy VPS-t, ami ennyiért elérhető és van backup plan is?

"Céges tárhelynek használni a GDrive-ot szerintem eléggé veszélyes."

Miért is?

--
https://iotguru.live

Semmi gond...
Igazad van...
Használd egészséggel.
Nem akarlak meggyőzni, azt használsz ami neked jólesik.

Szóval nem kapok annyi szolgáltatást, ráadásul drágább, de valami bővebben ki nem fejtett conspiracy miatt használjam. Remek.

--
https://iotguru.live

Nem kell mögélátni semmit.
Egyszerűen nem akarok veled vitatkozni. Teljesen mindegy mit mondok, neked ígyis-úgyis lesz valami ellenérved.
Az hogy valamiért kevesebb pénzt adsz, nem azt jelenti hogy olcsó!

Nem fontos válaszolnod.

Baszki, ha valamiben nem értünk egyet, akkor vita már csak arról szól, hogy érvek és ellenérvek követik egymást. Az a fajta kommunikáció, amit űzöl, az pusztán időhúzás, mert abból áll, hogy kinyilatkoztatsz, majd ha valaki megkérdőjelezi az állításod, akkor nem akarsz se vitázni róla, se szimplán tényeket felsorolva érvelni mellette.

--
https://iotguru.live

Az az érzésem, hogy az aktivista gondolkodásmód legalább annyira öli az agysejteket mint a kóros alkoholizmus.

A gúgle az kurvaanyád. Ha azt használod, netán racionális érvet hozol fel szolgáltatásainak használata mellett akkor te a nép ellensége vagy, imperialista ügynök és osztályáruló.

el kene engedned...

--
O1G

Én azonnal amint egy reális alternatívát mutat valaki hasonló áron.

Több olyan nagyobbacska (több tíz ezer embert foglalkoztató) multinál láttam, hogy a korábbi saját infrastruktúra után vagy a google suite vagy az o365 irányba állították át a levelezést.
Saját domain nevüket megtartották, de attól még a google illetve a microsoft szervereinek az IP címe látszik.

Javíts ki, ha tévedek, de a fent említett lista az IP cím alapján dolgozik, nem a domain nevet nézi.

/off
Van olyan ember (nem a hozzászólóra utalok ^^) , aki
komplett webes szolgáltatásokat / email szolgáltatást ad el úgy, hogy konkrétan a garázsban megy egy szerver + UPX/Teleszom/bármiegyéb neten lóg az egész történet.

S mikor meg akarod neki magyarázni hogy ez így nem biztos hogy jó, akkor jön a megdönthetetlen "mermérnemjó_működik" érvvel ..:/

/off

Értem és tudom mi alapján blokkolnak leveleket, de akkor is minimum megmosolygató és komolytalan, ha egy cég ennyit nem hajlandó költeni.
Ha ezt egy több 10 ezer fős cég csinálja az még szánalmas is egyben.
Szinte majdnem mindegy mivel foglalkozik a cég, biztos hogy szükség van belső hálózatra, HR, Raktár, Gyártásirányítás (ERP) stb.
Ezekhez biztosan kell IT dolgozó, de inkább csapat. Szóval elég érdekes cégek lehetnek.

Egyáltalán nem biztos, hogy olyan mélységben akarnak IT-vel foglalkozni, dedikált adminnal és társaival. A rendelkezésre állásról nem is beszélve. Ez is a kiszervezés egy formája.

Azt csak halkan jegyzem meg, hogy azért masszívan kell egy O365-öt vagy Gugli mailt is piszkálni, ha sok a felhasználód.

OK.

Naaagy cégnek (ráadásul masszívan IT-ra épül gyakorlatilag minden üzleti folyamatuk) o365-ös a levelezése, és van rajta masszív rate limit, csak hogy örüljön neki mindenki... Amikor egyben ki kéne tolni nekik párezer valid, workflow szerint egyedileg, egy adott napon legenerált levelet, akkor azért érdekesen fel tud duzzadni a küldő oldalon a queue...

Idézet:
biztos hogy szükség van belső hálózatra, HR, Raktár, Gyártásirányítás (ERP) stb.
Ezekhez biztosan kell IT dolgozó, de inkább csapat. Szóval elég érdekes cégek lehetnek.

Nem tudom, mi alapján következtetted ki, hogy nincs IT.

Van. Eddig a levelezést is ők üzemeltették. Most meg előfizettek egy üzleti szolgáltatásra.

Nem teljesen értem a "cég ennyit nem hajlandó költeni" részt sem. Mennyit?

Ezek a cégek nyílt részvénytársaságok. Kötelező úgy dolgozniuk, hogy a részvény árak felfele menjenek, ehhez pedig a legegyszerűbb út a plusz bevétel és alacsonyabb költségek = magasabb profit.

Ha üzemeltetheti a saját IT saját gépen a levelezést, és az kerül X-be egy évben, vagy üzemeltetheti valamelyik nagy cég, mint Google vagy Microsoft, és az Y-ba kerül és az Y láthatóan kevesebb, mint X, akkor elgondolkozik az, aki adja a pénzt. Mi legyen? Ugyanazt a szolgáltatást kapom. Fizethetek többet, és simanzoli szerint komoly cég vagyunk, vagy fizethetek kevesebbet, és akkor simanzoli szerint komolytalan, megmosolyogtató és érdekes a cég. Mi számít nekem és a főnökeimnek többet, megtakarítani néhány száz vagy ezer vagy millió pénzt egy évben, vagy simanzoli véleménye? Hmmm... Nehéz döntés.

Kozel 70K alkalmazottal alltunk at O365-re on premis lofasz notes-rol.

Megvaltas volt.

Plusz egy nagy ceg eseteben az email az egy aktiv platform resze es nem egy pop3 mail meg egy tunderbor kliensbol all.

A lótusznótuszhoz képest szerintem bármi megváltás, még a kitekintő365 is... Bár szerencsére jó ideje nem láttam az előbbit közelről :-)

+sok

És mi van akkor, ha saját domainjével használ gmailt a levelezésére? Mert erre is van lehetőség fizetéses konstrukcióban.

> gmail -t használ levelezésre
> Mi állítja meg, hogy a saját domain nevét használja levelezésre?

egész eddig meg voltam győződve róla, hogy a gmailt lehet saját domainnel használni, fizetett supporttal, stb.

ezek szerint valami csalónak utalok egy rakás pénzt minden hónapban :(

ugy erted, egy mikroszoftos nem o365-ot, hanem g-t hasznal?

--
O1G

úgy érted, egy ex-microsoftos nem használhat más szolgáltatót egy olyan hobbiprojekthez, amiben rajta kívül senki sem ex-microsoftos? :)

szerk: amúgy nem olyan nagy csoda ez, akkor is használtam egy csomó konkurens terméket, amikor ott dolgoztam, csak az kevésbé triggerelte a huppereket, így nem tűnt fel

szerk2: mondjuk o365-öm is van, ha valakit érdekel

remelem, jo darabig listazni fogjak a kocsog gaymail-t...

--
O1G

Csak a kommentek olvasása után néztem meg a blacklist summary-t, és akkor láttam, hogy csak a SORBS-on van fent (meg egy oroszon, de nem hiszem, hogy az alapján dobták), és spamtrap hit miatt (ami a legnagyobb genyóság egyébként - mert valaha volt, csak azóta megszűnt címeket használnak ilyesmire sokan, nem az eredetileg szánt, elírással sem előállítható címeket).

Annyit tudsz tenni, hogy az ügyfél fogadó szerverének rendszergazdájának jelzed, hogy a SORBS alapján ne utasítsák el a leveleket (mint ahogy mondjuk a zen alapján teszik), hanem engedjék tovább a content filter-ig. Úgy vagy megkapja az ügyfél, vagy elő tudják szedni a karanténból. De mindenképp lesz nyoma, hogy jött volna valami.
Ezen felül mindenképp jelezd a Google felé. A hiedelmekkel ellentétben foglalkoznak vele, és aránylag gyorsan.

Kis adalék, hogy miért is furcsa ez az egész.

Scenario:
-Küldök levelet gsuiteos cimről a

-ra mondjuk 9:32-kor
-Az ugyfel.hu Mailscannert használ SA-val
-A levél viszont 1-3 óra késéssel jön meg, addig el se jut a célszerverig, tehát nem a Mailscanner adja hozzá a delayt, hanem már eleve késéssel jön meg a gmailtől (mintha saját maguk raknák rá a delayt)
-A beérkezett levél a Mailscanner szerint nem spam, nem fogja meg se a content filter, se a blacklist (ezért nem ér semmit, hogy felveszem a saját cimünket whitelistre a Mailscannerben)

-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Ha tippelni lehet, akkor valamelyik köztes SMTP szerver blokkolja IP alapon, a Google szervere próbálja újraküldeni pár alkalommal, aztán meg egy másik szerverről küldi el egy idő után, amit már vagy még nem blokkol a köztes SMTP szerver.

Olyat eddig nem vettem észre, hogy a Google nem küldi ki, kivéve, ha túlléptem a csúszóátlagos kvótát, de arról meg jön "550 5.4.5 Daily user sending quota exceeded". Szerintem nézd meg, hogy nem lépted-e túl te is, mert ha van egy lokál SMTP szervered, amelyiknek a Google a relay, akkor elő tud ilyen fordulni.

--
https://iotguru.live

Még néha ilyen is visszajön, ekkor nem ér oda a levél

Delivery incomplete
There was a temporary problem delivering your message to

. Gmail will retry for 45 more hours. You'll be notified if the delivery fails permanently.
The response was:

read error: generic::failed_precondition: read error (0): error
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Izémizé, ha GSuite, akkor az gondolom fizetős történet. A szapport mit mond ezekre?

Én O365-ös leveleknél láttam ezt. Egy másik cég küldte, de órákon át a MS meg se próbálta kézbesíteni. Aztán amikor igen, akkor meg fennakadt a greylisten, mert minden egyes alkalommal más IP címről próbálta küldeni. És baromi ritkán próbálkozott.
Az IP címeket fehérlistázva legalább a greylisten fennakadás által begyűjthető 2-10 órás késést sikerült elkerülni, de az Outlook365 továbbra is csak 3-4 órával a küldés után próbálkozott először.

A nagyokat érdemes illik blacklist és greylist kivételre tenni. Errefelé nagyon ritka a Gmail-ről vagy O365-ről jövő emailekkel a gond.

A Received from sorokbol kiderul, hol ucsorgott sokaig a level...

--
O1G