Forum » Omrežja in internet » SMTP promet
SMTP promet
b3D_950 ::
Mogoče kdo ve, če je smtp promet na amisu blokiran v ostala omrežja slo. ISPjev v obe smeri?
Npr. imam statičen IP na amisu in enega na telekomu ter na obeh svoj mail server.
Če pošiljam mail iz serverja, ki je na omrežju telekoma na svojo domeno (na amisu), dobim timeoute in obratno. Kot da server ne obstaja (ping in ostalo gre čez).
To pomeni, če mi hoče kdo poslat mail, ki je na siolu/tušu/t2, ne dobim nič.
Medtem, ko s tujino ni problemov (gmail, yahoo, razne mailing liste...).
IP ni na spam listi.
Npr. imam statičen IP na amisu in enega na telekomu ter na obeh svoj mail server.
Če pošiljam mail iz serverja, ki je na omrežju telekoma na svojo domeno (na amisu), dobim timeoute in obratno. Kot da server ne obstaja (ping in ostalo gre čez).
To pomeni, če mi hoče kdo poslat mail, ki je na siolu/tušu/t2, ne dobim nič.
Medtem, ko s tujino ni problemov (gmail, yahoo, razne mailing liste...).
IP ni na spam listi.
Zdaj ko je mir, jemo samo krompir.
- spremenil: b3D_950 ()
NeMeTko ::
Zelo čudno, da ravno promet, ki izvira iz SLO nebi prišel skozi.
Si preveril MX zapise, kako jih imaš postavljene? Kaj ti piše v logih mail serverja? Ti požarni zid zazna poskus povezave na smpt?
Si poskusil s telnetom na portu 25, če se ti poveže z mail serverjem?
Načeloma ne vidim razloga, da bi Amis ali SIOL blokirala normalni smtp promet na statičnih IP naslovih (pri dinamičnih je to bolj običajno).
Seveda lahko pokličeš helpdesk pa ti bodo takoj povedali, kaj blokirajo in kaj ne, vendar mislim, da imaš problem nekje drugje.
Ali pošiljaš svoje maile direktno v svet ali uporabljaš providerjev mail relay? Morda se tu skriva kakšen problem?
Jaz sem dolgo časa uporabljal T-2 mail relay za pošiljanje z mojega strežnika, pa sem ravno zaradi Amisa in podobnih, ki uporabljajo greylisting bil prisiljen to ukiniti, če nisem hotel vsak mail v ta omrežja/domene pošiljati po dva ali celo trikrat, predenj so bila tudi dejansko dostavljena.
Takrat se mi je greylisting kot antispam rešitev zameril do take mere, da bi ga prepovedal, butaste admine, ki ga uporabljajo pa tunkal v ljubljanico, kot so včasih goljufive peke.
Si preveril MX zapise, kako jih imaš postavljene? Kaj ti piše v logih mail serverja? Ti požarni zid zazna poskus povezave na smpt?
Si poskusil s telnetom na portu 25, če se ti poveže z mail serverjem?
Načeloma ne vidim razloga, da bi Amis ali SIOL blokirala normalni smtp promet na statičnih IP naslovih (pri dinamičnih je to bolj običajno).
Seveda lahko pokličeš helpdesk pa ti bodo takoj povedali, kaj blokirajo in kaj ne, vendar mislim, da imaš problem nekje drugje.
Ali pošiljaš svoje maile direktno v svet ali uporabljaš providerjev mail relay? Morda se tu skriva kakšen problem?
Jaz sem dolgo časa uporabljal T-2 mail relay za pošiljanje z mojega strežnika, pa sem ravno zaradi Amisa in podobnih, ki uporabljajo greylisting bil prisiljen to ukiniti, če nisem hotel vsak mail v ta omrežja/domene pošiljati po dva ali celo trikrat, predenj so bila tudi dejansko dostavljena.
Takrat se mi je greylisting kot antispam rešitev zameril do take mere, da bi ga prepovedal, butaste admine, ki ga uporabljajo pa tunkal v ljubljanico, kot so včasih goljufive peke.
NoName ::
@NeMeTko - T-2 ima greylisting na MXih le za tiste poredne serverje, ki niso baš v skladu z RFCji, pošiljajo veliko neželene pošte, nimajo urejenega PTR ter pripadajočega A (ali AAAA) DNS zapisa, ...
I can see dumb people...They're all around us... Look, they're even on this forum!
b3D_950 ::
MX, A, TXT:dkim/spf je ok. Edino reverse kaže namesto na mail.domena.si, na mail1.domena.si. Pošiljam direktno, če nastavim relay, zadeva gre skozi, obratno sicer ne...Telnet/traceroute na port 25 ne gre.
Log:
Sep 25 09:26:49 mail postfix/smtp[2963]: 0F30CA4A7B2: to=/test@telekom.si/, relay=none, delay=87329, delays=87269/0.01/60/0, dsn=4.4.1, status=deferred (connect to smtp1.telekom.si[193.77.55.37]:25: Connection timed out)
Log:
Sep 25 09:26:49 mail postfix/smtp[2963]: 0F30CA4A7B2: to=/test@telekom.si/, relay=none, delay=87329, delays=87269/0.01/60/0, dsn=4.4.1, status=deferred (connect to smtp1.telekom.si[193.77.55.37]:25: Connection timed out)
Zdaj ko je mir, jemo samo krompir.
NeMeTko ::
@NoName - ni bil problem nekih list na T-2 strežniku, temveč samega principa delovanja greylistinga na Amisovi strani (in drugih domenah, ki ta zlodja uporabljajo).
Greylisting izhaja iz predpostavke, da spammer ne bo pošiljal maila 2x, če v prvo ni šel skozi. Zato greylisting po defaultu zavrne poslan mail s sporočilom 'daj poskusi malo kasneje'. T-2 mail relay pa je ignoriral ta 'poskusi malo kasneje' in je mal lepo vrnil, češ da ni dostavljiv. Tako sem moral ročno ponovno poslati mail čez nekaj časa (še to ima vsak na svojem greylisting drugače nastavljeno) in preveriti, če je tokrat morda le šlo skozi.
Admini, ki uporabljajo greylisting, se izgovarjajo, da je to lepo po RFC-ju in da oni niso nič krivi, če mail relay od T-2 ne dela po RFC. Krasno, ampak meni to ne pomaga. Na izbiro sem imel le biti potrpežljiv in paziti na zavrnjena sporočila in jih ponovno pošiljati, ali pa ukiniti T-2 mail relay in pošiljati maile direktno z mojega strežnika, ki nima "problemov" z RFC-jem. Ko sem imel poven kufer (uporaba tega greylistinga se je prav butasto širila...), sem spremenil eno vrstico v konfig datoteki mail serverja in ga restartal....
Kljub temu, da mi sedaj ni več potrebno ponovno pošiljati sporočil, pa to mora delati moj mail server. Seveda zaradi tega mail ni promptno dostavljen, ampak z neko zamudo (odvisno od tega, kako je nekdo nastavil svoj greylisting - včasih celo 15 min!!!). Resda si potem greylisting za nekaj časa zapomni, da nisi nek grdi hudobni spammer, vendar mislim da se to kar kmalu pozabi in spet pristaneš na listi 'ne vem kdo si - dej pošlji mi še enkrat ...'.
Resnično ne vem od kod takšno navdušenje adminov nad tem greylistingom. Dejansko po nepotrebnem povečuje promet po omrežju, povzroča zamude pri dostavi in kar je še najhuje - zavrnjen mail je lahko izgubljen za vedno. Običajno (npr. gmail) se spam izloči v karanteno ali poseben spam folder, kjer lahko rešimo kakšen pomotoma za spam označeni mail. Pri greylistingu pa naslovnik nikoli ne izve, da mu je nekdo pošiljal sporočilo. Če še pošiljatelj spregleda, da je bilo sporočilo zavrnjeno, je to sporočilo izgubljeno.
Priporočam ti, da pokličeš support na Amisu in SIOLu, pa da preverijo, če ti filtrirajo port 25 v bilo kateri smeri.
S preprostim vprašanjem, si boš olajšal nadaljno diagnosticiranje, saj boš vsaj vedel, kje naj nebi rabil iskati faila.
Greylisting izhaja iz predpostavke, da spammer ne bo pošiljal maila 2x, če v prvo ni šel skozi. Zato greylisting po defaultu zavrne poslan mail s sporočilom 'daj poskusi malo kasneje'. T-2 mail relay pa je ignoriral ta 'poskusi malo kasneje' in je mal lepo vrnil, češ da ni dostavljiv. Tako sem moral ročno ponovno poslati mail čez nekaj časa (še to ima vsak na svojem greylisting drugače nastavljeno) in preveriti, če je tokrat morda le šlo skozi.
Admini, ki uporabljajo greylisting, se izgovarjajo, da je to lepo po RFC-ju in da oni niso nič krivi, če mail relay od T-2 ne dela po RFC. Krasno, ampak meni to ne pomaga. Na izbiro sem imel le biti potrpežljiv in paziti na zavrnjena sporočila in jih ponovno pošiljati, ali pa ukiniti T-2 mail relay in pošiljati maile direktno z mojega strežnika, ki nima "problemov" z RFC-jem. Ko sem imel poven kufer (uporaba tega greylistinga se je prav butasto širila...), sem spremenil eno vrstico v konfig datoteki mail serverja in ga restartal....
Kljub temu, da mi sedaj ni več potrebno ponovno pošiljati sporočil, pa to mora delati moj mail server. Seveda zaradi tega mail ni promptno dostavljen, ampak z neko zamudo (odvisno od tega, kako je nekdo nastavil svoj greylisting - včasih celo 15 min!!!). Resda si potem greylisting za nekaj časa zapomni, da nisi nek grdi hudobni spammer, vendar mislim da se to kar kmalu pozabi in spet pristaneš na listi 'ne vem kdo si - dej pošlji mi še enkrat ...'.
Resnično ne vem od kod takšno navdušenje adminov nad tem greylistingom. Dejansko po nepotrebnem povečuje promet po omrežju, povzroča zamude pri dostavi in kar je še najhuje - zavrnjen mail je lahko izgubljen za vedno. Običajno (npr. gmail) se spam izloči v karanteno ali poseben spam folder, kjer lahko rešimo kakšen pomotoma za spam označeni mail. Pri greylistingu pa naslovnik nikoli ne izve, da mu je nekdo pošiljal sporočilo. Če še pošiljatelj spregleda, da je bilo sporočilo zavrnjeno, je to sporočilo izgubljeno.
MX, A, TXT:dkim/spf je ok. Edino reverse kaže namesto na mail.domena.si, na mail1.domena.si. Pošiljam direktno, če nastavim relay, zadeva gre skozi, obratno sicer ne...Telnet/traceroute na port 25 ne gre.
Log:
Sep 25 09:26:49 mail postfix/smtp[2963]: 0F30CA4A7B2: to=/test@telekom.si/, relay=none, delay=87329, delays=87269/0.01/60/0, dsn=4.4.1, status=deferred (connect to smtp1.telekom.si[193.77.55.37]:25: Connection timed out)
Priporočam ti, da pokličeš support na Amisu in SIOLu, pa da preverijo, če ti filtrirajo port 25 v bilo kateri smeri.
S preprostim vprašanjem, si boš olajšal nadaljno diagnosticiranje, saj boš vsaj vedel, kje naj nebi rabil iskati faila.
Zgodovina sprememb…
- spremenil: NeMeTko ()
NoName ::
@NeMeTko, pol si pa tale relay preko T-2 mail serverjev imel že doooolgo doooolgo časa nazaj.. Če prejemnikov mail server sedaj zavrne sporočilo z napako 4xx, potem njihov server počaka nek default time, poskusi znova, in če spet ne more dostaviti sporočila, poskusi s podvojenim časom... in tako naprej vse do max backoff time; dokler se pošta bodisi ne dostavi ali pa doseže max queue time... Če pa je napaka s strani strežnika za dostavo 5xx, potem pa takoalitako ni druge, kot da mail server vrne bounce pošiljatelju.
I can see dumb people...They're all around us... Look, they're even on this forum!
Bakunin ::
preden karkoli napises ali komentiras glede e-posto si preberi RFC 2821/2822, kjer imas lepo napisano in definirano kar se sme in ne sme z e-posto.
http://www.faqs.org/rfcs/rfc2821
4.5.4.1 Sending Strategy
5. Address Resolution and Mail Handling
ce bi le ljudje BRALI sporocila o napakah.
http://www.faqs.org/rfcs/rfc2821
4.5.4.1 Sending Strategy
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days.
5. Address Resolution and Mail Handling
...
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds.
Če prejemnikov mail server sedaj zavrne sporočilo z napako 4xx,...
ce bi le ljudje BRALI sporocila o napakah.
Zgodovina sprememb…
- spremenil: Bakunin ()
NeMeTko ::
V idealnem svetu stvari laufajo tako, kot narekuje RFC, v realnem pač ne. (PIKA!)
Zlorabljanje neke posebnosti oz. možnosti, ki jo ponuja RFC za tak način filtriranja spama za moje pojme ni dopustno, saj se kaznuje uporabnike, ki nimajo prav nobenega vpliva na to, kako ima njihov ponudnik skonfiguriran mail server ali relay. Še bolj nedopustno je zavračanje maila, ki je namenjen tretjim osebam (npr. naročnikom Amisa), brez njihove vednosti o tem, kaj je bilo zavrnjeno. Za to obstaja spam tagging in spam karantene, da se lahko na koncu uporabnik sam odloči, ali je neko sporočilo spam ali ne - ne pa da se provider namesto njega in brez njegove vednosti odloča, da je spam tudi vse, kar pride s strežnikov, ki ne ustrezajo 100% RFC-ju.
Če bi se dobro načital, bi tudi prebral, da določeni starejši strežniki po defaultu niso kompatibilni z greylistingom in tako dobesedno drugi strani vsiljuješ nabavo novega strežnika? Čemu že? Če s celim svetom normalno komunicirajo, le z greylisting sistemi ne? Kaj pa nepotrebni overhead na omrežju, basanje mail queue-jev, zamuda v dostavljanju? Aja, to pa je v skladu z RFC. Morda pa ni v skladu z načeli smotrne rabe resursov? Kateri greh je sedaj večji?
Ravno tako smatram za aroganco in nesramen odnos do uporabnikov, če nek admin reče 'če bi ljudje brali sporočila o napakah'. Do sporočil o napakah sploh priti ne sme - za to si admin in tvoje delo je, da uporabniki ne bodo rabili brati teh sporočil, ne pa da uvajaš rešitve, za katere se VE, da niso 100% kompatibilne z vsemi mail sistemi in tako zavestno generiraš dodatna nepotrebna sporočila o napakah.
Pri vseh inteligentnih antispam sistemih, ki danes obstajajo (kdor pozna highend rešitve, bo vedel o čem govorim), je uporaba greylistinga eno navadno sprenevedanje ali pa nepoznavanje tehnologije. Kolikšna pa je dejanska učinkovitost greylistinga? Proti spam botu, ki pošilja preko regularnega smtp strežnika nekega providerja odpove na celi črti (razen če ta strežnik morda ni skonfiguriran po RFC?). Zato za borbo proti spamu potrebuješ dodatne mehanizme. Ti pa so danes že tako napredni in inteligentni, da ne potrebujejo več nobenega greylistinga.
@NoName - mislim, da je tega kakšnega pol leta, ko sem izklopil mail relay. Problem ni bil v običajnem pošiljanju mailov s kakšnega T-2 mailboxa, tisto gre na njihov smtp strežnik, ki očitno nima težav.
Težava se pojavi, kadar tvoj lastni smtp strežnik pošilja mail preko T-2 mail relaya. Pri tem relay sam ne poskuša izvajati ponovnega pošiljanja in uporabniku vrne sporočilo o nedostavljivosti. Nisem pa šel študirati RFC, če bi moral relay sporočiti smtp serverju, da sporočila ne more dostaviti, pa da bi potem moral lokalni server delati retry.
Če so v tem času kaj spreminjali na konfiguraciji ali celo postavili nov server, res nebi vedel (pa tudi ne bom šel preizkušati).
Zlorabljanje neke posebnosti oz. možnosti, ki jo ponuja RFC za tak način filtriranja spama za moje pojme ni dopustno, saj se kaznuje uporabnike, ki nimajo prav nobenega vpliva na to, kako ima njihov ponudnik skonfiguriran mail server ali relay. Še bolj nedopustno je zavračanje maila, ki je namenjen tretjim osebam (npr. naročnikom Amisa), brez njihove vednosti o tem, kaj je bilo zavrnjeno. Za to obstaja spam tagging in spam karantene, da se lahko na koncu uporabnik sam odloči, ali je neko sporočilo spam ali ne - ne pa da se provider namesto njega in brez njegove vednosti odloča, da je spam tudi vse, kar pride s strežnikov, ki ne ustrezajo 100% RFC-ju.
Če bi se dobro načital, bi tudi prebral, da določeni starejši strežniki po defaultu niso kompatibilni z greylistingom in tako dobesedno drugi strani vsiljuješ nabavo novega strežnika? Čemu že? Če s celim svetom normalno komunicirajo, le z greylisting sistemi ne? Kaj pa nepotrebni overhead na omrežju, basanje mail queue-jev, zamuda v dostavljanju? Aja, to pa je v skladu z RFC. Morda pa ni v skladu z načeli smotrne rabe resursov? Kateri greh je sedaj večji?
Ravno tako smatram za aroganco in nesramen odnos do uporabnikov, če nek admin reče 'če bi ljudje brali sporočila o napakah'. Do sporočil o napakah sploh priti ne sme - za to si admin in tvoje delo je, da uporabniki ne bodo rabili brati teh sporočil, ne pa da uvajaš rešitve, za katere se VE, da niso 100% kompatibilne z vsemi mail sistemi in tako zavestno generiraš dodatna nepotrebna sporočila o napakah.
Pri vseh inteligentnih antispam sistemih, ki danes obstajajo (kdor pozna highend rešitve, bo vedel o čem govorim), je uporaba greylistinga eno navadno sprenevedanje ali pa nepoznavanje tehnologije. Kolikšna pa je dejanska učinkovitost greylistinga? Proti spam botu, ki pošilja preko regularnega smtp strežnika nekega providerja odpove na celi črti (razen če ta strežnik morda ni skonfiguriran po RFC?). Zato za borbo proti spamu potrebuješ dodatne mehanizme. Ti pa so danes že tako napredni in inteligentni, da ne potrebujejo več nobenega greylistinga.
@NoName - mislim, da je tega kakšnega pol leta, ko sem izklopil mail relay. Problem ni bil v običajnem pošiljanju mailov s kakšnega T-2 mailboxa, tisto gre na njihov smtp strežnik, ki očitno nima težav.
Težava se pojavi, kadar tvoj lastni smtp strežnik pošilja mail preko T-2 mail relaya. Pri tem relay sam ne poskuša izvajati ponovnega pošiljanja in uporabniku vrne sporočilo o nedostavljivosti. Nisem pa šel študirati RFC, če bi moral relay sporočiti smtp serverju, da sporočila ne more dostaviti, pa da bi potem moral lokalni server delati retry.
Če so v tem času kaj spreminjali na konfiguraciji ali celo postavili nov server, res nebi vedel (pa tudi ne bom šel preizkušati).
der_Alte ::
V idealnem svetu stvari laufajo tako, kot narekuje RFC, v realnem pač ne. (PIKA!)
Ravno tako smatram za aroganco in nesramen odnos do uporabnikov, če nek admin reče 'če bi ljudje brali sporočila o napakah'. Do sporočil o napakah sploh priti ne sme - za to si admin in tvoje delo je, da uporabniki ne bodo rabili brati teh sporočil, ne pa da uvajaš rešitve, za katere se VE, da niso 100% kompatibilne z vsemi mail sistemi in tako zavestno generiraš dodatna nepotrebna sporočila o napakah.
Se ne strinjam. Nobena aroganca ni, da se uporabniku reče, naj prebere sporočila o napaki. Še največkrat se to zgodi, ko ljudje vpišejo napačnega naslovnika. Je delo administratorja, da popravlja to? Ali bi mogoče bilo boljše, če bi uporabnik enkrat prebral, da njegovo sporočilo ni bilo dostavljeno, ker naslovnika pač ni? Če nekdo ni vešč branja (sporočil o napakah), naj sam tudi pošilja ne ničesar. Naj si plača nekoga, ki bo pošiljal namesto njega.
Še večje cvetke so tisti, ki imajo kar »catch-all« nastavljeno za svojo domeno in požrejo vso pošto, tudi za neobstoječe naslove (večinoma samo napačno zapisane). Potem pa npr. dobiš zahtevke, da se pregleda dnevnike, kaj se je zgodilo s pošto, ki ni prišla do naslovnika. Pravilen odgovor administratorja je seveda, da je sporočilo uspešno prišlo do strežnika naslovnika. Kaj se pa zgodi na »drugi strani«, te pa kot admina prav nič ne zanima.
Kaj hudiča delajo na Internetu SMTP strežniki, ki ne delajo po pravilih? Čimprej zginejo, boljše bo. Jaz osebno blokiram tudi elektronsko pošto, ki prihaja z naslovov, ki ne sprejemajo pošte.
Edit: kaj neki slo-tech jamra o manjkajočem Array tagu na koncu?
Umri mlad! Bodi lepo trupelce!
Zgodovina sprememb…
- spremenil: der_Alte ()
NeMeTko ::
@der Alte - kaj TI blokiraš na tvojem strežniku je TVOJA stvar - se boš že zmenil s svojimi uporabniki.
Povsem nekaj drugega pa je, če to počne provider, brez da bi ga kdo prosil in o tem ne obvešča tistih, ki mu plačujejo za dostavo pošte v njihov mailbox.
'Resend' je bil v RFC umeščen zato, da bi strežniki dostavili pošto tudi v primeru, ko je link down, ali strežnik začasno ni online. Uporaba tega mehanizma za namen ugotavljanja potencialnega spama pa je zloraba tega dela RFCja. Za to imaš druge mehanizme.(PIKA!)
Da se nekaj 'da' in da nikjer ni eksplicitnega predpisa, da se to ne sme, še zdaleč ne pomeni, da je to tudi dobra praksa.
Navedenih pa si imel še nekaj argumentov proti greylistingu, ki si jih očitno spregledal?
O aroganci pa sem govoril v kontekstu, da je admin povzročitelj nepotrebnih sporočil. Več kot jih bo, hitreje jih bodo uporabniki metali v koš. Arogantno pa je potem kriviti uporabnike, da jih niso prebirali, če si ti že v sami osnovi moral poskrbeti, da jih sploh nebi bilo.
Še bolj arogantno je tako izgovarjanje, če gledamo na primere iz prakse: petek ob 15.00 odpošlješ nek mail, ki ga tvoja stranka nujno rabi, ugasneš računalnik in greš na dopust za en teden. Kdaj boš potem prebiral sporočilo o nedostavljeni pošiljki? Pa ne govorimo o narobe napisanem naslovu, temveč o povsem pravilno sestavljenem sporočilu.
Povsem nekaj drugega pa je, če to počne provider, brez da bi ga kdo prosil in o tem ne obvešča tistih, ki mu plačujejo za dostavo pošte v njihov mailbox.
'Resend' je bil v RFC umeščen zato, da bi strežniki dostavili pošto tudi v primeru, ko je link down, ali strežnik začasno ni online. Uporaba tega mehanizma za namen ugotavljanja potencialnega spama pa je zloraba tega dela RFCja. Za to imaš druge mehanizme.(PIKA!)
Da se nekaj 'da' in da nikjer ni eksplicitnega predpisa, da se to ne sme, še zdaleč ne pomeni, da je to tudi dobra praksa.
Navedenih pa si imel še nekaj argumentov proti greylistingu, ki si jih očitno spregledal?
O aroganci pa sem govoril v kontekstu, da je admin povzročitelj nepotrebnih sporočil. Več kot jih bo, hitreje jih bodo uporabniki metali v koš. Arogantno pa je potem kriviti uporabnike, da jih niso prebirali, če si ti že v sami osnovi moral poskrbeti, da jih sploh nebi bilo.
Še bolj arogantno je tako izgovarjanje, če gledamo na primere iz prakse: petek ob 15.00 odpošlješ nek mail, ki ga tvoja stranka nujno rabi, ugasneš računalnik in greš na dopust za en teden. Kdaj boš potem prebiral sporočilo o nedostavljeni pošiljki? Pa ne govorimo o narobe napisanem naslovu, temveč o povsem pravilno sestavljenem sporočilu.
jkreuztzfeld ::
@NeMeTko, imam quote zate:
Še enkrat preberi kaj je napisal der_Alte:
Greylisting je po RFCju (beri pravilih), je učinkovit on ne povzroča posebnih problemov.
Aja. PIKA!
Sometime it is better to remain silent and be thought a fool than to speak out and remove all doubt.
Še enkrat preberi kaj je napisal der_Alte:
Kaj hudiča delajo na Internetu SMTP strežniki, ki ne delajo po pravilih? Čimprej zginejo, boljše bo.
Greylisting je po RFCju (beri pravilih), je učinkovit on ne povzroča posebnih problemov.
Aja. PIKA!
--
Great minds run in great circles.
Great minds run in great circles.
Zgodovina sprememb…
- spremenil: jkreuztzfeld ()
NeMeTko ::
jkreuztzfeld je izjavil:
Greylisting je po RFCju (beri pravilih), je učinkovit on ne povzroča posebnih problemov.
Potem mi pa pokaži, kje v RFC-ju piše kaj o spamu, pa ti bom takoj pritrdil, da imaš prav.
Ne trdim, da sama ideja greylistinga v načelu (v nekem trenutku časa) ni bila dobra, vendar je danes a)neučinkovita b)naredi več zgage, kot koristi.
Admini na strežnikih, ki uporabljajo greylisting imajo pač to srečo, da uporabniki ne vedo, kakšne gnile prijeme uporabljajo in kakšne so posledice teh prijemov - potem se pa čudijo, kje nek mail hodi 15 minut in nazadnje še celo mislijo, da je to 'normalno'.
Aja, v RFC tudi piše, da smtp mail ne jamči dostave maila. Torej je tudi po RFC, če uporabniku preprosto zbrišeš par legitimnih sporočil na dan? Če prodajaš X.400, boš zelo vesel takšnih adminov, ki tako dobesedno jemljejo RFC....
Zgodovina sprememb…
- spremenil: NeMeTko ()
jkreuztzfeld ::
Ok, se pustim seznanit s cenejšo in učinkovitejšo metodo (razen nolistinga, ki je zgolj cenejši).
Kot pravilno ugotavljaš, SMTP v resnici JE best effort servis!
Greylisting ne dela nobene zgage. Poskusi ga vklopit na kakšnem od svojih mail serverjev, naredi analizo logov in mi povej koliko spammerjev poskusi ponovno po temporary errorju - potem lahko nergaš o neučinkovitosti.
SMTP ni bil nikoli namenjen za real-time komunikacijo - za to se uporablja instant messaging.
Kot pravilno ugotavljaš, SMTP v resnici JE best effort servis!
Greylisting ne dela nobene zgage. Poskusi ga vklopit na kakšnem od svojih mail serverjev, naredi analizo logov in mi povej koliko spammerjev poskusi ponovno po temporary errorju - potem lahko nergaš o neučinkovitosti.
SMTP ni bil nikoli namenjen za real-time komunikacijo - za to se uporablja instant messaging.
--
Great minds run in great circles.
Great minds run in great circles.
Bakunin ::
edini "gnil prijem", ki ga vidim v tvojih sporocilih je, da pljuvas po pravilih/standardih, ki jih nisi prej prebral.
SMTP streznik VEDNO poslje sporocilo o napaki - tako da je posiljatelj VEDNO obvescen o tem KAJ je narobe.
to JE normalno.
se enkrat - max. cas dostave je STIRI do PET dni! Ce zelis kaj hitrejsega - fax, gsm/telefon, pot-pod-noge
Internet je bil planiran (se vedno nastavljen tako), da je robusten in ne da je "hiter".
greylisting NE brise e-poste in je NE onemogoca, ampak (samo) zamakne dostavo (pri prvem posiljanju...) za par minut.
Ce je to cena tega, da se znebis OCITNIH trojancev, virusev in FSCKEDUP smtp nedeljskih-kvazi-sistemcev, potem je to OK.
Ce imas smtp, ki ne pozna 4xx err codes n ne uporablja "retry", potem je tak sistem DOA in nima kaj poceti na Internetu.
osebno uporabljam SE nolisting ali dns "greylist"
MX z najnizjo ter najvisjo prioriteto kazeta na IP, kjer tcp/25 timeouta
mx 1 spamtrap-tryothermx.domena.tld.
mx 10 mx.domena.tld
mx 11 mx-ipv4only.domena.tld.
mx 20 spamtrap-tryothermx.domena.tld.
mx v "sendvicu" dobi povezave samo od smtpjev, ki poznajo RFC 2821/2822. dela bp in brez pripomb par sto uporabnikov in dopisnih seznamov.
SMTP streznik VEDNO poslje sporocilo o napaki - tako da je posiljatelj VEDNO obvescen o tem KAJ je narobe.
potem se pa čudijo, kje nek mail hodi 15 minut in nazadnje še celo mislijo, da je to 'normalno'.
to JE normalno.
se enkrat - max. cas dostave je STIRI do PET dni! Ce zelis kaj hitrejsega - fax, gsm/telefon, pot-pod-noge
Internet je bil planiran (se vedno nastavljen tako), da je robusten in ne da je "hiter".
greylisting NE brise e-poste in je NE onemogoca, ampak (samo) zamakne dostavo (pri prvem posiljanju...) za par minut.
Ce je to cena tega, da se znebis OCITNIH trojancev, virusev in FSCKEDUP smtp nedeljskih-kvazi-sistemcev, potem je to OK.
Ce imas smtp, ki ne pozna 4xx err codes n ne uporablja "retry", potem je tak sistem DOA in nima kaj poceti na Internetu.
osebno uporabljam SE nolisting ali dns "greylist"
MX z najnizjo ter najvisjo prioriteto kazeta na IP, kjer tcp/25 timeouta
mx 1 spamtrap-tryothermx.domena.tld.
mx 10 mx.domena.tld
mx 11 mx-ipv4only.domena.tld.
mx 20 spamtrap-tryothermx.domena.tld.
mx v "sendvicu" dobi povezave samo od smtpjev, ki poznajo RFC 2821/2822. dela bp in brez pripomb par sto uporabnikov in dopisnih seznamov.
Reycis ::
Meni kot uporabniku je vsakršno zadrževanje/nedostavljanje pošte v imenu antispama nezaželjeno. Za vsak mail pričakujem, da je dostavljen takoj. Edini razlog, da se to ne zgodi je lahko tehničen nikakor pa ne administrativen.
miki133 ::
Da boste približno vedeli za kaka razmerja gre en graf s seštevki za zadnjih 24 ur :)
LP Miro
Slika
LP Miro
jkreuztzfeld ::
@Majk Heh. Na (tvojo?) srečo, se lahko v (korporativnem) okolju, kjer je e-mail pomemben način komunikacije, namesto tebe odločijo drugi.
Pri svojih privatnih zadevah lahko filtriranje spama urediš pri svojem ISP-ju, ali sam uživaš v ločevanju semena od plev.
Pri svojih privatnih zadevah lahko filtriranje spama urediš pri svojem ISP-ju, ali sam uživaš v ločevanju semena od plev.
--
Great minds run in great circles.
Great minds run in great circles.
NeMeTko ::
Najprej razčistimo nekaj pojmov: NE govorim o 'malih zasebnih mail serverjih' ampak o providerjevih sistemih in sistemih velikih uporabnikov (@gov.si!), ki imajo več kot preveč denarja na voljo, da lahko stvari uredijo drugače.
Ti sistemi dnevno procesirajo na stotisoče mailov in povsem po nepotrebnem generirajo dodaten promet na internetu in zamude pri dostavi sporočil.
Če maš ti na @poorman.si postavljen greylisting in zavrneš 50-100 (potencialnih) spamov, boš naredil škodo sebi, in morda še dvema svojima uporabnikoma, ki bosta enkrat mesečno naletela na situacijo, da bosta klicala stranko, kdaj misli že poslati tisti obljubljeni mail, stranka pa bo ugotovila, da je bil zavrnjen. Si rečeš 'shit happens', odtehtaš pluse, minuse, preceniš, da se ti zdi, da ni toliko škode (itak se pri stranki izgovoriš na butasti antispam - krivi so takointako spammerji, saj ga drugače nebi rabil), da bi to upravičilo investicijo v kakšno bolj konkretno antispam rešitev in furaš dalje.
Če pa @polnarit.si, ki ima desttisoč uporabnikov na svoji domeni, škrtari pri tako banalni zadevi, kot je antispam, pa nimam prav nobenega razumevanja. Še manj pa ga imam, če to počne provider. Vsi veliki ponudniki 'free' mail storitev imajo spam folderje, kamor razporedijo sumljiva sporočila - tudi slučajno si ne drznejo, da bi jih samovoljno zavračali ali brisali brez tvoje vednosti. Zakaj pa nek Amis to lahko? Po čem bo Amis sodil, če je nek mail za mene pomemben ali ne? Ali sem mu to sploh dovolil? Pa ko bi vsaj vprašal in opozoril po sistemu 'tako pač je, če ti ni všeč, pa pojdi drugam'.
Tudi če nimaš denarja, imaš na voljo celo goro free blacklist strežnikov in rešitev, ki znajo uporabljati razne dictionary-e, scoring mehanizme, baesian filtre in logiko - v open source projektih! Samo poguglaš 'open source antispam', pa vidiš, da obstaja še kaj drugega, kot greylisting.
Po nekih ocenah greylisting zavrne cca. 60% spam sporočil (in neznano število legitimnih sporočil).
Kdor se količkaj spozna v antispam rešitve ve, da sodobne antispam rešitve prefiltrirajo 99+% spama ob 0.01-% false positives. Kje je tu potem upravičenost uporabe greylistinga? Rešitev, ki brez greylistinga ni sposobna prefiltrirati 90+% spama ne sodi v nobeno resno okolje.
Izgovarjanje na max. čas dostave maila po RFC je .... (zmisite si primeren izraz). Ti RFC-ji so se pisali pred 30 leti (ali več?), ko je internet baziral še na analognih žičnih povezavah, mail pa se pretežno dostavljal preko UUCP. Danes, ko imajo velika podjetja gigabitne povezave, optika pa na vsakem vogalu, so te norme iz RFCja popolnoma antične, zastrarele in za poslovni svet nedopustne. To bi moral VSAK mail admin vedeti.
Ravno tako bi moral vsak mail admin vedeti, da je prva prioriteta vsake resne antispam rešitve, da se zagotovi, da se ne označuje legitimno pošto za spam. Že 1% false positives je številka, ki bi morala resno zaskrbeti vsakega admina.
Z uporabnikovega vidika, je bistveno manjše zlo, če ima dnevno 10 spam sporočil v inboxu, kot pa če mu 'izgine' eno samo legitimno sporočilo na teden. Ampak očitno se mail admini skrivate tako globoko v katakombah IT oddelkov, da do vas ne pridejo pritožbe uporabnikov? Če pa že kdaj pride kakšna pritožba, pa pomahate z RFC-jem in se izgovarjate na tujo krivdo, sploh pa ni panike, saj mail lahko hodi 4-5 dni, mar ne?
Mi pa še vedno ni jasno, ali je to posledica lenobe, neznanja ali ignorance, da ob veliko bolj zanesljivih open source metodah uporabljate metodo, s katero v bistvu sami spammate po netu. Da - tista fake error 4xx sporočila SO spam in po nepotrebnem obremenjujejo tuje mail strežnike - in to celo VELIKO bolj, kot običajen spam!
Običajen spam prileti na strežnik, se sprocesira in gre v karanteno - v manj kot 1 sekundi.
Tisto error 4xx sporočilo pa kot prvo reče pošiljatelju 'kaj me briga, če imaš 10 megabytov maila za dostaviti - ti lepo počakaj pa mi to pošlji kdaj drugič'. Pošiljateljev strežnik nato mora po nepotrebnem skladiščiti tistih 10 MB in odšteva, kdaj sme poskusiti ponovno. Proba po dveh minutah - tup jo dobi po glavi - greylista ga še vedno ne j* in dobi spet error 4xx. Skladišči dalje in odšteva naslednjih 5 minut, da bo spet poskusil kontaktirati strežnik z greylistingom. Z nekaj sreče (odvisno od konfiguracije), mu bo morda v tretje uspelo znebiti se tistega sporočila in sprostiti disk, če bo imel smolo, bo pa moral še v četrto rundo poskušanja. Pošiljateljev strežnik je tako zlorabljan 7-15 minut čisto po nepotrebnem.
Če kdo trdi, da so si snovalci RFCja predstavljali, da se bodo resursi tratili na tak način, potem ta ne ve kaj govori.
Ti sistemi dnevno procesirajo na stotisoče mailov in povsem po nepotrebnem generirajo dodaten promet na internetu in zamude pri dostavi sporočil.
Če maš ti na @poorman.si postavljen greylisting in zavrneš 50-100 (potencialnih) spamov, boš naredil škodo sebi, in morda še dvema svojima uporabnikoma, ki bosta enkrat mesečno naletela na situacijo, da bosta klicala stranko, kdaj misli že poslati tisti obljubljeni mail, stranka pa bo ugotovila, da je bil zavrnjen. Si rečeš 'shit happens', odtehtaš pluse, minuse, preceniš, da se ti zdi, da ni toliko škode (itak se pri stranki izgovoriš na butasti antispam - krivi so takointako spammerji, saj ga drugače nebi rabil), da bi to upravičilo investicijo v kakšno bolj konkretno antispam rešitev in furaš dalje.
Če pa @polnarit.si, ki ima desttisoč uporabnikov na svoji domeni, škrtari pri tako banalni zadevi, kot je antispam, pa nimam prav nobenega razumevanja. Še manj pa ga imam, če to počne provider. Vsi veliki ponudniki 'free' mail storitev imajo spam folderje, kamor razporedijo sumljiva sporočila - tudi slučajno si ne drznejo, da bi jih samovoljno zavračali ali brisali brez tvoje vednosti. Zakaj pa nek Amis to lahko? Po čem bo Amis sodil, če je nek mail za mene pomemben ali ne? Ali sem mu to sploh dovolil? Pa ko bi vsaj vprašal in opozoril po sistemu 'tako pač je, če ti ni všeč, pa pojdi drugam'.
Tudi če nimaš denarja, imaš na voljo celo goro free blacklist strežnikov in rešitev, ki znajo uporabljati razne dictionary-e, scoring mehanizme, baesian filtre in logiko - v open source projektih! Samo poguglaš 'open source antispam', pa vidiš, da obstaja še kaj drugega, kot greylisting.
Po nekih ocenah greylisting zavrne cca. 60% spam sporočil (in neznano število legitimnih sporočil).
Kdor se količkaj spozna v antispam rešitve ve, da sodobne antispam rešitve prefiltrirajo 99+% spama ob 0.01-% false positives. Kje je tu potem upravičenost uporabe greylistinga? Rešitev, ki brez greylistinga ni sposobna prefiltrirati 90+% spama ne sodi v nobeno resno okolje.
Izgovarjanje na max. čas dostave maila po RFC je .... (zmisite si primeren izraz). Ti RFC-ji so se pisali pred 30 leti (ali več?), ko je internet baziral še na analognih žičnih povezavah, mail pa se pretežno dostavljal preko UUCP. Danes, ko imajo velika podjetja gigabitne povezave, optika pa na vsakem vogalu, so te norme iz RFCja popolnoma antične, zastrarele in za poslovni svet nedopustne. To bi moral VSAK mail admin vedeti.
Ravno tako bi moral vsak mail admin vedeti, da je prva prioriteta vsake resne antispam rešitve, da se zagotovi, da se ne označuje legitimno pošto za spam. Že 1% false positives je številka, ki bi morala resno zaskrbeti vsakega admina.
Z uporabnikovega vidika, je bistveno manjše zlo, če ima dnevno 10 spam sporočil v inboxu, kot pa če mu 'izgine' eno samo legitimno sporočilo na teden. Ampak očitno se mail admini skrivate tako globoko v katakombah IT oddelkov, da do vas ne pridejo pritožbe uporabnikov? Če pa že kdaj pride kakšna pritožba, pa pomahate z RFC-jem in se izgovarjate na tujo krivdo, sploh pa ni panike, saj mail lahko hodi 4-5 dni, mar ne?
Mi pa še vedno ni jasno, ali je to posledica lenobe, neznanja ali ignorance, da ob veliko bolj zanesljivih open source metodah uporabljate metodo, s katero v bistvu sami spammate po netu. Da - tista fake error 4xx sporočila SO spam in po nepotrebnem obremenjujejo tuje mail strežnike - in to celo VELIKO bolj, kot običajen spam!
Običajen spam prileti na strežnik, se sprocesira in gre v karanteno - v manj kot 1 sekundi.
Tisto error 4xx sporočilo pa kot prvo reče pošiljatelju 'kaj me briga, če imaš 10 megabytov maila za dostaviti - ti lepo počakaj pa mi to pošlji kdaj drugič'. Pošiljateljev strežnik nato mora po nepotrebnem skladiščiti tistih 10 MB in odšteva, kdaj sme poskusiti ponovno. Proba po dveh minutah - tup jo dobi po glavi - greylista ga še vedno ne j* in dobi spet error 4xx. Skladišči dalje in odšteva naslednjih 5 minut, da bo spet poskusil kontaktirati strežnik z greylistingom. Z nekaj sreče (odvisno od konfiguracije), mu bo morda v tretje uspelo znebiti se tistega sporočila in sprostiti disk, če bo imel smolo, bo pa moral še v četrto rundo poskušanja. Pošiljateljev strežnik je tako zlorabljan 7-15 minut čisto po nepotrebnem.
Če kdo trdi, da so si snovalci RFCja predstavljali, da se bodo resursi tratili na tak način, potem ta ne ve kaj govori.
Poldi112 ::
Zanimivo, da nekoga, ki govori o današnjem času in hitrih povezavah, tako boli 10M mail, ki se parkrat zavrne. :)
Greylisting je čisto ok. Reči, da bolj obremenuje omrežje kot spam (ki predstavlja koliko, 75%? prometa), je pa abotno.
Pa btw, saj veš kaj je rekel avtor postfix-a: "Junk mail is war. RFCs do not apply."
Greylisting je čisto ok. Reči, da bolj obremenuje omrežje kot spam (ki predstavlja koliko, 75%? prometa), je pa abotno.
Pa btw, saj veš kaj je rekel avtor postfix-a: "Junk mail is war. RFCs do not apply."
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
NeMeTko ::
Pa veš kaj je rekel avtor zgornjega prispevka? "Just answer the question: are you lazy or just stupid and ignorant?"
Brane22 ::
@NeMeTko:
Se ne strinjam. Vsaj pri meni dela greylisting super. In če bi vsi uporabljali RFCje samo v smislu, kot so si jih zamislili prvotni avtorji, danes net ne bi zanimal nikogar, ker bi služil samo za akademske projekte, email pa bi uporabljali samo odhlapeli doktorji znanosti.
Pač nek haklc se je v novejšem času izkazal kot nepričakovano koristen. In ne samo to, ampak ta haklce precej natančno identificira spammerja, ki bi ga sicer težko ločil. Tako spammer kot legitimni uporabnik bi ti rada nekaj sporočila. Najbolj očitna rzlika je, da bi spammer silno rad, da sprejmeš sporočilo TAKOJ in zanj nisi zanimiv, če tega časa nimaš prav zdaj, pri ostalih je pa prav obratno- nekaj minut se vedno najde.
Druge metode niso vedno rešitev. Pošiljanje spama je trivijalno, skeniranje sprejetih sporočil in fitriranje spama je pa bolj umetnost kot rešen problem. Ravno tako je poseben glavobol razmerje orožij. Ti porabiš veliko več procesorske moči in časa ( = energije = denarja) za fiiltriranje, kot ga porabi spammer za generiranje. In še vedno pride nekaj skozi. Se pravi, v tej vojni je pri takem pristopu on vedno na boljšem. Njegov računalnik je lahko veliko cenejši.
Tudi ni res, da je bolj imeti nekaj spama kot zgubiti kak mail. Vsaj zame to niti približno ni tako. Brez pametnega filtriranja dobim lahko več kot 100 spam sporočil na dan. Po nekaj dneh je to lahko 1000 in več mailov. če me pričaka tak kup mailov po enotedenskem premoru, mi bo že samo brkljanje po kupu povzročilo nemalo muke, vzelo ohoho časa in čisto komot med tem spregledam kak legalni mail.
Tudi ni res, da je bolj imeti nekaj spama kot zgubiti kak mail. Vsaj zame to niti približno ni tako. Brez pametnega filtriranja dobim lahko več kot 100 spam sporočil na dan. Po nekaj dneh je to lahko 1000 in več mailov. če me pričaka tak kup mailov po enotedenskem premoru, mi bo že samo brkljanje po kupu povzročilo nemalo muke, vzelo ohoho časa in čisto komot med tem spregledam kak legalni mail.
Vsako morebitno čakanje na mail več kot odtehta izfitriran crap. Ta pa koneckoncev tudi v bandwidthu ne more biti prav poceni.Dokler nekdo ne pogrunta dobre alternative, mi je tole kot ad-hoc rešiotev več kot ustreza.
In BTW tudi automatizirano filtriranje ni rešitev. Vedno vsak filter lahko odfiltrira uproaben mail. Torej to, da ga pa montiraš na svoji strani, ne rešuje ničesar.
Kar pa se emaila, ki bi te zaradi graylistinga utegnil zgrešiti, se ne sekiram preveč zanj. Ne bom pozimi delal ob odprtem oknu za vsak slučaj, ker bi mi kdo lahko poslal pošto po golobu. Pričakovano je neko ustrezanje standardom in določena toleranca do bugov. Če bi bil ta haklc neuporabljan in nekoristen, bi ga odrezali ali se vsaj ne bi preveč sekirali z ustreznostjo. Ker pa se je pokazal kot splošnokoristen, je normalno, da se od poreme pričakuje tovrstno ustreznost.
Tudi ne vidim kaj naj bi negativnega povzročilo "nekaj 10MB pošte, ki čaka". Naj čaka. V globalu to ne spremeni ničesar. Bo pač sedaj poslana pošta, ki je čakala prej. ziroma vsaj njen legalni del. preostanek bo čakal naprej, dokler se ne bo izfiltriral dalje ali pa zavrgel.
Diski so poceni. Bandwidth je manj. CPU power manj. Delo progrmerja na filtrih in milijarde userjev, ki dodatno čekira ročno vse maile pa še manj.
Se ne strinjam. Vsaj pri meni dela greylisting super. In če bi vsi uporabljali RFCje samo v smislu, kot so si jih zamislili prvotni avtorji, danes net ne bi zanimal nikogar, ker bi služil samo za akademske projekte, email pa bi uporabljali samo odhlapeli doktorji znanosti.
Pač nek haklc se je v novejšem času izkazal kot nepričakovano koristen. In ne samo to, ampak ta haklce precej natančno identificira spammerja, ki bi ga sicer težko ločil. Tako spammer kot legitimni uporabnik bi ti rada nekaj sporočila. Najbolj očitna rzlika je, da bi spammer silno rad, da sprejmeš sporočilo TAKOJ in zanj nisi zanimiv, če tega časa nimaš prav zdaj, pri ostalih je pa prav obratno- nekaj minut se vedno najde.
Druge metode niso vedno rešitev. Pošiljanje spama je trivijalno, skeniranje sprejetih sporočil in fitriranje spama je pa bolj umetnost kot rešen problem. Ravno tako je poseben glavobol razmerje orožij. Ti porabiš veliko več procesorske moči in časa ( = energije = denarja) za fiiltriranje, kot ga porabi spammer za generiranje. In še vedno pride nekaj skozi. Se pravi, v tej vojni je pri takem pristopu on vedno na boljšem. Njegov računalnik je lahko veliko cenejši.
Tudi ni res, da je bolj imeti nekaj spama kot zgubiti kak mail. Vsaj zame to niti približno ni tako. Brez pametnega filtriranja dobim lahko več kot 100 spam sporočil na dan. Po nekaj dneh je to lahko 1000 in več mailov. če me pričaka tak kup mailov po enotedenskem premoru, mi bo že samo brkljanje po kupu povzročilo nemalo muke, vzelo ohoho časa in čisto komot med tem spregledam kak legalni mail.
Tudi ni res, da je bolj imeti nekaj spama kot zgubiti kak mail. Vsaj zame to niti približno ni tako. Brez pametnega filtriranja dobim lahko več kot 100 spam sporočil na dan. Po nekaj dneh je to lahko 1000 in več mailov. če me pričaka tak kup mailov po enotedenskem premoru, mi bo že samo brkljanje po kupu povzročilo nemalo muke, vzelo ohoho časa in čisto komot med tem spregledam kak legalni mail.
Vsako morebitno čakanje na mail več kot odtehta izfitriran crap. Ta pa koneckoncev tudi v bandwidthu ne more biti prav poceni.Dokler nekdo ne pogrunta dobre alternative, mi je tole kot ad-hoc rešiotev več kot ustreza.
In BTW tudi automatizirano filtriranje ni rešitev. Vedno vsak filter lahko odfiltrira uproaben mail. Torej to, da ga pa montiraš na svoji strani, ne rešuje ničesar.
Kar pa se emaila, ki bi te zaradi graylistinga utegnil zgrešiti, se ne sekiram preveč zanj. Ne bom pozimi delal ob odprtem oknu za vsak slučaj, ker bi mi kdo lahko poslal pošto po golobu. Pričakovano je neko ustrezanje standardom in določena toleranca do bugov. Če bi bil ta haklc neuporabljan in nekoristen, bi ga odrezali ali se vsaj ne bi preveč sekirali z ustreznostjo. Ker pa se je pokazal kot splošnokoristen, je normalno, da se od poreme pričakuje tovrstno ustreznost.
Tudi ne vidim kaj naj bi negativnega povzročilo "nekaj 10MB pošte, ki čaka". Naj čaka. V globalu to ne spremeni ničesar. Bo pač sedaj poslana pošta, ki je čakala prej. ziroma vsaj njen legalni del. preostanek bo čakal naprej, dokler se ne bo izfiltriral dalje ali pa zavrgel.
Diski so poceni. Bandwidth je manj. CPU power manj. Delo progrmerja na filtrih in milijarde userjev, ki dodatno čekira ročno vse maile pa še manj.
Zgodovina sprememb…
- spremenilo: Brane22 ()
NeMeTko ::
Ignoranca?
Beri IETF draft "Email Greylisting: An Applicability Statement for SMTP draft-ietf-appsawg-greylisting-09" in posveti posebno pozornost sekciji 4 tega dokumenta.
Začnite se zavedati, da mail server ni postavljen zato, da se bo mail admin igračkal s spammerji, kdo ima daljšega, temveč IZKLJUČNO zato, da UPORABNIKI lahko pošiljajo in sprejemajo elektronsko pošto - brez izgub in z čim manjšo zakasnitvijo.
Ignoranca ali stupidity?
Če sem jaz govoril o enem sporočilu, malo razmislite, kaj to pomeni na nekem strežniku ranga SIOL ali T-2, če na tisoče sporočil čaka, da bo butasti greylisting sistem že končno sprejel sporočilo, ki mu je namenjeno. Tu ni več govora o megabyt-ih ampak giga in terabytih in popolnoma nepotrebni dodatni obremenitvi strežniških sistemov, ki namesto da bi sporočilo oddali, to premeščajo po queue-ju gor in dol.
Beri IETF draft "Email Greylisting: An Applicability Statement for SMTP draft-ietf-appsawg-greylisting-09" in posveti posebno pozornost sekciji 4 tega dokumenta.
Začnite se zavedati, da mail server ni postavljen zato, da se bo mail admin igračkal s spammerji, kdo ima daljšega, temveč IZKLJUČNO zato, da UPORABNIKI lahko pošiljajo in sprejemajo elektronsko pošto - brez izgub in z čim manjšo zakasnitvijo.
Ignoranca ali stupidity?
Če sem jaz govoril o enem sporočilu, malo razmislite, kaj to pomeni na nekem strežniku ranga SIOL ali T-2, če na tisoče sporočil čaka, da bo butasti greylisting sistem že končno sprejel sporočilo, ki mu je namenjeno. Tu ni več govora o megabyt-ih ampak giga in terabytih in popolnoma nepotrebni dodatni obremenitvi strežniških sistemov, ki namesto da bi sporočilo oddali, to premeščajo po queue-ju gor in dol.
Brane22 ::
@NeMeTko:
če bi ga kdo posavil pri nas na tak način, ga nihče ne bi uporabljal. Domnevam da je tako tudi drugje. Navaden uporabnik ne bere RFCjev in verjetno niti ne ve, kaj to je. Neki taki prijemi tipa "evo ti account, dalje pa snadži se" ne bi delale v redu v splošnem.
Vsi ti giga in terabajti bi bili sicer spuščeni po linku in temu ustrezno plačani. Po splošni statistiki bi bilo levji delež tega čisti spam.
Tako pa obremenjujejo par poceni diskov.
In ne samo da bi bili spuščeni po linku. Potem bi se z vsemi temi maili uvkvarjala maljarda spam-filtrov namaljardi serverjev in pri tem požgala megavatne ure.
Zatem pa bi skozi rezultat čekirala maljarda ljudi in preverjala, če ni še kak spam ostal oziroma če ni kaj bistvenega končalo v kanti.
Ni ga večjega užitka od intimnega spoznavanja smradu kante...
ačnite se zavedati, da mail server ni postavljen zato, da se bo mail admin igračkal s spammerji, kdo ima daljšega, temveč IZKLJUČNO zato, da UPORABNIKI lahko pošiljajo in sprejemajo elektronsko pošto - brez izgub in z čim manjšo zakasnitvijo.
če bi ga kdo posavil pri nas na tak način, ga nihče ne bi uporabljal. Domnevam da je tako tudi drugje. Navaden uporabnik ne bere RFCjev in verjetno niti ne ve, kaj to je. Neki taki prijemi tipa "evo ti account, dalje pa snadži se" ne bi delale v redu v splošnem.
Če sem jaz govoril o enem sporočilu, malo razmislite, kaj to pomeni na nekem strežniku ranga SIOL ali T-2, če na tisoče sporočil čaka, da bo butasti greylisting sistem že končno sprejel sporočilo, ki mu je namenjeno. Tu ni več govora o megabyt-ih ampak giga in terabytih in popolnoma nepotrebni dodatni obremenitvi strežniških sistemov, ki namesto da bi sporočilo oddali, to premeščajo po queue-ju gor in dol.
Vsi ti giga in terabajti bi bili sicer spuščeni po linku in temu ustrezno plačani. Po splošni statistiki bi bilo levji delež tega čisti spam.
Tako pa obremenjujejo par poceni diskov.
In ne samo da bi bili spuščeni po linku. Potem bi se z vsemi temi maili uvkvarjala maljarda spam-filtrov namaljardi serverjev in pri tem požgala megavatne ure.
Zatem pa bi skozi rezultat čekirala maljarda ljudi in preverjala, če ni še kak spam ostal oziroma če ni kaj bistvenega končalo v kanti.
Ni ga večjega užitka od intimnega spoznavanja smradu kante...
Zgodovina sprememb…
- spremenilo: Brane22 ()
NeMeTko ::
Lazy ?
Greylisting sam po sebi nebi bil problem, če admini nebi bili takšne lenobe in bi ročno poadministrirali whiteliste za znane strežnike, ki se ne odzivajo pravilno na greylisting error 4xx sporočila.
Če bi admini sledili priporočilom IETF drafta, bi se bolj malo kdo pritoževal nad greylistingom. Tako pa se admini obnašate kot tisti kmet ki s šibrovko odganja vrabce in slepo streljate okoli sebe - če spotoma še koga ranite ni problem, glavno, da so vrabci pregnani. Pa so res? Kolikšen je že detection rate za greylisting? 60%? Ajajajaj!
Greylisting sam po sebi nebi bil problem, če admini nebi bili takšne lenobe in bi ročno poadministrirali whiteliste za znane strežnike, ki se ne odzivajo pravilno na greylisting error 4xx sporočila.
Če bi admini sledili priporočilom IETF drafta, bi se bolj malo kdo pritoževal nad greylistingom. Tako pa se admini obnašate kot tisti kmet ki s šibrovko odganja vrabce in slepo streljate okoli sebe - če spotoma še koga ranite ni problem, glavno, da so vrabci pregnani. Pa so res? Kolikšen je že detection rate za greylisting? 60%? Ajajajaj!
Brane22 ::
Fajn. Kolišen del navfadnih pisem, ki ne ustrzeeajo specifikacijam pošte ali pa so brez veljavne znamke pride skozi ?
naj zdaj uvedeno brezplačno poštnino, da bo naslovnik ziher dobil pošiljko ?
Če pošiljatelj ne ustreza minimalnim zahtevam, JBG.
naj zdaj uvedeno brezplačno poštnino, da bo naslovnik ziher dobil pošiljko ?
Če pošiljatelj ne ustreza minimalnim zahtevam, JBG.
Poldi112 ::
Iz muhe dela slona. Verjetno ima menstruacijo :)
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
misek ::
Kateri maili pa danes sploh pristanejo na grey listi, torej da se zakasnijo? Maili, poslani med slovenskimi operaterji verjetno ne, saj so se že zdavnaj izkazali, da so legitimni in ne spam.
NeMeTko ::
Ignoranca....
Sem mislil, da če ne bosta resno jemala, kar jaz napišem, da bosta vsaj resno jemala IETF draft dokument.
Ampak očitno sta tako zelo zaverovana vase in samovšečna, da je za vaju tudi ta dokument navaden bullshit.
Po vajino je očitno imel še nekdo na IEFT menstruacijo, ko je imel v uradni dokument toliko o 'unintended consequences' in 'tradeoffs' za napisati? Tisti del z 'recommendations' pa je za vaju navaden PMS?
Sem mislil, da če ne bosta resno jemala, kar jaz napišem, da bosta vsaj resno jemala IETF draft dokument.
Ampak očitno sta tako zelo zaverovana vase in samovšečna, da je za vaju tudi ta dokument navaden bullshit.
Po vajino je očitno imel še nekdo na IEFT menstruacijo, ko je imel v uradni dokument toliko o 'unintended consequences' in 'tradeoffs' za napisati? Tisti del z 'recommendations' pa je za vaju navaden PMS?
Brane22 ::
NeMeTko:
Pa saj jaz nisem nek admin in ne štejem sebe za svetovne avtoritete. Le dal sem svoje mnenje.
Pogledal sem dokument tisti dokument. NIsme imel čas za podrobno branje a kolikor sem videl, ne navaja pod side-effects nič novega.
Del klientov se obnaša "atipično". OK. Ta del se bo ali začel obnašati "tipično" ali pa bo odpadel.
Fine with me.
Pa saj jaz nisem nek admin in ne štejem sebe za svetovne avtoritete. Le dal sem svoje mnenje.
Pogledal sem dokument tisti dokument. NIsme imel čas za podrobno branje a kolikor sem videl, ne navaja pod side-effects nič novega.
Del klientov se obnaša "atipično". OK. Ta del se bo ali začel obnašati "tipično" ali pa bo odpadel.
Fine with me.
Poldi112 ::
Glej, dokument govori o možnostih. Tem stvarem se da izogniti. Samo po drugi strani, kako naj tebe kdo resno jemlje, če jokaš o stvareh, za katere v praksi vidimo, da lepo delujejo. In govoriš o terabajtih izgub - od kje ti take cifre? In od kje ti ideja, da je naloga sistemca, da vse dostavi - spam je pravilno, da se briše. In blokiranje serverjev, ki ne spoštujejo rfc je super indikacija. Bolj zanesljivo od vseh list. Če ima pa kdo res tako zanič server, da ne spoštuje specifikacije, je pa to striktno njegov problem oz. problem njegovih uporabnikov.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
NeMeTko ::
Kateri maili pa danes sploh pristanejo na grey listi, torej da se zakasnijo? Maili, poslani med slovenskimi operaterji verjetno ne, saj so se že zdavnaj izkazali, da so legitimni in ne spam.
Nekaj malega spama se najde tudi v prometu med slovenskimi operaterji - vendar je zanemarljiv.
Zato sem tudi jezen na lene admine, ki niso sposobni vpisati tistih nekaj legitimnih SLO strežnikov, ki stojijo pri providerjih v whiteliste (da gredo direktno skozi).
Vprašanje je tudi, koliko adminov ima database za whitelisto zgolj 'in memory' in se resetira ob vsakem restartu strežnika. Ravno tako imajo aging na whitelisti nastavljen tako na kratek čas, da neprestano izpadaš iz že preverjenega seznama 'poštenih pošiljateljev', namesto da bi se malo potrudili in sami sestavili seznam domen iz katerih ni še nikoli prišel spam in ga vnesli v permanentno whitelisto.
Potem pa se repenčijo, da imajo drugi slabo porihtane strežnike - namesto da bi najprej pometli pred lastnim pragom.
NeMeTko ::
Glej, dokument govori o možnostih. Tem stvarem se da izogniti. Samo po drugi strani, kako naj tebe kdo resno jemlje, če jokaš o stvareh, za katere v praksi vidimo, da lepo delujejo. In govoriš o terabajtih izgub - od kje ti take cifre? In od kje ti ideja, da je naloga sistemca, da vse dostavi - spam je pravilno, da se briše. In blokiranje serverjev, ki ne spoštujejo rfc je super indikacija. Bolj zanesljivo od vseh list. Če ima pa kdo res tako zanič server, da ne spoštuje specifikacije, je pa to striktno njegov problem oz. problem njegovih uporabnikov.
Pa saj ravno v tem je štos, da v praksi ne delujejo tako lepo, kot bi to radi prikazali!
Ne delujejo pa zato, ker niso poadministrirani tako, kot bi mogli biti.
Istočasno pa sami sebe farbate kako strašno dobra antispam rešitev da je. Koliko % gre še vedno skozi?
NeMeTko ::
Btw.: meni spam filtrira Commtouch
Prestreže 98% spama, brez enega samega false positives kiksa tekom zadnjih petih let.
BREZ grey in drugega shit-listinga, brez spammanja tujih serverjev s fake error 4xx.
IZGUBLJENIH mailov ni - vsi sumljivi maili se shranijo v spam karanteno, kjer se lahko na lastne oči prepričaš, da vmes ni zašel noben legitimen mail.
Administrativni napor = 0
Koliko pa vam greylisting nafiltrira, da lahko opravičujete njegovo rabo?
Lahko vaš uporabnik preveri, če je bil določen njemu namenjen mail morda blokiran? Ga lahko restavrira?
Prestreže 98% spama, brez enega samega false positives kiksa tekom zadnjih petih let.
BREZ grey in drugega shit-listinga, brez spammanja tujih serverjev s fake error 4xx.
IZGUBLJENIH mailov ni - vsi sumljivi maili se shranijo v spam karanteno, kjer se lahko na lastne oči prepričaš, da vmes ni zašel noben legitimen mail.
Administrativni napor = 0
Koliko pa vam greylisting nafiltrira, da lahko opravičujete njegovo rabo?
Lahko vaš uporabnik preveri, če je bil določen njemu namenjen mail morda blokiran? Ga lahko restavrira?
Brane22 ::
Ni čisto tako.
Čim imaš spam karanteno, pomeni da je neka možnost, da je tja zašel dober mail.
Čim ta možnost je, jo moraš preveriti, da se prepričaš.
Čim to storiš, to ni več zastonj.
Tudi ni jasno, kako naj bi našel morebitni dober mail v skupini od recimo 50.000.
Mene greylisting ne stane CPU-wise praktično nič. Ti mi lahko mečeš spam maile praktično z recimo polovico mojega bandwidhta in zgodilo se ne bo veliko. Če pa se zanašam na skeniranje, zaradi tega komot položiš moj server. Ali to ali pa moram imeti ogromno rezervo.
Poleg tega sta ob rešitvi ortogonalni. Komot imam lahko graylisting, rezultat pa preskeniram.
Čim imaš spam karanteno, pomeni da je neka možnost, da je tja zašel dober mail.
Čim ta možnost je, jo moraš preveriti, da se prepričaš.
Čim to storiš, to ni več zastonj.
Tudi ni jasno, kako naj bi našel morebitni dober mail v skupini od recimo 50.000.
Mene greylisting ne stane CPU-wise praktično nič. Ti mi lahko mečeš spam maile praktično z recimo polovico mojega bandwidhta in zgodilo se ne bo veliko. Če pa se zanašam na skeniranje, zaradi tega komot položiš moj server. Ali to ali pa moram imeti ogromno rezervo.
Poleg tega sta ob rešitvi ortogonalni. Komot imam lahko graylisting, rezultat pa preskeniram.
Poldi112 ::
>Istočasno pa sami sebe farbate kako strašno dobra antispam rešitev da je. Koliko % gre še vedno skozi?
Saj se ne farbamo - pač, uporabiš orodja, ki so ti na voljo. Graylisting je zgolj eno od njih. Spama praktično nimam, ne vem pa na pamet, koliko katera stvar naredi. Sistem laufa in ga že kakšno leto nisem tikal. Je pa to za malo firmo, tako da razne profi rešitve tu niti ne pridejo v poštev.
>Lahko vaš uporabnik preveri, če je bil določen njemu namenjen mail morda blokiran? Ga lahko restavrira?
Če je zavrnjen zaradi grayliste in ga pošiljateljev smtp ne pošlje ponovno, potem jasno ne. Ga pa vidi pošiljatelj (oz. naj bi ga, razen če je spammer in to ignorira).
Saj se ne farbamo - pač, uporabiš orodja, ki so ti na voljo. Graylisting je zgolj eno od njih. Spama praktično nimam, ne vem pa na pamet, koliko katera stvar naredi. Sistem laufa in ga že kakšno leto nisem tikal. Je pa to za malo firmo, tako da razne profi rešitve tu niti ne pridejo v poštev.
>Lahko vaš uporabnik preveri, če je bil določen njemu namenjen mail morda blokiran? Ga lahko restavrira?
Če je zavrnjen zaradi grayliste in ga pošiljateljev smtp ne pošlje ponovno, potem jasno ne. Ga pa vidi pošiljatelj (oz. naj bi ga, razen če je spammer in to ignorira).
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
jkreuztzfeld ::
Ok. I get it. Priznam da sem bolj počasne pameti, ampak v temle navalu besa sem rabil nekaj časa.
NeMeTko je jezen na admine, ki ne znajo skonfigurirat mail serverja.
Dragi NeMeTko, če bi vsakič, ko pri varnostnem pregledu ali kaki drugi priložnosti vidim drain-bamage skonfiguriran mail/dns/web server, dobil evro, bi mi že odpadel poden od domače blagajne. Zatorej predlagam dihalne vaje in omiljeni napitek za pomirjanje. Get over it, zadeve se zaradi tvojega ranta ne bodo spremenile.
Seveda te moram še malo pojezit. Greylisting nima false positivov. Mail serverji na internetu upoštevajo standarde. Če ima kak end user (ob redkih priložnostih ko dobi mail iz vira ki ni na whitelisti), težavo počakat 15 minut, je odgovor že v enem prejšnjih postov.
NeMeTko je jezen na admine, ki ne znajo skonfigurirat mail serverja.
Dragi NeMeTko, če bi vsakič, ko pri varnostnem pregledu ali kaki drugi priložnosti vidim drain-bamage skonfiguriran mail/dns/web server, dobil evro, bi mi že odpadel poden od domače blagajne. Zatorej predlagam dihalne vaje in omiljeni napitek za pomirjanje. Get over it, zadeve se zaradi tvojega ranta ne bodo spremenile.
Seveda te moram še malo pojezit. Greylisting nima false positivov. Mail serverji na internetu upoštevajo standarde. Če ima kak end user (ob redkih priložnostih ko dobi mail iz vira ki ni na whitelisti), težavo počakat 15 minut, je odgovor že v enem prejšnjih postov.
--
Great minds run in great circles.
Great minds run in great circles.
NeMeTko ::
@Poldi - kaj se potem sploh oglašaš, če takointako spadaš v tisto skupino @poorman.si s tremi uporabniki - govora je o velikih domenah in providerjih, ki imajo sredstva in bi morali imeti tudi znanje, da stvari drugače rešijo.
Predstavljaj si, da VSI mail serverji na svetu začnejo uporabljati greylisting. Potem pa poskusi imeti mailing listo, bognedaj, da si velik provider, ki ponuja hosting za mailing liste, ki na uro razpošlje od 100k pa tja do 1M mailov.
Predstavljaj si, da si SIOL, pa da moraš po 15 min skladiščiti vse maile, ker jih strežniki nočejo prevzeti iz prve. Kakšne nadgradnje mašin bi potreboval?
Morda vsaj tako postane jasno, da je greylisting skrajno egoističen in potraten pristop?
@Brane22 - vidim, da nimaš praktičnih izkušenj z mail karantenami, o skeniranju in porabi CPU pri tem pa še manj. Nekje si nekaj slišal, dve stvari sprobal in se imaš za eksperta? Res lepo, da tebe CPU-wise nič ne stane - morda bi bila dobra ideja, da bi tebi zaračunavali CPU in disk tisti, ki jim ti spammaš mašine z greylistingom? Mogoče bi potem spremenil mišljenje?
Si kdaj preračunal, koliko spam sporočil lahko shraniš v 1 GB? Če pogledaš tipična spam sporočila, so velika od 2kB, pa tja do največ 50kB - večinoma pa nekje do 5kB. Tudi če smo radodarni pa vzamemo, da povprečno sporočilo zasede 10kB, jih v 1GB spraviš okoli 100.000. Ob uporabi kompresije pa cca. 10x toliko (ASCII znaki se komprimirajo do 90%). V kolikšnem času prejmeš 100.000 spam sporočil? Če dnevno uporabnik prejme 5-10 spam sporočil in imaš 1000 uporabnikov, boš v 1GB shranil spam treh mesecev. Običajno pa karantena samodejno čisti sporočila, ki so starejša od 30 dni...
Če povprečen uporabnik na dan prejme po 20 sporočil (spam+ham), to znaša 20.000 sporočil dnevno za podjetje s 1000 uporabniki. Če predpostavimo, da 70% sporočil prejmemo med 8 urnim delovnim časom, pridemo na 14.000 sporočil /8ur ali 30 sporočil/minuto - torej ima filter celi dve sekundi časa, sa poskenira posamezno sporočilo.
Torej - kako je zdaj s tisto mašino, ki bi počepnila zaradi aktivnega skeniranja maila?
Tudi če rečeš, da sem bil skromen pri številkah - pomnoži jih z 10, pa še vedno nebi smel imeti problema na povprečni dualcore mašini. Na takšnih mašinah komercialne rešitve skenirajo po 50k+ sporočil na uro (spam+AV)!
Ne vem, je res tako teško za malenkost pogledati preko svojih plank in vklopiti nekaj logike?
Če nimaš izkušenj iz prakse, da bi lahko utemeljeno argumentiral stališče - zakaj se zaganjaš v tistega, ki ti z argimenti skuša razložiti, da ima neka reč niz slabosti, s katerimi se je moral v praksi spopadati? Zagovarjaš neko tehniko, brez da bi v detajle vedel, kako v resnici deluje, katere so njene slabe strani in na kaj moraš paziti, da drugim ne povzročaš nepotrebnih sitnosti.
Moti me stališče 'jaz že vse vem' in nepripravljenost prisluhniti tujim izkušnjam. Kje je tu še pripravljenost, da bi spoznal in analiziral druge/nove rešitve, njihove prednosti in slabosti?
@ticko551 - verjetno imaš prav, da mi najbrž nikoli nebi padle v oči slabosti greylistinga, če bi bili ti sistemi optimalno poadministrirani, saj mi tako nebi nikoli povzročili težav, zaradi katerih sem se poglobil v njihovo delovanje.
Se pa ne strinjam s tabo, ko rečeš, da greylisting nima false positives. Res pa je, da je vprašanje, kaj pojmuješ kot false positives. Za mene je to vsako legitimno sporočilo, ki zaradi nekega filtrirnega mehanizma ni bilo dostavljeno v naslovnikov inbox - ne glede na to, če pošiljatelj dobi sporočilo o nedostavljivosti. V enem od zgornjih postov sem podal link na IETF draft o greylistingu, ki lepo našteva več slabosti greylistinga - tudi s strežniki, ki so 100% v skladu z RFC standardi. Dober in vesten admin lahko te slabosti 'kašira'. Kljub temu pa ostaja vprašanje, če je danes, ob toliko drugih razpoložljivih (in bolj učinkovitih) tehnikah še smiselno uporabljati greylisting.
Če si prebral začetek tematike, pa si lahko videl, da z mojim mail strežnikom ni bilo nič narobe - probleme je delal providerjev mail relay, na katerega kot uporabnik nimam popolnoma nobenega vpliva. Ne vem, kdo je greylisting tako zelo sporopagandiral, da se je v nekem trenutku začel množiti po Sloveniji. V glavnem je zadeva sčasoma postala tako nadležna, da sem bil prisiljen prekonfigurirati mail server in ukiniti rabo providerjevega relaya. Mera je bila polna, ko sem nekega dne moral 5x na roke resendat neko sporočilo, predenj je šlo skozi. Če že postaviš greylisting, bi lahko potem tudi skonfiguriral error message, da bi notri pisalo, na kako dolg timeout je strežnik nastavljen. Na splošno pa mislim, da je popolni nesmisel konfigurirati več kot 2-5 minut.
Predstavljaj si, da VSI mail serverji na svetu začnejo uporabljati greylisting. Potem pa poskusi imeti mailing listo, bognedaj, da si velik provider, ki ponuja hosting za mailing liste, ki na uro razpošlje od 100k pa tja do 1M mailov.
Predstavljaj si, da si SIOL, pa da moraš po 15 min skladiščiti vse maile, ker jih strežniki nočejo prevzeti iz prve. Kakšne nadgradnje mašin bi potreboval?
Morda vsaj tako postane jasno, da je greylisting skrajno egoističen in potraten pristop?
@Brane22 - vidim, da nimaš praktičnih izkušenj z mail karantenami, o skeniranju in porabi CPU pri tem pa še manj. Nekje si nekaj slišal, dve stvari sprobal in se imaš za eksperta? Res lepo, da tebe CPU-wise nič ne stane - morda bi bila dobra ideja, da bi tebi zaračunavali CPU in disk tisti, ki jim ti spammaš mašine z greylistingom? Mogoče bi potem spremenil mišljenje?
Si kdaj preračunal, koliko spam sporočil lahko shraniš v 1 GB? Če pogledaš tipična spam sporočila, so velika od 2kB, pa tja do največ 50kB - večinoma pa nekje do 5kB. Tudi če smo radodarni pa vzamemo, da povprečno sporočilo zasede 10kB, jih v 1GB spraviš okoli 100.000. Ob uporabi kompresije pa cca. 10x toliko (ASCII znaki se komprimirajo do 90%). V kolikšnem času prejmeš 100.000 spam sporočil? Če dnevno uporabnik prejme 5-10 spam sporočil in imaš 1000 uporabnikov, boš v 1GB shranil spam treh mesecev. Običajno pa karantena samodejno čisti sporočila, ki so starejša od 30 dni...
Če povprečen uporabnik na dan prejme po 20 sporočil (spam+ham), to znaša 20.000 sporočil dnevno za podjetje s 1000 uporabniki. Če predpostavimo, da 70% sporočil prejmemo med 8 urnim delovnim časom, pridemo na 14.000 sporočil /8ur ali 30 sporočil/minuto - torej ima filter celi dve sekundi časa, sa poskenira posamezno sporočilo.
Torej - kako je zdaj s tisto mašino, ki bi počepnila zaradi aktivnega skeniranja maila?
Tudi če rečeš, da sem bil skromen pri številkah - pomnoži jih z 10, pa še vedno nebi smel imeti problema na povprečni dualcore mašini. Na takšnih mašinah komercialne rešitve skenirajo po 50k+ sporočil na uro (spam+AV)!
Ne vem, je res tako teško za malenkost pogledati preko svojih plank in vklopiti nekaj logike?
Če nimaš izkušenj iz prakse, da bi lahko utemeljeno argumentiral stališče - zakaj se zaganjaš v tistega, ki ti z argimenti skuša razložiti, da ima neka reč niz slabosti, s katerimi se je moral v praksi spopadati? Zagovarjaš neko tehniko, brez da bi v detajle vedel, kako v resnici deluje, katere so njene slabe strani in na kaj moraš paziti, da drugim ne povzročaš nepotrebnih sitnosti.
Moti me stališče 'jaz že vse vem' in nepripravljenost prisluhniti tujim izkušnjam. Kje je tu še pripravljenost, da bi spoznal in analiziral druge/nove rešitve, njihove prednosti in slabosti?
@ticko551 - verjetno imaš prav, da mi najbrž nikoli nebi padle v oči slabosti greylistinga, če bi bili ti sistemi optimalno poadministrirani, saj mi tako nebi nikoli povzročili težav, zaradi katerih sem se poglobil v njihovo delovanje.
Se pa ne strinjam s tabo, ko rečeš, da greylisting nima false positives. Res pa je, da je vprašanje, kaj pojmuješ kot false positives. Za mene je to vsako legitimno sporočilo, ki zaradi nekega filtrirnega mehanizma ni bilo dostavljeno v naslovnikov inbox - ne glede na to, če pošiljatelj dobi sporočilo o nedostavljivosti. V enem od zgornjih postov sem podal link na IETF draft o greylistingu, ki lepo našteva več slabosti greylistinga - tudi s strežniki, ki so 100% v skladu z RFC standardi. Dober in vesten admin lahko te slabosti 'kašira'. Kljub temu pa ostaja vprašanje, če je danes, ob toliko drugih razpoložljivih (in bolj učinkovitih) tehnikah še smiselno uporabljati greylisting.
Če si prebral začetek tematike, pa si lahko videl, da z mojim mail strežnikom ni bilo nič narobe - probleme je delal providerjev mail relay, na katerega kot uporabnik nimam popolnoma nobenega vpliva. Ne vem, kdo je greylisting tako zelo sporopagandiral, da se je v nekem trenutku začel množiti po Sloveniji. V glavnem je zadeva sčasoma postala tako nadležna, da sem bil prisiljen prekonfigurirati mail server in ukiniti rabo providerjevega relaya. Mera je bila polna, ko sem nekega dne moral 5x na roke resendat neko sporočilo, predenj je šlo skozi. Če že postaviš greylisting, bi lahko potem tudi skonfiguriral error message, da bi notri pisalo, na kako dolg timeout je strežnik nastavljen. Na splošno pa mislim, da je popolni nesmisel konfigurirati več kot 2-5 minut.
Brane22 ::
@NeMeTko:
Ironično je,d a ravno ti, ki toliko mahaš krog s tem natančnim branjem podanih materialov spregledaš moj prejšnji post, kjer eksplicitno pravim, da se NIMAM za eksperta.
1. Poglej si definicijo za "spam" in spamanje. Nato se lahko pogovorimo dalje.
2. Tudi če pozabimo prvo točko, prav. Sprejmem. Če mi dobim nazaj tisto, kar s tem prišparam na prenosu podatkov, ki jim ni bilo treba čez kojekakve mreže in podmreže.
Povprečje me tu kot uporabnika ne zanima preveč. Poleg tega ga debelo presegam. Ti imaš sistem, na katerega bi se rad zanesel, ne pa pričakoval da ti dela, ko si v povprečju ali pod njim.
Kaj če dobiš polovico povprečja not v eni uri ? Koliko ima potem filter časa za skeniranje ? In kaj če ta tvoja šibka točka postane znana ?
kaj če te jaz začnem spamat ravno z namenom, da ti zaglupim server ? Evo, sem na netu na 100M optiki. kar je totalne mikroskopski drobiž za vsakogar, ki iam kakršnekoli resne agresivne namene, pa vendar, vzemimo za banalen primer. Če uporabim samo pol tega bandwidtha za spamanje, ti lahko pošljem teoretično 5.000 mailov v sekundi. Tistih "povprečnih" od 10k. Za nameček jih lahko generiram s psevdonaključnim tekstom da dam tvojim filtrom delat. To je en mail na 200 mikrosekund. Ti pa rabiš 1 sekundo za delo filtra.
Pa recimo da te CPUje imaš in da v ozadju stoji 5000 CPUjev in da se vsi potijo in delajo na polno in da vsak žge samo 100W. Koliko te stane samo štrom za tole ? CPUji žgejo 500kW. V eni uri porabijo torej 500kWh, torej cca €50. Samo za štrom, brez stroškov klimatizacije itd.
Ali z drugimi besedami toliko, kot ti jih jaz lahko pošljem prek 100M linka v 50 sekundah ?
Edit- v prejšnjejm primeru s 5000 corei sem zajebal zgleda za eno nulo. Ampak osnovni problem pa še vedno ostaja.
Brane22 - vidim, da nimaš praktičnih izkušenj z mail karantenami, o skeniranju in porabi CPU pri tem pa še manj. Nekje si nekaj slišal, dve stvari sprobal in se imaš za eksperta?
Ironično je,d a ravno ti, ki toliko mahaš krog s tem natančnim branjem podanih materialov spregledaš moj prejšnji post, kjer eksplicitno pravim, da se NIMAM za eksperta.
Res lepo, da tebe CPU-wise nič ne stane - morda bi bila dobra ideja, da bi tebi zaračunavali CPU in disk tisti, ki jim ti spammaš mašine z greylistingom? Mogoče bi potem spremenil mišljenje?
1. Poglej si definicijo za "spam" in spamanje. Nato se lahko pogovorimo dalje.
2. Tudi če pozabimo prvo točko, prav. Sprejmem. Če mi dobim nazaj tisto, kar s tem prišparam na prenosu podatkov, ki jim ni bilo treba čez kojekakve mreže in podmreže.
Če povprečen uporabnik na dan prejme po 20 sporočil (spam+ham), to znaša 20.000 sporočil dnevno za podjetje s 1000 uporabniki. Če predpostavimo, da 70% sporočil prejmemo med 8 urnim delovnim časom, pridemo na 14.000 sporočil /8ur ali 30 sporočil/minuto - torej ima filter celi dve sekundi časa, sa poskenira posamezno sporočilo.
Povprečje me tu kot uporabnika ne zanima preveč. Poleg tega ga debelo presegam. Ti imaš sistem, na katerega bi se rad zanesel, ne pa pričakoval da ti dela, ko si v povprečju ali pod njim.
Kaj če dobiš polovico povprečja not v eni uri ? Koliko ima potem filter časa za skeniranje ? In kaj če ta tvoja šibka točka postane znana ?
kaj če te jaz začnem spamat ravno z namenom, da ti zaglupim server ? Evo, sem na netu na 100M optiki. kar je totalne mikroskopski drobiž za vsakogar, ki iam kakršnekoli resne agresivne namene, pa vendar, vzemimo za banalen primer. Če uporabim samo pol tega bandwidtha za spamanje, ti lahko pošljem teoretično 5.000 mailov v sekundi. Tistih "povprečnih" od 10k. Za nameček jih lahko generiram s psevdonaključnim tekstom da dam tvojim filtrom delat. To je en mail na 200 mikrosekund. Ti pa rabiš 1 sekundo za delo filtra.
Pa recimo da te CPUje imaš in da v ozadju stoji 5000 CPUjev in da se vsi potijo in delajo na polno in da vsak žge samo 100W. Koliko te stane samo štrom za tole ? CPUji žgejo 500kW. V eni uri porabijo torej 500kWh, torej cca €50. Samo za štrom, brez stroškov klimatizacije itd.
Na takšnih mašinah komercialne rešitve skenirajo po 50k+ sporočil na uro (spam+AV)!
Ali z drugimi besedami toliko, kot ti jih jaz lahko pošljem prek 100M linka v 50 sekundah ?
Edit- v prejšnjejm primeru s 5000 corei sem zajebal zgleda za eno nulo. Ampak osnovni problem pa še vedno ostaja.
Zgodovina sprememb…
- spremenilo: Brane22 ()
Brane22 ::
Pa še to- v tej tvoji rešitvi osnovni problemi še vedno ostanejo.
Ni nobene koristi od 17.000 mailov v karanteni, če tega ne moreš ročno pregledat in bit ziher, da ne boš zgrešil nobenega koristnega maila.
Ti koneckoncev lahko dokupiš dodatna jedra in ram ter plačaš štrom zanje. Ampak pospeševanje premetavanja po karanteni pa zahteva še dodatne pare oči, ki gredo v paketu z možgani in plačano delovno uro itd.
Meni se zdi stvar neubranljiva ker ti potrebuješ veliko več CPU časa za analizo sporočila kot jaz za generacijo. Pa na koncu tvoj filter še vedno zahteva človeške oči, ki pa ne napredujejo tako hitro kot silicij, pa še skalirajo težko.
Za nameček pa so današnji bandwidthi taki da komot zafilajo CPU, ki bi bil sicer več kod zadosten.
Ni nobene koristi od 17.000 mailov v karanteni, če tega ne moreš ročno pregledat in bit ziher, da ne boš zgrešil nobenega koristnega maila.
Ti koneckoncev lahko dokupiš dodatna jedra in ram ter plačaš štrom zanje. Ampak pospeševanje premetavanja po karanteni pa zahteva še dodatne pare oči, ki gredo v paketu z možgani in plačano delovno uro itd.
Meni se zdi stvar neubranljiva ker ti potrebuješ veliko več CPU časa za analizo sporočila kot jaz za generacijo. Pa na koncu tvoj filter še vedno zahteva človeške oči, ki pa ne napredujejo tako hitro kot silicij, pa še skalirajo težko.
Za nameček pa so današnji bandwidthi taki da komot zafilajo CPU, ki bi bil sicer več kod zadosten.
Zgodovina sprememb…
- spremenilo: Brane22 ()
NeMeTko ::
Ne vem kaj hočeš povedati, ko navajaš nek fiktivni DDOS napad, pod katerim bi ti počepnil tudi greylisting.
Poleg tega pred vsak mail server sodi firewall, kjer definiraš maksimalno dovoljeno število connection/sec, tako da tisti napad dejansko nikoli ne pride do mail serverja, saj ti preobremeni že firewall (če je zares obsežen).
Če takšne reči vlečeš na dan, si lahko kvečjemu mislim, da dejansko nimaš pojma, kako se te reči v praksi postavlja in kako naj bi delovale.
Tako se lahko samo vprašam, kaj vraga sploh diskutiram s tabo, če ne veš, o čemu pravzaprav govoriš.
Poleg tega pred vsak mail server sodi firewall, kjer definiraš maksimalno dovoljeno število connection/sec, tako da tisti napad dejansko nikoli ne pride do mail serverja, saj ti preobremeni že firewall (če je zares obsežen).
Če takšne reči vlečeš na dan, si lahko kvečjemu mislim, da dejansko nimaš pojma, kako se te reči v praksi postavlja in kako naj bi delovale.
Tako se lahko samo vprašam, kaj vraga sploh diskutiram s tabo, če ne veš, o čemu pravzaprav govoriš.
Brane22 ::
Ne vem kaj hočeš povedati, ko navajaš nek fiktivni DDOS napad, pod katerim bi ti počepnil tudi greylisting.
Bistveno težje.
Poleg tega pred vsak mail server sodi firewall, kjer definiraš maksimalno dovoljeno število connection/sec, tako da tisti napad dejansko nikoli ne pride do mail serverja, saj ti preobremeni že firewall (če je zares obsežen).
Res ? Ampak kaj če je vsaj majhen del teh mailov legalnih ? A ni mantra tvoje cerkve da sprejmeš VSAK mail, sicer je konec sveta ?
Kako bi ti sploh lahko živel sam s seboj ob polni zavesti, da si firewallom mogoče obglavil kak nedolžen mail ?
A ni to smrten greh v tvoji religiji ?
Zgodovina sprememb…
- spremenilo: Brane22 ()
Brane22 ::
Sploh pa, število mailov ni vedno enako številu connectionov.
Postfix AFAIK zna in tudi uporablja connection reuse in ne gre odpirat novega TCP socketa za vsak novi mail v seriji.
Da ne govorimo o tem,d a bi lahko izvedel distribuirani napad.
Ti bi seveda lahko zahteval, da je vsak pošiljatelj naveden kot MX v domeni ali celo da ima veljaven SPF record.
Če tvoja religija tega ne bi izrecno prepovedovala, ker tao lahko ubiješ kak nedolžen email...
Postfix AFAIK zna in tudi uporablja connection reuse in ne gre odpirat novega TCP socketa za vsak novi mail v seriji.
Da ne govorimo o tem,d a bi lahko izvedel distribuirani napad.
Ti bi seveda lahko zahteval, da je vsak pošiljatelj naveden kot MX v domeni ali celo da ima veljaven SPF record.
Če tvoja religija tega ne bi izrecno prepovedovala, ker tao lahko ubiješ kak nedolžen email...
NeMeTko ::
Glej, k se še kar duvaš in vsiljuješ svoj fiktivni DDOS scenarij - zakaj že?
Ker je tako prekleto teško priznati, da držijo stvari, o katerih sem govoril in se tudi omenjajo v IETF draftu?
Ker je tako teško priznati, da si prelen, da bi naštudiral in izprobal še kakšno drug opensource rešitev?
Ja res ti je treba. Grow up poba, malo izkušenj si naberi v realnih omrežjih in jih poskusi tudi optimizirati, ne pa vse samo po sistemu 'meni dela, če pa sosedu crkne krava, mi je pa vseeno'.
Ker je tako prekleto teško priznati, da držijo stvari, o katerih sem govoril in se tudi omenjajo v IETF draftu?
Ker je tako teško priznati, da si prelen, da bi naštudiral in izprobal še kakšno drug opensource rešitev?
Ja res ti je treba. Grow up poba, malo izkušenj si naberi v realnih omrežjih in jih poskusi tudi optimizirati, ne pa vse samo po sistemu 'meni dela, če pa sosedu crkne krava, mi je pa vseeno'.
Brane22 ::
Ne razumem te. Nimam nekega ponosa, ki bi ga moral branit.
Podal sem samo svoj pogled, brez nekega namena ga branit do zadnjega diha. Pravzaprav tega namena ne kažem praviloma.
Briga me res kdo je profi in kdo ne, to so itak samo mentalne nalepke. Važne so mi vsebine.
Ki nekako v teh tvojih postih, vsaj iz mojega zornega kota nimajo poštimanih logičnih čeksumov.
Če se motim, fajn. Ti že veš. Jaz sem samo odgovarjal in kazal na nelogičnosti, kot jih vidim sam.
Nisem se imel najmanjšega namena "duvat". Ne maram pa mentalnih masturbacij drugih. Te prijeme obvladam tudi sam.
Podal sem samo svoj pogled, brez nekega namena ga branit do zadnjega diha. Pravzaprav tega namena ne kažem praviloma.
Briga me res kdo je profi in kdo ne, to so itak samo mentalne nalepke. Važne so mi vsebine.
Ki nekako v teh tvojih postih, vsaj iz mojega zornega kota nimajo poštimanih logičnih čeksumov.
Če se motim, fajn. Ti že veš. Jaz sem samo odgovarjal in kazal na nelogičnosti, kot jih vidim sam.
Nisem se imel najmanjšega namena "duvat". Ne maram pa mentalnih masturbacij drugih. Te prijeme obvladam tudi sam.
NeMeTko ::
@Brane22 - jaz, če sem enkrat zložil papirnat avionček in mi je lepo letel, ne bom šel na Brnik pa sral pilotu Airbusa, kakšno sranje on to fura po nebu, češ da takoj pade dol, ko mu crknejo motorji.
Točno tako pa se obnašaš ti. V materijo se sploh nisi poglobil. Namestil si greylisto, stvar ti dela in boli te kiki, če mogoče komu drugemu delaš štalo, še manj razmišljaš o temu, kaj bi bilo, če bi vsi uporabljali greylisting. Ne - po tvoje je cool, tebi dela, vse ostale pa kiki gledal - itak so idioti. Mar ne?
Kako bi bilo, če bi v bloku na glas navijal glasbo? Tebi je cool, če soseda moti, je pa sosed čudak? Kaj če bi vsak v bloku navijal glasbo do daske, kolikor mu znese veršterkeraj?
Točno tako pa se obnašaš ti. V materijo se sploh nisi poglobil. Namestil si greylisto, stvar ti dela in boli te kiki, če mogoče komu drugemu delaš štalo, še manj razmišljaš o temu, kaj bi bilo, če bi vsi uporabljali greylisting. Ne - po tvoje je cool, tebi dela, vse ostale pa kiki gledal - itak so idioti. Mar ne?
Kako bi bilo, če bi v bloku na glas navijal glasbo? Tebi je cool, če soseda moti, je pa sosed čudak? Kaj če bi vsak v bloku navijal glasbo do daske, kolikor mu znese veršterkeraj?
Poldi112 ::
V bistvu se ti obnašaš tako, stojiš na svojem kupu gnoja in se ne premakneš od tam. Namesto da bi argumentiral se sklicuješ na lastno avtoriteto. Očitno te je hudo zabolelo, ko si dobil v obraz, da bo tvoj firewall porezal legitimen mail :)
>Predstavljaj si, da si SIOL, pa da moraš po 15 min skladiščiti vse maile, ker jih strežniki nočejo prevzeti iz prve. Kakšne nadgradnje mašin bi potreboval?
Zih boš moral podvojiti kapacitete, ker 15 min skladiščenja za en mali del pošte je adijo pamet.
>Morda vsaj tako postane jasno, da je greylisting skrajno egoističen in potraten pristop?
Egoističen - pa ja. Potraten - ne. Zaradi njega mi spam občutno manj obremenjuje server. Kot rečeno, pa si ignoriral - koliko ti pa 75% prometa, ki je spam, obremenjuje server? In koliko uporabnike?
>Če nimaš izkušenj iz prakse, da bi lahko utemeljeno argumentiral stališče - zakaj se zaganjaš v tistega, ki ti z argimenti skuša razložiti, da ima neka reč niz slabosti, s katerimi se je moral v praksi spopadati?
Ne vem od kda je: "graylisting evil, fuck off bedniki" argument. Edino kar si dal je en rfc, kjer piše, da lahko pride do težav. In to ti je očitno sveto.
>Mera je bila polna, ko sem nekega dne moral 5x na roke resendat neko sporočilo, predenj je šlo skozi.
A si ziher, da znaš skonfigurirat mail server? :)
>Predstavljaj si, da si SIOL, pa da moraš po 15 min skladiščiti vse maile, ker jih strežniki nočejo prevzeti iz prve. Kakšne nadgradnje mašin bi potreboval?
Zih boš moral podvojiti kapacitete, ker 15 min skladiščenja za en mali del pošte je adijo pamet.
>Morda vsaj tako postane jasno, da je greylisting skrajno egoističen in potraten pristop?
Egoističen - pa ja. Potraten - ne. Zaradi njega mi spam občutno manj obremenjuje server. Kot rečeno, pa si ignoriral - koliko ti pa 75% prometa, ki je spam, obremenjuje server? In koliko uporabnike?
>Če nimaš izkušenj iz prakse, da bi lahko utemeljeno argumentiral stališče - zakaj se zaganjaš v tistega, ki ti z argimenti skuša razložiti, da ima neka reč niz slabosti, s katerimi se je moral v praksi spopadati?
Ne vem od kda je: "graylisting evil, fuck off bedniki" argument. Edino kar si dal je en rfc, kjer piše, da lahko pride do težav. In to ti je očitno sveto.
>Mera je bila polna, ko sem nekega dne moral 5x na roke resendat neko sporočilo, predenj je šlo skozi.
A si ziher, da znaš skonfigurirat mail server? :)
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Bakunin ::
bruh.
se enkrat preberi ...pa pocasi...
Internet in vsi servisi povezani z njim so bili nastavljeno tako da podatek nekako PRIDE (tudi z retry) do naslovnika.
Ceprav to traja par dni.
Ce zelis HIPNO komunikacijo imas druge nacine transporta (v zivo, telefon, fax, ...).
Lahko potocis se toliko solz in pizdis da ti hoces to takoj - tako pac je.
get over it.
on ne razume, da neglede na to kar ON zna... mora ta njegov umotvor komunicirat z ostalimi.
in se jezi, ker ostali ne igrajo po NJEGOVIH pravilih (pogledih na svet).
RFC in ostali "standardi" so zato, da ta masa ljudi sploh komunicira med seboj.
kako bi bilo, ce bi vsak po svoje govoril ängléskó ?
se enkrat preberi ...pa pocasi...
Internet in vsi servisi povezani z njim so bili nastavljeno tako da podatek nekako PRIDE (tudi z retry) do naslovnika.
Ceprav to traja par dni.
Ce zelis HIPNO komunikacijo imas druge nacine transporta (v zivo, telefon, fax, ...).
Lahko potocis se toliko solz in pizdis da ti hoces to takoj - tako pac je.
get over it.
A si ziher, da znaš skonfigurirat mail server? :)
on ne razume, da neglede na to kar ON zna... mora ta njegov umotvor komunicirat z ostalimi.
in se jezi, ker ostali ne igrajo po NJEGOVIH pravilih (pogledih na svet).
RFC in ostali "standardi" so zato, da ta masa ljudi sploh komunicira med seboj.
kako bi bilo, ce bi vsak po svoje govoril ängléskó ?
Zgodovina sprememb…
- spremenil: Bakunin ()
brodul ::
off-topic:
Koncno neka dobra tema na slo-tech po pol leta.
Hvala, jst sem se ze ful naucil.
Koncno neka dobra tema na slo-tech po pol leta.
Hvala, jst sem se ze ful naucil.
Pretending to be a mature adult is so exhausting.
NoName ::
:) Bom še malo pristavil svoj pisker.
- če se ne motim, je zadnji SMTP RFC (ki obsoleta 2821) s številko 5321, pisan leta 2008, in ne 'pred 30 leti', kot navaja NeMeTko
- ne glede na dolgo in široko obrazložitev, kako slab in zlovešč je greylisting, se s trditvijo ne strinjam, saj skrbim za strežnike s 100k+ uporabniki, kjer se dnevno prepošlje kakih 100k sporočil, in je v izhodnih queue-ih je v povprečju pod 200 sporočil hkrati, tako da mi greylisting ne predstavlja večjih težav.
Greylisting, kar se mene tiče, ne porablja veliko sistemskih resursov; ko se mail queueja na serverju, se takoalitako shrani na disk, potem se pa samo prestavi v deferred mapo; kar se pa bandwidtha tiče, pa tudi ne, saj se izvede pred DATA fazo, ki dejansko prenaša tiste megabajte sporočila...
- če se ne motim, je zadnji SMTP RFC (ki obsoleta 2821) s številko 5321, pisan leta 2008, in ne 'pred 30 leti', kot navaja NeMeTko
- ne glede na dolgo in široko obrazložitev, kako slab in zlovešč je greylisting, se s trditvijo ne strinjam, saj skrbim za strežnike s 100k+ uporabniki, kjer se dnevno prepošlje kakih 100k sporočil, in je v izhodnih queue-ih je v povprečju pod 200 sporočil hkrati, tako da mi greylisting ne predstavlja večjih težav.
Greylisting, kar se mene tiče, ne porablja veliko sistemskih resursov; ko se mail queueja na serverju, se takoalitako shrani na disk, potem se pa samo prestavi v deferred mapo; kar se pa bandwidtha tiče, pa tudi ne, saj se izvede pred DATA fazo, ki dejansko prenaša tiste megabajte sporočila...
I can see dumb people...They're all around us... Look, they're even on this forum!
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Poštni strežnik in nedosegljivostOddelek: Omrežja in internet | 6400 (5716) | jype |
| » | SMTP TLS enkripcijaOddelek: Informacijska varnost | 1873 (1724) | AndrejO |
| » | Lastni poštni strežnik(kako ne biti označen kot spam)Oddelek: Omrežja in internet | 3331 (2891) | BlackPanx |
| » | Postfix MX lookupOddelek: Omrežja in internet | 2302 (1901) | Bakunin |
| » | Standardizirane tehnologije za boj proti neželeni e-poštiOddelek: Novice / Omrežja / internet | 3649 (3174) | kronik |