SMTP promet

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.

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

b3D_950 je 25. sep 2012 ob 15:27 izjavil:

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.

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

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.

NoName je 26. sep 2012 ob 09:46 izjavil:

Če prejemnikov mail server sedaj zavrne sporočilo z napako 4xx,...

ce bi le ljudje BRALI sporocila o napakah.

NeMeTko je 26. sep 2012 ob 10:58 izjavil:

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?

@NeMeTko, imam quote zate:

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!

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.

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.

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

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

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

@NeMeTko:

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

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.

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:

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.

misek je 26. sep 2012 ob 18:55 izjavil:

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.

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?

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

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

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.

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 ?

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

@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?

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.

Poldi112 je 27. sep 2012 ob 09:32 izjavil:

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ó ?

:) 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...