Freemail bannolás

 ( bb | 2015. november 25., szerda - 12:13 )

Sziasztok,

látom sokan velem együtt tehetetlenek a freemail spamszűrésével és megbízhatatlanságával, elérhetetlenségével szemben.
Gondolom kb 1-2 ember tartja életben az egészet, nem őket hibáztatom!

Esetleg nem lehetne figyelmeztető sztrájkot folytatnunk a freemail-el szemben mindaddig, amíg nem változtatnak?

vagy a tőlük beérkező levelek tetejére tolni egy a megbízhatatlanságáról szóló szöveget?

BB

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

Sztem az egy szolgaltato reszerol az ilyen jellegu megnyilvanulasok elegge gagyisztikusnak hatnak. Mindig meglepodok amikor egy site pl. keptelen beallitani a mara mar szabvanyos technologiakat (SPF, DKIM, DMARC) es nyilvanosan hisztizik hogy ez vagy az a szolgaltato milyen rossz. Na az ilyen sztrajkolas kb hasonlo szinten van.

A felhasznalo leveleibe belenyulni pedig egy abszolut no-no. Ha torvenyt nem is sertesz vele, de az a level nem a tied, hanem a felhasznaloe.

Ha nagyon nem boldogulsz a Freemail spam szuresevel, keress meg privatban, lehet hogy fogok tudni segiteni, ugyanis foglalkoztam azzal a rendszerrel egy keveset.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Node itt a probléma az, hogy hiába állítasz be bármit, hiába vagy okos, ha valamiért és nem tudod meg hogy miért, spamnek jelölnek akkor annyit mondanak hogy DATA rejected és kész.

Az én teljesen normális, hétköznapi leveleimet a Gmail nézi rendszeresen spam-nek. Vannak tippjeim, hogy miért, de azért elmennek a fenébe:

- gmail-es címről, de nem a webes felületről, hanem a szolgáltatóm SMTP-jéről küldöm a levelet

- mail klienst használok, de nem a leggyakoribb Thunderbird-öt vagy Outlook Express-t, hanem Claws Mail-t

- mindezt azzal fokozom, hogy nem a desktopon leggyakoribb Windows-ról, hanem Linuxról küldöm, de ott sem Ubunturól, hanem Fedoráról

Gondolom, ezzel eléggé kilógok a sorból, a Google meg úgy van vele, ami szokatlan, az nyilván spammer. Pedig nem. Viszont az ismerőseim néha hetek múltán veszik észe a leveleimet a spam-ek között. Nem mondom, hogy ennek örülök.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az elso pont a Gmail szerint eppen eleg ok arra, hogy spam-nek jelolje a leveled.

"- gmail-es címről, de nem a webes felületről, hanem a szolgáltatóm SMTP-jéről küldöm a levelet"

Ez nem csak a gmaillel nem fog mukodni, hanem sehol mashol sem, pl az en szerverem is spamnek fogja jelolni a leveleidet. A gmailnek be van allitva SPF/DMARC rekordja, ami egyertelmuen kimondja, hogy ha valaki gmailes envelope senderrel kuld nem gmailes szerverrol, az kukaba valo. Ezt a szolgaltato szervererol valo levelkuldosdit igy 2015 vegen el kellene felejteni, minden tisztesseges mail szolgaltato, pl. a gmail is, biztosit SMTP szervert a sajat postafiokjaira.

Allitsd be helyesen a levelezoprogramodat es akkor ez jo esellyel nem lesz problema.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ennek mi az oka? Tudom, le vagyok maradva, ezért kérdezem. Korábban az volt, hogy open relay ne legyen, tehát csak mindenki a saját szolgáltatójának smtp-jén keresztül levelezzen. Ez érthető, mert így az isp meg tudja fogni azokat user-eket, akiknek a gépéről - akár tudtukon kívül - ömlik ki a spam, hiszen a saját smtp-jükre lehet kvótát állítani, más smtp-hez meg nem engednek csatlakozni. Ez így miért nem jó megoldás? Ezen elv miatt adom meg smtp-nek a szolgáltatómat.

Beállíthatom ugyan a Gmail smtp-jét a kliensben, de halványan rémlik, hogy nyomulós a Google a privacy sértés, profilozás terén, s pop3-at, imap-ot lehet csak úgy, de smtp beállításhoz az én „biztonságom” érdekében elkéri az IRL telefonszámomat. Erről viszont szó sem lehet. Mi hát a megoldás?

Különben azzal nincs bajom, ha a levelem spamnek van minősítve, de a címzettnek módjában áll biztonságos forrásnak jelölni, ha úgy tetszik, tanítani a spam szűrőt.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ennek az az oka, hogy az SMTP eredetileg semmifele ellenorzest nem biztosit arra, hogy valaki jogosult-e azzal a mailcimmel kuldeni. Ennek kovetkezteben aztan barki barkit meg tud szemelyesiteni, lasd a masik aktualis topicot. Ennek a kivedesere keszult az SPF technologia, aminek megvannak a maga bajai, nevezetesen hogy 1. a From fejlecet senki nem ellenorzi, az envelopeot meg csak az latja aki belenez a fejlecekbe. 2. a forwardolt mailek kezelese problemas. Ugyan van SRS, de azt agyloves implementalni.

Eppen ezert a normalis szolgaltatok manapsag a 465-os porton biztositanak egy SSL-el titkositott lehetoseget arra, hogy levelet kuldj mas halozatbol is, igy biztositva azt, hogy mindenki azon a mailszerveren keresztul kuld, ahol a postafiokja lakik, konnyen ellenorizhetove teve a forrast es beallithatova teve az SPF headert. A szolgaltatoi mailszerverek egyebkent is iszonyatosan problemasak, a T csoport kimeno mailszerverei pl rendszeresen kulonbozo blacklisteken vannak, mert a tomegek keptelenek a lopott vindozaikat virusmentesen tartani. Lekorlatozni meg nem lehet, mert akkor sir az ugyfel.

Magyaran ha kuldeni akarsz, akkor ket opciod van:

1. Hasznalod a gmail SMTP szerveret.
2. Veszel egy sajat domaint es keresel egy tisztesseges mailszolgaltatot.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Köszönöm az infót, hasznos volt! :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ráadásul a Gmail-hez jár azonosításos SMTP, illik azt használni.

+1 Illetve ott legalább menni fog rendesen SSL-en keresztül is ;)

Kicsit bovebben kifejtve a kerdest: http://hup.hu/node/144198

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Köszönöm, épp az imént olvastam végig a blogbejegyzésed! Nem vagyok rendszerüzemeltető, csak szoktam segíteni tűzoltásban kis cégnél, s az utóbbi időben megszaporodott a jelenség, hogy a céges, egyedi levelek, amelyek például rendelés visszaigazolások, tehát nem spam, nem is tömeges, a címzettnél spam-be kerül. Elsőre arra gondoltam - szerintem nem alaptalanul -, hogy a T-től kimenő levelek blacklist-en vannak, mivel sok felhasználó nem tartja karban a gépét, így a T SMTP-je könnyen feketelistára kerülhet. Ezek szerint bőven nem csak ez volt a baj.

Nagyot változott a világ, mert én még mindig ott tartottam, hogy a szolgáltató SMTP-jén illik levelet küldeni, aztán dehogy.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Ugyan van SRS, de azt agyloves implementalni."
Frappánsan összefoglaltad. :D

"Erről viszont szó sem lehet. Mi hát a megoldás?"
Olyan szolgáltatót használsz, akinél megfelelnek neked a privacy irányelvek, ezért tudod normálisan használni?

Van tipped olyan ingyenes, mail klienssel pop3-on és imap-on használható szolgáltatóra, amelyik jó eséllyel hosszú időn keresztül megmarad, jól használható, nem fél nap múlva érkezik meg a levél?

Aztán, mi van, ha Gmailről automatikusan forwardolom a leveleket ide, majd reply-jal válaszolok? Akkor rendben lesz a header, legalább is nem lesz spam-gyanús?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

google? :)

Viccet félretéve, szerintem ezt a legtöbb nagy szolgáltató tudja, mivel láthatólag nem technikai a problémád, hanem valamiért nem bízol annyira a googleben, ezért nem tudom helyetted megítélni. (Azt mondjuk nem nagyon értem, hogy a telószámod authoz nem adod meg nekik, mert nem bízol bennük, de a komplett levelezésed rájuk bízod.)

legtöbb nagy szolgáltató tudja

Konkrétan melyek ezek?


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

mittomén, google, ms, yahoo, többiek? Mondjuk lehet a pop3at nem. Nem nekem nem tesztik a google.

Idézet:
Beállíthatom ugyan a Gmail smtp-jét a kliensben, de halványan rémlik, hogy nyomulós a Google a privacy sértés, profilozás terén, s pop3-at, imap-ot lehet csak úgy, de smtp beállításhoz az én „biztonságom” érdekében elkéri az IRL telefonszámomat. Erről viszont szó sem lehet. Mi hát a megoldás?

Nem kell megadnod a Google-nek a telefonszámod, sőt, semmilyen telefonszámot, sőt, semmilyen telefonszámot helyettesítő számot sem.

:)

Jó, ez egy régi emlékem, volt, amikor ezzel kekeckedett, de már elmúlt. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A kekeckedés tulzás, megkér, hogy add meg ha akarod, de ott a cancel gomb is.

ekozben a digi meg letiltja a kimeno mail portokat vagy mi volt multkor itt egy blogban...

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A 465-os portot tiltjak? Linkelj mar, ez elment mellettem!

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

az kimenő 25-ös portot tiltják, ahogy a upc és a té is.

csak átmeneti zavar lehetett az erőben az adott helyen
több kerületben is laktak az elmúlt 10 évben és mindig vittem magammal a Digi előfizetésem,
de még sosem blokkolták se a 587-es se a 465-ös portot sehol

Mindeközben a freemail. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A lentebb leírtakhoz képest van egy óriási különbség. Nem egy kövér rejectet kapsz a DATA után, hanem a Spam folderbe kézbesít és a fejlécben ott lesz, hogy SPF Fail, mert az XY szerver nem jogosult küldeni a gmail.com-os véggel. Ha esetleg a gmail rögtön visszadob, akkor is mindíg igyekeznek valami használhatót mondani, hogy példul túl sok email volt az órában vagy mittom.

hogy példul túl sok email volt az órában

Azt ugye vágod, hogy az a gmail-es "hibaüzenet", hogy túl sok email volt az órában, az egy generikus hasbaakasztós szöveg? Ha egy vírusos levelet próbálsz forwardolni egy gmailes címre, akkor ezt kapod. Ugyanazon levél a vírusos attachment nélkül gond nélkül bemegy akármikor, direkt teszteltem. Előtte-utána minden megy, a vírusos levélre viszont jön ez az üzenet. Hogy mi a faszért nem lehet normális hibaüzeneteket berakni, azt kurvára nem értem. Tiszta májkrémszoft b+..

Eddigi tapasztalataim szerint nagyjából rendben voltak, bár amikor az IPv6-os tesztemen hisztizett be a gmail, akkor szomorú lettem.

Alapvetően nem a tiltással van baj, az előfordul a legjobb családban is, hanem azzal, hogy képtelenek implementálni a szabványos visszajelzéseket és nulla supportot adnak egy sokak által használt szolgáltatásra

Természetesen az általad említett összes szabványos technika (SPF, DKIM, DMARC) implementálva van.

Az szerintem nem megoldás, hogy egyszercsak 550 5.7.1 Command rejected lesz egy addig elfogadott küldőből minden detektálható ok nélkül.

Ezt nevezhetjük nyilvános hisztinek, de ha egyszerűen nincs kit elérni ez ügyben, akkor hogyan tovább?

"akkor hogyan tovább?"

Pl. Amint a címzett @freemail.hu, a küldőnek még küldés pillanatában hibaüzenetet írni, hogy xy okok miatt ide nem tud levelet küldeni. A partnetről kérjen másik e-mail címet.

Ez nem is rossz ötlet. :) Egy napra kipróbálom majd. :)

a gts datanet ugyanezt a rendszer használja. próbálj meg egy datanetes címre írni (pl. az info-ra) visszapattan, aztán rögtön irhatsz nekik. gyorsabban reagálnak is és leszedik. ls ha iott leszedik a freemailen is leszedődik.

ez biztos?

--
"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)

Gyakorlatilag így megy. Az, hogy ez ténylegesen egy rendszer, vagy hogy ha egyikből leszedik akkor leszedik a másikból is, azt nem tudom.


MikroVPS Black Friday:
BF50 kupon: 50% kedvezmény minden OpenVZ VPS-re
BF80 kupon: 80% kedvezmény minden magyarországi Cpanel tárhelyre

Attol hogy azonos a technologia, meg a Freemail csinalhatott maganak egyeb checkeket is.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ez lehet, de a gyakorlatba ezt tapasztaltam. Végülis egy cég...


MikroVPS Black Friday:
BF50 kupon: 50% kedvezmény minden OpenVZ VPS-re
BF80 kupon: 80% kedvezmény minden magyarországi Cpanel tárhelyre

Szia! Kipróbáltam, de az

-ról nem pattant vissza.

-ra küldve mint a huzat visszapattant reggel.
A gmail címemről is írtam az

ra és elég volt ha a kérdéses domain szerepelt a szövegben benne, már repültem. Ha szóközzel higítottam a szöveget, akkor nem jött vissza.

Helló,

"próbálj meg egy datanetes címre írni" -> @datanet.hu


MikroVPS Black Friday:
BF50 kupon: 50% kedvezmény minden OpenVZ VPS-re
BF80 kupon: 80% kedvezmény minden magyarországi Cpanel tárhelyre

Aha, így már izgalmasabb. Ez egyelőre a szerver logban van, a levél pedig a queueban.

Result: delayed, Status: 4.3.2 451 Temporary failure, please try again later.

Ez még lehet greylisting is.

Az lesz, 11 perc után kézbesítődött.

"a tőlük beérkező levelek tetejére tolni egy a megbízhatatlanságáról szóló szöveget"
Hát, ha az én smime-mal titkosított levelemet tolnád evvel szét, elég morcos lennék :)
(nem, nem használok freemail-t, csak szóltam: nem illik a mail body-t bántani - ellenben a tárgyat...)
--
PtY - www.onlinedemo.hu, www.westeros.hu

Sziasztok!

Tamás Péter vagyok a Freemailtől.
Innentől megtalálhattok ezen a portálon is, valamint e-mailben elértek a

címen. A regisztrációm célja, hogy elősegítsem a Freemaillel kapcsolatos problémáitok megoldását.
Ezt a kommentemet most át fogom másolni a többi topic-ba is, ahol találkoztam Freemaillel kapcsolatos problémákkal, ezért elnézéseteket kérem, hogy most nem válaszolok minden kommentre külön-külön személyesen, viszont igyekszem választ adni egyben minden felmerült kérdésre, problémára.

=== a Freemail spamszűréséről ===

A Freemail spamszűrése jelenleg a Cloudmark (https://www.cloudmark.com/en) spamszűrésén és számos külső blacklist együttműködésén alapszik.

A Cloudmark spamszűrője 0-100 pont közötti pontszámot ad minden levélnek.
Mi jelenleg azon leveleket dobjuk el, amik 100 közeli pontszámot érnek el, vagy kevesebb pontot kapnak, de szerepelnek egy vagy több BL-en. Azért nem írom le, hogy ez 98 vagy 95, mert ezen időről időre szoktunk mi is állítani.

Azok a levelek kerülnek a spam mappába, amik nem 100 közeli, de magas pontszámot értek el, vagy alacsony pontszámot kaptak, de fent vannak pontosan 1 BL-en (ha többön, akkor eldobjuk a levelet).

=== a Cloudmark spamszűrő technológiájáról, avagy mi alapján kap egy levél 0-100 pontot ===

A Cloudmark spamszűrő technológiájának lelke az ún. fingerprinting algorithm (https://www.cloudmark.com/en/press/new-cloudmark-fingerprinting-algorithm-rapidly-detects-and-blocks-email-borne-viruses).

Ez nagyon leegyszerűsítve, azt csinálja, hogy:
* apró elemeire bontja a teljes levelet, annak fejlécével, tartalmával együtt,
* “ujjlenyomatokat" készít a levél minden apró részéről,
* a levélhez tartozó ujjlenyomatokat megfuttatja az ujjlenyomat adatbázisában,
* ha talál spamnek vagy vírusnak jelentett ujjlenyomatot a levélben, elkezdi lefelé pontozni a levelet,
* ha sok negatív ujjlenyomatot talál vagy csak egyet, ami "nagyon negatív", az már 100 közeli pontszámot eredményez

Negatív jelzést egyedül a felhasználóktól kaphatnak az ujjlenyomatok.
Amikor egy felhasználó spamnek jelent egy levelet:
* a spamnek jelentett levelet elküldjük automatikusan a Cloudmarknak,
* a Cloudmark a levél ujjlenyomatait összehasonlítja a többi spamnek jelentett levél ujjlenyomataival, és hasonlóságot keres,
* azon ujjlenyomatokat, amit több különböző spamnek jelentett levélben is megtalál, megjegyzi, mint negatív ujjlenyomatot

Minek lehet ujjlenyomata egy levélben?
Bárminek…
* egy képnek (akár logónak, stock fotónak),
* egy szónak (akár cégnévnek),
* egy szövegrésznek,
* egy csatolmánynak,
* …

A Cloudmark ezeket intelligensen dolgozza fel, hogy pl a “Kedves XY” kifejezést még véletlenül se értékelje negatív ujjlenyomatként.

=== a tapasztalataink a jelenlegi spamszűrésünkkel ===

Sajnos vegyesek...
Egyrészt azt látjuk, hogy alapvetően működőképes ez az algoritmus: nem büntet ok nélkül.
Másrészt van olyan eset, amikor túlzónak érezzük a döntését (pl domain szintű tiltások).
Harmadrészt vannak olyan spammerek, akik egész gyorsan rátanultak arra, hogy hogyan tudják kijátszani.
Azaz egyszerre érezzük túl erősnek és túl gyengének a jelenlegi szűrésünket.
Ez egy probléma, ami egyaránt érint titeket is és minket is.

Remélem ezen a fórumon vagy e-mailben vagy egyéb módon kialakul közöttünk egy olyan párbeszéd,
amelyben a kritika helyett az érdemi megoldást tekintjük mindannyian közös célnak.

Kifejtem kicsit bővebben a vegyes tapasztalatainkat.

Azt látjuk, hogy a jelenlegi spamszűrésünk alapvetően nem büntet ok nélkül:
* a hozzánk beérkezett panaszokat kivizsgálva az esetek 90+%-ában a levelek eldobásának az oka az, hogy
** vagy csapda címekre is (nem tiszta adatbázisra) küldenek leveleket,
** vagy a felhasználók tömegesen jelentik spamnek a küldő leveleit,

Azt is látjuk, hogy a jelenlegi spamszűrésünk néhány esetben túlzó döntéseket hoz:
Például találkoztunk tárhelyszolgáltató céggel, akiknek a tárhelyein egyszerre voltak tömegesen reklámlevelet küldők, magán weboldalak és a cégnek a saját levelező szolgáltatása.
A közös az volt a náluk lakó összes kisebb szolgáltatásban, hogy a tárhelyszolgáltatótól küldött levelek láblécébe a cég automatikusan odarakta a tárhelyszolgáltató megnevezését.
Amikor ennél a tárhelyszolgáltatónál volt olyan időszak, hogy:
* volt nála olyan magán webhely, amit támadók feltörtek, és vírusos leveleket küldtek onnan,
* voltak olyan tömeges levelek, amit rajtuk keresztül küldtek, és sokan jelentették spamnek ezeket a leveleket,
akkor a Cloudmark arra tanult rá, hogy ezekben a levelekben a közös az, hogy mindegyik alján szerepel a tárhelyszolgáltató neve,
ezért elkezdett eldobni minden levelet, aminek az alján megtalálta ezt a nevet.
Ez azt jelentette, hogy a tárhelyszolgáltató cég által nyújtott személyes levelező szolgáltatásról küldött levelek sem érkeztek meg Freemailre.

Azt látjuk, hogy a jelenlegi spamszűrésünket még mindig ki tudják játszani a spammerek:
Ezen nagyon nincs mit részletezni, sajnos még mindig jóval több spam jut át a spamszűrésünkön, mint amennyit szeretnénk.
Ez ellen folyamatosan küzdünk, ahogy a spammerek is folyamatosan alkalmazkodnak.

=== mi a megoldás jelenleg? ===

Először is különböztessük meg a Freemail felé _tömegesen_ érkező leveleket 2 típusát:
* vannak adminisztratív levelek,
* vannak nem adminisztratív levelek (reklám célú, marketing jellegű levelek)

Adminisztratív levelek definíciója a mi olvasatunkban:
"azok a levelek, amelyeket logikus körülmények között a felhasználó sosem jelentene spamnek".

Ezek azok a levelek, amikért mindent megteszünk, hogy bejusson a felhasználóink inboxába.
Ha kell - és ha máshogy nem biztosítható ez -, whitelist-re tudjuk tenni azokat az IP címeket, ahonnan csak és kizárólag adminisztratív jellegű levelek érkeznek.
A whitelist lehetőségét felajánlottuk mindenkinek, aki ilyen jellegű problémával megkeresett minket, ez a lehetőség nyitott mindenki számára, akinek az adminisztratív levelei egyébként nem feltétlenül jutnának be a Freemailen inboxba. Ilyen például a fenti tárhelyszolgáltató cég esete.
A whitelist lehetőségnek a következő feltételei vannak:
* az adminisztatív leveleknek külön IP címről kell érkezniük, amin csak és kizárólag adminisztratív levelek érkeznek,
* amint megtaláljuk az első nem adminisztratív levelet, ami whitelist-es IP-ről érkezik, töröljük a whitelistről az IP címet, és nem adunk újabb lehetőséget visszakerülni ide (innentől ugyanannyi esélye van bekerülni ezeknek a leveleknek, mint bármely más levélnek)

Nem adminisztratív levelek esetén a következő a teendő a jelenlegi folyamataink szerint:
1. Küldjetek nekünk e-mailt az

címre (biztos, ami biztos, cc-be nyugodtan berakhattok engem is:

) a következő információkkal:
* küldő IP cím(ek)
* log részlet, amelyben látszik:
** a pontos hibaüzenet
** a küldés pontos időpontja
** a címzett
2. Ekkor mi feljegyezzük a panaszhoz tartozó:
* időpontot
* cégnevet
* kapcsolattartót és e-mail címét
3. Ha a panaszban nincs a nyomozáshoz elegendő technikai információ (lásd 1.), bekérjük ezeket
4. Elegendő technikai információ birtokában Freemail szerver oldali logot kérünk az eldobott levélhez (ebben van benne ugyanis a spamszűrő által elhelyezett kódolt string, amely az eldobás okának ujjlenyomatait tartalmazza)
5. A Freemailes szerver oldali logot elküldjük elemzésre a Cloudmarknak
6. A Cloudmarktól megkapjuk az elemzés eredményét
7. Az elemzés ereményét feljegyezzük a panaszhoz
8. Az eredménytől függően a következők lehetségesek:
* Ha nagy problémát látunk (pl vírus küldés):
** ezt jelezzük a küldő felé,
** kérjük, hogy ezt oldja meg, majd vegye fel velünk ismét a kapcsolatot
* Ha a küldőnek ez az első problémája nálunk:
** reset-eljük a hozzá tartozó ujjlenyomato(ka)t,
** megírjuk neki, hogy a probléma okát, és hogy min változtasson ahhoz, hogy a jövőben ezt elkerülje,
** megírjuk neki, hogy reseteltük
* Ha a küldő már korábban is járt nálunk hasonló problémával:
** megírjuk neki, hogy a probléma okát, és hogy min változtasson ahhoz, hogy reseteljük
* Ha csak admisztratív leveleket érint a probléma (ilyen még nem volt):
** reseteljük a hozzá tartozó ujjlenyomatot,
** ha már korábban reseteltük, és ismét fennáll a tiltás, és nem látunk nála problémát: whitelistre tesszük az IP címét
* Ha adminisztratív levelei is érintettek a problémában (ilyen előfordul):
** ha az adminisztratív levelek külön IP címről érkeznek, és más úton nem tudjuk megoldani, hogy beérkezzenek ezek a levelek (lásd a tárhelyszolgáltatós történet): whitelistre tesszük ezt az IP címét
** ha az adminisztratív levelek ugyanazon IP-ről érkeznek, mint a reklámlevelei, megkérjük, hogy ezeket szedje szét, és ezután reseteljük

Ennek a folyamatnak az átfutási ideje normál esetben 1-2 nap.

Többen írtátok, hogy az

-ról nem kaptatok választ.
Ezért elnézéseteket kérem, az utóbbi napokban ezek a levelek nem jutottak el hozzánk, ma reggel kezdtük el feldolgozni az időközben ide érkezett ~300 levelet.

=== miben látjuk a hosszú távú megoldást? ===

Amint lehet, szeretnénk elindítani a Freemail feedback loop szolgáltatását.
A feedback loop ugye azt jelenti, hogy:
* a felhasználói spam jelentések tényét elküldjük a levél küldőjének is
* a küldőnek innentől lehetősége lesz leiratkoztatnia az adatbázisából azokat a felhasználókat, akik spammernek értékelik őt,
* így a küldőnek lehetősége lesz folyamatosan magas reputációt fenntartani, és a levelei meg fognak érkezni az inboxba,
* amelyik küldő figyelmen kívül hagyja majd a feedback loop által küldött felhasználói spamjelentéseket, annak pontosan meg tudjuk majd mondani, hogy miért rossz a reputációja, és hogy tud ezen azonnal javítani.

Ez a szolgáltatásunk úgy gondoljuk megoldás lesz a jelenlegi problémára, miszerint a spamszűrőnk eldob leveleket azért, mert sok felhasználó spamnek ítéli ezeket a leveleket, de jelenleg nem tudunk érdemi segítséget nyújtani a küldőknek az adatbázisuk tisztításában.
Ez nyilván nem jelent megoldást a továbbra is beérkező sok spamre, de ha lesz feedback loop szolgáltatásunk, bátrabban erősíthetünk majd a szűrésünkön is.

Igyekszünk mielőbb publikálni a feedback loop szolgáltatásunkat, az indulásig a türelmeteket kérem (sajnos hónapokról beszélünk, nem hetekről).

Remélem segítettem, és tudok még segíteni nektek, ha folytatjuk a beszélgetést itt vagy e-mailben (még egyszer:

).
Szívesen bármi konstruktív hozzászólást, ötletet, tanácsot a témában, keressetek bátran.
Előre elnézést kérek, ha nem rögtön válaszolok, de legkésőbb 1-2 nap alatt reagálok minden felé érkező levélre.

A magam reszerol koszonom a kimerito es sok mindent megmagyarazo valaszt, nagyon pozitiv meglepetes.

A magam reszerol tobb tarhely es levelezo szolgaltato szervereit is karban tartom. Ami igazan fajo pont jelenleg, hogy mint rendszergazda es szolgaltato nem szerezheto ertesites a visszautasitas okarol es kesobb a pontos okozo sem volt pontosan beazonosithato. Erre a feedbacken kivul jo lenne valamilyen rendszert kitalalni, akar ugy is, hogy a szolgaltato regisztralhat hozzatok, hogy az adott ip cimek gazdaja. Csak a kuldonek irni levelet nem erzem, hogy eredmenyre vezetne es az elszabadult vagy megtort weboldalrol is jobb a szervert uzemeltetot ertesiteni szerintem.

A feedback loop pontosan ezt csinalja. Beregeled hogy tied az adott IP cim es levelet kapsz ha valaki spamnek jeloli a leveledet. Lasd: https://en.wikipedia.org/wiki/Feedback_loop_(email) A kuldo itt az IP cim tulajdonosat jelenti, nem a MAIL FROM cimet.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Oh, szuper. :) Kivancsian varom a bevezeteset.

Így van, a feedback loop bevezetésével tervezzük meglépni ezt.

Miért nem lehet (automata) értesítést küldeni ha egy ip-ről (szerintetek) spam jön az ip whoisában lévő abuse-ra (akár külsőn keresztül, spamcop, stb)?

De már az is jó lenne, ha elutasítás nem annyiból állna, hogy Command rejected, hanem (mint mindenhol máshol) megmondaná _nagyjából_, hogy mi a hiba. Mert a command rejected aztán akármi lehet.


MikroVPS

"Mert a command rejected aztán akármi lehet."

most lett elmagyarazva, hogy ket ok lehet :
1. 100 kozeli pontszam
2. eppen hatar alatti pontszam + 1 blacklist

ha nem vagy blacklisten, akkor tutti az elso.

Igen, mostmár tudjuk, de eleddig nem volt ez sehol leírva, senki nem tudta.


MikroVPS

Te is tudod hogy a whois szabvany mennyire ir elo pontos formatumot: semennyire. Az, hogy egy IP-nek mi a tenyleges abuse e-mail cime, human eroforrast kivan hogy ne spamelje szet a vilagot. Nem veletlenul nem csinal ilyet senki. A sender feedback loop a bevett technologia erre a feladatra.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Hát a spamcop, cloudflare meg atöbbi elég jól meg tudja oldani automatán is.

A spamcop gyk kidobja eled az osszes mailcimet amit a whoisban talal, plusz oda a netszolgaltatok regelnek es amikor ez megtortenik, akkor meg kell erositeni az e-mail cimet. Szoval egy picit mas teszta.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Én nem regeltem soha a spamcopra mint szolgáltató, mégis kapom tőluk az abusokat (nagyon helyesen).


MikroVPS

Mert mukodik az abuse cimed? :)

Szemmel lathatolag nem erted: a SpamCop nagyon sok energiat fektetett abba, hogy a rendszeruk kepes legyen kezelni, ha egy adott e-mail cim tulajdonosa nem ker levelet, pl mert semmi koze ahhoz a tartomanyhoz. Ha minden szolgaltato implementalna egy SpamCop-jellegu rendszert, ezen a szerencsetlen delikvensek postaladaja osszeroskadna es eselye se lenne mindenhonnan leiratkozni.

Arrol ugye nem is beszelve, hogy a SpamCop jelento pontosan tudja mit csinal, ezzel szemben az atlagusernal lattunk olyat, hogy a torles gomb helyett hasznalja a spam gombot (talan Te is emlekszel erre az esetre).

Ha a Freemail azt csinalna amit javasolsz, gyk szetspamelne a vilagot.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

A spam jelentésekről értesítést a feedback loop rendszerünk fog küldeni.

Abban egyet értek, hogy beszédesebb hibaüzenetet illene küldenünk a "command rejected"-nél.
Ez nem csak nektek lenne hasznosabb, de a mi munkánkat is könnyítené. Szerepel is ez a feladat egy ideje a fejlesztési terveink között, de eddig mindig akadt prioritásosabb feladat, ami tolta ezt maga előtt. Hogy bizonyítsam tettrekészségünket, most megpróbálom megsürgetni ezt a feladatot :)

A terveink szerint a reject üzenetben visszaküldenénk
* a reject okát: hogy spamnek néztük a levelet
* elérhetőséget, ahová fordulhattok ezzel kapcsolatban az alábbi kódsorral
* egy string kódsor, amit jelenleg manuálisan bányászunk ki az általatok küldött log részlet alapján a mi logjainkból

Ezzel a küldő fél is tájékozottabb lesz, és mi is megspórolunk a korábban írt folyamatunk a 8 pontjából hármat, ami így minimum 2 levélváltással rövidebb és ezzel gyorsabb lesz.

En egy idealis rendszert igy kepzelnek el:

1. visszadobott emailben benne van a reject oka, es egy generalt azonosito.

1.b) generalt azonositot ti elmentitek egy adatbazisba, amit 7 napig oriztek

2. a generalt azonositoval a targyban irunk egy levelet, amire kapunk egy automata valaszt, ami egy weboldalra visz, ahol amit szeretnetek kitolt az ember (azonositasi requestek, pl. domaint igazolod, hogy a tied, odateszel egy adott fajlt egy adott urlre, a mailszervert igazolod, hogy a tied, ahol valaszt kell kuldeni adott feladoval (pl. altalatok kuldott emailben levo 2 szamot osszeadva visszakuldeni), etc, etc).

2.b) A generalt azonosito 7 napig orzodik egy adatbazisban, utana dobjatok.

3. A fenti oldalra, akar regisztralni lehet, igy ertesitest is kaphatsz, ha sok spam jon a domainedbol.

A fenti egy azonosito rendszer es egy ticketing rendszer osszedolgozva.

Lehetne egyebkent ez penzugyileg onfenntarto is, csak egy elborult pelda:
lehet fizetni, hogyha egymas utan tobbszor kell kivenni valakit a spamlistabol.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Helyes, koszi. Par eve mar duhongtem rajta, hogy lovesem sem volt, megis miert nezte spamnek a levelemet (vagy ugyfelet, mar nem tudom)
Ja, megcsak ezt sem kozolte, csak a rejected volt.

" egy string kódsor, amit jelenleg manuálisan bányászunk ki az általatok küldött log részlet alapján a mi logjainkból"
Ezzel viszont nagyon sokat dobnatok, mashol nem lattam :) A nonpluszultra persze az lenne, ha a kuldott level kifogasolhato reszletet irnatok vissza :) De ez mar durva lazalom, asszem.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

<personal>
Szia Kond!!! :)

Örülök, hogy eljutott hozzád, szép, profi megoldás, gratula :)
</personal>

miota hasznaljatok a cloudmark-ot, ill. milyen versenyzoket utasitott maga moge ez a termek a lehetseges megoldasok sorravetelekor?

--
"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)

Majdnem pontosan egy éve használjuk a Cloudmarkot (hogy pontos legyek, Mailspectet használunk, akik Cloudmarkot használnak).
Előtte a Kaspersky szolgáltatta a spamszűrésünket, azelőtt pedig a Virusbuster (ami azóta megszűnt).

A Cloudmarkra egy nyílt tender keretén belül esett a választásunk. Hogy a tenderen kik vettek még részt, arról nem tudom mennyire írhatok, ezért inkább nem teszem. Több, mint 1 hónapon keresztül teszteltük a résztvevők szolgáltatásait, a Cloudmark jött ki győztesként.

kossz az infot. Esetleg privatban lehet tudni a teszteles reszleteirol? Azert faggatozom, mert en is fejlesztek egy spamszurot, es kivancsi vagyok, hogy egy nagyobb mail szolgaltato hogyan tesztelt, mire figyelt, mit hogyan pontozott, stb.

--
"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)

Reméltem, hogy eljutunk ide. Én is ezt javasoltam volna. Megérne egy tesztet a te rendszered is. Jobban mondva a teszt után 1:1-ben rárengedni a freemail levelezését és megnézni, hogy muzsikál. Őszintén kíváncsi lennék az eredményre.

Na arra en is ;-)

--
"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)

"Ezen nagyon nincs mit részletezni, sajnos még mindig jóval több spam jut át a spamszűrésünkön, mint amennyit szeretnénk."

Ezt alairom...Van 2 freemail fiokom, ahova csak es kizarolag spam erkezik, mindkettobe ugyanaz...Gondolom, msoknak is, nemcsak ez a ket fiok ilyen kiemelt. Midnegy, facebook regre jok voltak anno.

Masreszt: xy ceg kuld levelet. Van egy belso halon logo ticket-alkalmazas, ami eximen kuld, ez atadja egy mailproxy szervernek (centos7, postfix, kulso ip-vel) ami kikuldi a cimzettnek. Csak a freemailre nem erkezik meg. Ha az alkalmazas kihagyja a sajat smtp szerveret, rogton a mailproxyn adja fel, megerkezik. Erdekes.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

Nem azért a 10 forintért, de én már annak is örülnék, ha a tárgyban a pontok számát meg lehetne adni. A szűrő részben mint egyedi spam beállítás. A leveleim tömkelege kb ezt csinálja: "Pi.henesre va.gysz, most akci.ós a k.rva anyad is".

A retkes szavakat karakterekkel vagdaljak, belonem hogy ha tobb mint 3 huss a spam mappába.

Pontosan ezek a spamek ellen küzdünk jelenleg is. Bár a megoldást nem a subject-ben lévő pontok számlálásában látom.

sub