SMTP promet

@NoName - predpostavka je bila: kaj bi bilo, če bi VSI uporabljali greylisting (po možnosti slabo skonfiguriranega?)
Nenadoma nebi imel 200 sporočil v queue ampak ....? Deferred mapa bi narasla na.....?

DOBRA tehnologija je tista, ki bi jo priporočil, naj jo uporabljajo VSI.
Če bi jo VSI uporabljali, bi se moral pokazati nek pozitiven efekt na resursih, zanesljivosti, ipd.

UPORABNA tehnologija je tista, ki jo lahko priporočaš in prinaša določene koristi vsaj določenemu krogu uporabnikov. Hkrati se obnaša nevtralno glede resursov, če to tehnologijo VSI uporabljajo.

SLABA tehnologija je tista, ki sicer prinaša prednosti določenemu krogu uporabnikov, dejansko pa postane fail, če bi to tehnologijo uporabljali VSI.

čisto tako, med nami, in če ni kaka poslovna skrivnost. kakšno programsko opremo in konfiguracijo pa uporabljaš na svojih sistemih, ter, koliko uporabnikov imaš na njih?

@nemetko
Zdej pa gres meni in se mnogim na kikija s svojimi arogantnimi in vzvisenimi izjavami.

krho je 27. sep 2012 ob 12:52 izjavil:

mx 10 vrneš 4xx, ne bo šel na mx 11, ampak bo še kar naprej tupil in se povezoval na mx 10.

nope, ker na tistih tcp portih nic ne poslusa.

remote smtp bo dobil 'tcp timeout' ali pa icmp 'port unreachable' ali 'admin prohibited'
in bo sel na naslednji MX - kot veli RFC. ;]

vecina virusev, trojancev ipd. s***tware ima minimalno kodo kar se smtp tice in zato "bombardirajo" samo MX z najvisjo ali z najvisjo prioriteto. vse z namenom, da na vsak nacin svoje s**** spravijo skozi.

ce hoces TAKOJ, potem se naroci na SMS obvescanje iz enaa
pa se tisto ima zamik, ce nimas signala....

saj tudi na cesti pocakas v koloni, ce je cesta proti tvojemu cilju "zabasana". ali kar obupas in p*** nad DARS/DRSC ?

Zdaj pa tko. Še en komentar kjerkoli, ki ne bo dobro argumentiran gre v kanto. Dvignite nivo debate in podkrepite svoje trditve.

Upam da se primerni zavedajo koga se drži.

Poldi112 je 27. sep 2012 ob 13:51 izjavil:

>Na koncu koncev, če iz enaa dobim mail, da me čaka roba za prevzem, potem hočem mail videt takoj in ne čez 15 minut.

Funny, 15 minut je kriza, primer je pa nakup v spletni štacuni in obvestilu, da roba čaka. Bolje, da ne pomisliš, koliko časa bi prihranil, če bi šel v fizično trgovino. :)

Evo tipičen primer administratorja, ki uporablja graylisting. Zna mi povedat kako sem neumen, ker kupujem v enaa in se mi gre za 15 minut. Spregleda pa, da v fizičnih trgovinah, kjer imajo stvari na polici, da so cene precej višje.

Glede tega filtriranja:

Študiranje postfixa in podobnega programja mi je vzelo manjšo večnost. Poreblem je v tem, ker je vse tako tesno povezano, vse od strukture maila, preko narave TCP in IP protokola, DNS zapisov do internih stvari OS-a, kot so kreacija procesov itd. Se pravi, daleč nad golim poznavanjem SMTP.

Inicialne trditve o tem, kako da je postfix optimiziran za high-bandwidth okolja so mi dale občutek, da je to rešitev na ključ, ki jo moram le pravilno skonfigurirati. Mislil sem, da je stvar izvedena tako hekersko natančno in kompaktno kot je recimo varnish. Pa je čisto nasprotje temu.
Namesto kompaktne kode ima postfix kup procesov, ki si med seboj pošiljajo sporočila in maile. Tako je filtriranje izpeljano podobno stvaritvam iz risanke "Ptice trkačice". Ko je mail sprejet ga en porces preda procesu filtra. Ko ta konča svoje delo in poda svoje mnenje, se mail vrne procesu, ki ga potem dispatcha naprej.

Potem so filtri. Srat me je prijelo, ko sem videl izvedbe pisane v interpreterskih jezikih, kot je recimo PERL.

Wietsjevi nasveti ob filtriranju govorijo jasno o tem, da to ni tehnično rešen problem, ampak da zahteva "štelanje" za vsako okolje in razmere posebej.

Po vsem tem sem poiskal najhitrejši no-nonsense filter, ki sem ga uspel najti. Zaenkrat je to DSPAM. Če bo treba, je to rešitev, ki jo bom uporabil.
NIsem pa je šeinštaliral, ker to IMO ni solidna tehnična rešitev.

Vedno v teh zadevah geldan ma problem z obeh strani. Če inštaliram defenzivno orodje, vedno razmišljam tudi o tem, kako bi ga napadel sam in kako bi se učinkovito branil. In pri spam-filtru nimam obrambe na svoj napad. Zato si ga ne upam postavit gor brez dodatnih mehanizmov.

@NeMeTko:

In ničesar ne vidim v tvojih trditvah, kar bi me prepričalo v nasprotno. Za greylisting praviš, da je ad-hoc rešitev, ki je pravi profiji ne bi smeli uporabljat. Ampak ko ti pa postavim par problematičnih vprašanj o spam-filtru pa praviš, da se s temi fikivnimi problemi ne misliš ukvarjat.

In nato braniš svojo rešitev z NATANKO istimi argumenti, ki jih očitaš drugim - "meni to dela".

BTW, zakaj misliš, da ima ST tako čudno omejitev postanja - samo nekih 1500 chars po postu, kar potem lahko dodajaš v korakih in podobne štose ?

Zaradi podobne linije napada ki skrbi mene pri mailu.

>- takšni ki po porihtajo stvari, da po njihovem mnenju delujejo in jim je prav malo mar, če so uporabniki z njihovimi nastavitvami zadovoljni.

Moji uporabniki niso tako občutljivi kot vidva, ki zahtevata, da se vsak mail prejme in pošlje instantno. Ker realnost je taka, da si vedno odvisen od sosednjega smtp serverja in na konfiguracijo tistega nimaš vpliva. Tako da kot uporabnik ne moreš pričakovati 100% instant maila ne glede na to, kako imaš pri sebi stvari skonfigurirane (razen jasno za interno pošto).

Plus da gladko ignoriraš dejstvo, da graylisting malo zakasni zgolj zanemarljivo število leginimnega prometa. Kar pomeni, da ga uporabniki v 99+% ne občutijo. Ampak ne, vidva iz tega delata celo katastrofo, bog ne daj da bi en mail sem ter tja malo zamudil, svet se bo podrl.

>Zna mi povedat kako sem neumen, ker kupujem v enaa in se mi gre za 15 minut.

Nikjer nisem rekel, da si neumen, zgolj da se mi zdi smešno, da ti potencialna zamuda 15 minut predstavlja tako krizo ob dejstvu, da kupuješ v trgovini, kjer imaš zamudo med nakupom in prevzemom koliko, en dan?

Da bi se lahko smatralo greylisting za legitimno metodo filtriranja spama, je osnovni predpogoj, da je zadeva optimalno poadministrirana.

Takšna administracija zahteva spremljanje legitimne pošte in strežnikov s katerih prihaja ta pošta.
Greylisting omogoča, da si zgradimo bazo, v kateri imamo zavedene vse strežnike in domene, za katere vemo, da niso problematični. V takšno permanentno whitelisto bi spadal tudi T-2 mail relay.

Če kljub temu, da mail admina opozoriš, da ti povzroča težave, ta ne ukrene NIČESAR, da bi postavil T-2 relay na permanentno whitelisto, ti postane jasno, da je nekaj narobe s to tehnologijo, ki pogojuje, da se te nek admin usmili in porihta svoj sistem.

Da greylisting povzroča probleme, kadar se gre za večje serverske farme ali clustre, je že dolgo znano. Ne vem, ali T-2 ima mail relay v clustru, pa da od tod izvira problem z greylistingom (nikoli ni problemov z resendingom, če je dejanski razlog problem na omrežju ali realni error 4xx), vendar to tudi ne rabim vedeti.

Admin, ki optimira svoj sistem, bi moral že sam občasno naresti statistiko domen za pošto, ki je bila zavrnjena in posebno pozornost polagati na slovenske domene. Tako bi tudi sam opazil, da se na določenih strežnikih ponavlja zavračanje sporočil. Temu ustrezno lahko tudi potem dopolni svojo permanentno whitelisto.

Ravno tako tudi ni problem na netu dobiti seznam slovenskih CIDR blokov in na njemu zgraditi svojo whitelisto, s katere kasneje odstraniš IP naslove, ki povzročajo težave s spamom (odprti relayi itd.). Če iz te liste izvzameš vse IP-je, ki se pri providerjih dinamično dodeljujejo, si še nekoliko bližje optimumu.

Z malenkost truda se tako lahko postavi greylisting sistem, ki ne bo nobenemu slovenskemu pošiljatelju povzročal kakršnihkoli dodatnih zamud pri dostavi pošte ali to celo zavračalo.

Žal je praksa drugačna. Večinoma se uporablja dinamično whitelisto, na permanentni pa se mogoče najde kvečjemu kakšen strežnik, za katerega je nekdo od vodilnih pošteno zaropotal, zakaj mu mail ni dostavljen promptno ampak z zamudo.

Namesto, da bi se oglasila in rekla 'nekaj je pa res na temu, bom pogledal, morda pa res lahko zoptimiziram sistem', se gresta kregati in uporabniku razlagati, da tistih 15 min bo pa že preživel. Tehnika to preživi, poslovni svet pa danes to vse manj tolerira, sploh če ni potrebno in bi se to lahko rešilo z nekaj malega dodatnega konfiguriranja.

V poslovnem svetu si s partnerjem na telefonu, diskutiraš o neki zadevi, mu pošlješ datoteko in hočeš prediskutirati njeno vsebino. Tu je že kasnitev dveh minut nadležna, kaj šele 5, ali celo 15 minut. Stvar mora delovati promptno in tudi LAHKO tako deluje - če je pravilno poadministrirana. Če sporočilo v 2 min še vedno ni dostavljeno, se začne uporabnik spraševati, če morda ni narobe vpisal naslova. Misli si, da se je stvar nekje 'zataknila'. Neredko gre potem isto sporočilo ponovno poslati. Tudi če je dobil sporočilo, da mail ni dostavljiv, bo pomislil, da se je zatipkal v naslovu - redko kateri uporabnik gre tista sporočila odpirati in tuhtati kaj bi tista solata notri lahko pomenila, pa tudi če bi, večina tistega takointako ne zastopi.


Tisti primer s spletno trgovino je nadležen, ni pa še maksimalno kritičen. Kritično postane pri poslovnih procesih, kakršenga sem navedel zgoraj. Zelo veliko je takšnih procesov, kjer vsaka minuta šteje. Če si recimo IT podjetje, ki nudi podporo svojim uporabnikom, pa ti uporabnik po mailu posreduje podatke, ki jih potrebuješ za reševanje njegovega primera. Si res lahko privoščiš čakanje do 15 minut, da ti prispe uporabnikov mail? Če ga imaš po možnosti še na plačljivi telefonski liniji in mu med tem impulzi tečejo.... ne vem, res ne vem?

Pa ne se prosim izgovarjati na instant messaging, SMS in podobno. SMTP je danes tako dozorel, da lahko povsem enakovredno dostavlja sporočila - brez zamude. Uvajanje rešitev, ki degradirajo service level na tistega, ki smo ga poznali pred 20 in več leti, pa ne sme biti nikomur v ponos.

Kadar govorimo o RFC, pa moramo imeti pred očmi, da je vedno govora o predpisani 'minimalni implementaciji'. Resend se je najprej navajal kot 'možnost', kasneje kot 'priporočljivo' nazadnje pa kot 'obvezno'. Super in prav je tako - predpisuje se pač višji service level ustrezno stanju tehnologije in samega omrežja.
Kaj pa če bo naslednji RFC prepisal, da se ne sme uporabljati 'fake error 4xx'? Če bo predpisal, da ne sme biti na dostavni poti ničesar, kar bi znatno vplivalo na hitrost dostave sporočil nad teoretično možno?
Poeg tega RFC sam nima posebno velikega pomena, če ne upoštevamo tudi pravil 'dobre prakse'.

Pa nikar mi zdaj ne prihajajta spet s tem, kako sta bolj pametna od mene. Predpostavimo, da sem navaden stupid user, ki ni še nikoli slišal za kakšen RFC, IETF, smtp in greyliste. Stupid user, ki točno ve, da mail z 1MB priponko pride ponavadi do pošiljatelja v manj kot minuti. Vem, da to povsod deluje - samo takrat ne, ko sem v firmi z nekom na telefonu - takrat pa moram s sogovornikom pretehtavati, ali naj ponovno pošlje, ali pa bom še malo počakal, pa da ga pokličem nazaj, ko bo zadeva preko gnilega firminega omrežja končno dospela.

Ja, admin se mora znati postaviti v kožo uporabnika, pa bo marsikaj razumel čisto drugače.

You didn't get the point.

Uporabljaj greylisting - ampak za boga milega, ne ga pustiti na default nastavitvah!

Tačas, ko si tuhtal za filtri, bi lahko dodal vse SLO MX-e/domene v permanentno whitelisto in rešil 90% problematike o kateri je govora.

V poslovnem svetu si s partnerjem na telefonu, diskutiraš o neki zadevi, mu pošlješ datoteko in hočeš prediskutirati njeno vsebino. Tu je že kasnitev dveh minut nadležna, kaj šele 5, ali celo 15 minut.

Za te probleme celo tako majhna firma kot je naša ima druge rešitve.

Postavim fajl na fileserver, njemu pa dam ( ponavadi že prej link na mapo) link je simpl in ga lahko zdiktiram tudi po telefonu, če je treba.

Tako se mi ni treba ubadat s tem, kaj bi preostanek sveta moral ali pa ne bi smel in zaupam temu, kar jaz lahko ali hočem.

Saj tega ne pričakujem od nje.

Dal ji bom link, na karega bo kliknila in odprlo se bo okno z vsebino mape. V to mapo bo lahko tudi sama poslala dokument.

Za to lahko uporabim bodisi ftp ali pa kar http/s protokol z možnostjo webdav ali celo brez.

In to kar iz browserja. Ne vidim, kaj je tu inherentno bolj nevarnega kot pri emailu.

Jaz lahko uporabim https. A lahko nepismena referentka kriptira email rutinsko ?

Včasih smo to delali kar prek ftp. Mislim,d a je Explorer imel tudi možnost uploada.

Zagrabil si datoteko in jo odnesel na borwserjevo ono in jo tam izpustil, pa jo je stvar prenesla.

Zdaj tega ne upirabljamo več, ker niti ni potrebe. Ampak razmišljam o http verziji.

V bsitvu bi glede na planirano izvedbo novega serverja tudi to lahko izpeljal za malo malico.

Komot lahko ustvariš one-time ali recimo one-day mapo, kamor naložiš datoteko kar iz browserja, nato pa link pošlješ željenemu naslovniku.

Samo tak link težko potem diktiraš po telefonu, ker so ponavadi daljši. Če pa mail ni problematičen, je to rešitev.

Možno je tudi to, da stranki po telefonu daš password in enostaven link na mapo za ta namen. Tam poišče mapo s svojim imenom in jo odpre in to je to.

Brane22 je 29. sep 2012 ob 02:47 izjavil:

EDIT- ok, vidim da hočeš zaščito za vsak individualen mail.

Mi nismo imeli teh potreb. Nikoli nismo delali s 5.000 podjetji ampak mogoče s 50.

In če je imelo vskao podjetje svojo mapo, v katero so lahko nalagali datoteke in jih jemali, je bilo za naše potrebe čezinčez dost.

Saj to sem mislil - če imaš 50 STALNIH partnerjev in max. 10 zaposlenih, ki smejo videti vse podatke, si lahko privoščiš bistveno večjo 'umetniško svobodo'.

Čim pa imaš poleg stalnih strank še kup občasnih 'padalcev', na svoji strani veliko uporabnikov, različne tipe podatkov, med katerimi nekateri podlegajo varstvu osebnih podatkov, drugi pa so poslovne skrivnosti, je pa zelo hitro konec z 'umetniško svobodo'.

Ne misliti, da ne poznam ftp strežnikov in sistem accountov, ki je lahko čisto ločen od sistemskih. Enako je s http strežnikom.

Vendar resnično nebi želel, da lahko kdorkoli v podjetju dodaja ali briše uporabnike na ftp ali http strežniku.

Alternativa bi bila kakšna preprosta php aplikacija, ki bi omogočala vsakemu uporabniku, da znotraj te aplikacije kreira accounte za 'njegove' sogovornike. Taka aplikacija bi v bazi z lahkoto shranjevala podatke o prenosih, uporabnika omejevala, da bi videl le tiste datoteke, ki jih je sam naložil za določenega naslovnika, naslovnika pa omejevala, da bi videl le datoteke, ki so namenjene njemu.

Skratka moraš se 'odmakniti' od file sistema in prepustiti aplikaciji, da skrbi za varnost.
Glede na to, da zadeva niti nebi smela biti preveč zahtevna za sprogramirati, bi bilo čudno, če se kaj v tem smislu nebi našlo v oprensource-u

Se pravi,da bo NeMeTko šel izmuljat tisto, kar vsaj zadnji 2 verziji Thunderbird podpira že out of the box.. BigFile

Z zanimanjem berem tole temo in se po malem smejim. Nisem admin, ne poznam podrobnosti delovanja mail strežnikov, ... ampak vidim pa, da NeMeTko sicer veliko ve, ampak se ne želi naučiti še kaj več. Ostaja zaprt v svoji škatli in modruje kako misli da deluje ta rešitev, namesto da bi si vzel 3 minute in malce prebral. Če bi namreč vsaj na hitro pogledal to BigFile podporo na Thunderbirdu bi videl, da se v mailu pošlje samo povezava na datoteko na nekem strežniku. Shranjevanje datoteke na strežnik, kreiranje povezave in vse kar je pač porebno pa naredi tale plugin.

In tudi za Outlook obstaja en kup podobnih rešitev.

Nesramen in žaljiv? Mhm, jaz tega ne vidim tako. Samo napisal sem, da namesto da si prebereš kako rešitev deluje raje razpredaš o morebitnih možnosti. In to na dolgo in široko.
Sem prepričan, da bi manj časa porabil, če bi prebral nekaj vrstic o tej thunderbird razširitvi kot o pisanju celega odstavka.

Glede prihajanja na forum: prihajam zato, da zvem kaj novega. In ne, nimam navade izlivati kakšnih frustracij na nikogar. Tole sedaj je bila izjema. In mislim da ni bilo izlivanje frustracij. Če že se je to velikokrat pokazalo ravno iz tvoje strani.

Verjetno bi potreboval nek dokumenti sistem. Npr. Alfresco (je bil en članek v reviji MonitorPRO pomlad 2012) ali pa ownCloud (trenutno sicer beta verzija). Če imaš kakšne posebne želje, lahko napišeš feature request. Pri slednjem sem za lastno rabo nekaj dodal, da mi beleži kdo se prijavil in kdaj, ter iz katerega IP naslova.

Edini varen in efikasen nacin je, da uporabljas le mail. Tisti, ki delajo z obcutljivimi podatki sem preprican, da imajo mail kvoto temu primerno dvignjeno, da se ne posluzujejo ostalih "solatarskih" resitev.

V smislu da ne odpira novih kanalov za moznost
Zlorabe. Mail z attachmentom in pgp enkripcija

Vidim, da moram problematiko malo globlje pojasniti.

Outlook ima default omejitev za velikost maila 20MB. Načeloma to velikost lahko 'navijemo v registry-ju in jo tudi čisto odpravimo, vendar bomo zelo hitro naleteli na problem, če ima naslovnikov mail server omejitev za neko max. velikost maila (večinoma se to postavlja), potem pa lahko naletimo še na omejitev samega mailboxa naslovnikovega mail accounta, ki nam prepreči dostavo maila, velikega nad 20MB. Če pa želimo poslati datoteko, ki ima npr. velikost 1GB, pa dejansko mail s svojimi omejitvami odpade - vsaj v klasičnem smislu.

Zadevo se v komercialnih okoljih rešuje z rešitvami, ki spadajo pod pojem 'Managed File Transfer' (MFT).

Pogledal sem tisti Thunderbird 'BigFile', kaj naj bi bil. Dejansko je to 'client' del nekakšne MFT rešitve - strežniški del nam nudi katera od številnih storitev za posredovanje velikih datotek (yousendit, sendthisfile, ipd.).

Zadeva s seboj prinaša dva problema: večina ljudi uporablja Outlook in ne Thunderbird, tako da je treba najti klient/plugin za Outlook in druge mail programe. Možno, da kateri od spletnih servisov celo ponuja tak plugin za svojo storitev, vendar za malo denarja dobimo tu ponavadi le zelo omejeno storitev.

Druga slabost shranjevanja velikih datotek na spletu je podvajanje prenosov. Če imamo 1GB datoteko, jo moramo najprej naložiti na strežnik nekje na spletu, nato jo mora pa še naslovnik prenesti k sebi. Večja kot je datoteka, dlje vsa procedura traja.

Rešitev bi bila torej v tem, da takšen strežnik postavimo na svojem omrežju, tako da se datoteka prenaša samo 1x preko interneta.

Žal pa iskanje z googlom za pojmom 'open source managed file transfer' obrodi le cel niz linkov na 'iščem pa ne najdem' zadetke.

Nekoliko sem razmišljal, če bi se dalo zadevo alternativno rešiti z nekim 'zasebnim' mail serverjem, ki bi maile skladiščil izključno lokalno in jih nebi pošiljal preko interneta.
Ker je strežnik naš in se nam ni potrebno ozirati na omejitve na tujih mail sistemih, lahko na tem strežniku umaknemo vse quote in ostale limite. Ker je strežnik na lokalnem omrežju, lahko nanj razmeroma hitro naložimo tudi največje datoteke.
Za varen prenos bi moral ta strežnik podpirati pop3s ali podoben varen protokol (VPN bi verjetno prinesel že prevelik overhead).

Kljub temu pri taki varianti ostaja niz nerešenih problemov, ki jih komercialne MFT rešitve elegantno pokrivajo.

V OpenSource obstaja kar lepo število fragmentov, ki bi optimalno združeni lahko tvorili dokaj spodobno MFT rešitev. Žal pa doslej še nisem zasledil projekta, ki bi si to zadal za cilj.

Če pa govorimo o datotekah velikih 20, 100MB ali pa več 100MB, potem mail odpade kot 'transportno sredstvo'. V tem primeru se ne moremo izogniti odlaganja datotek na nek vmesni strežnik.

Jaz se že nekaj časa pripravljam da bi namestil rešitev, ki ves ta proces avtomatizira - preko maila. V tem primeru 'referentka' v Outlooku enostavno kot priponko doda sporočilo, ki je lahko poljubne velikosti (lahko tudi 100MB in več, če je treba). Plugin v Outlooku potem to priponko sam preusmeri na strežnik, kjer jo varno odloži (samodejno kreira account za naslovnika), naslovniku pa pošlje v mailu poseben link, s pomočjo katerega ta uporabnik aktivira svoj account na našemu strežniki in varno (FTPS) prenese datoteko k sebi. Pri tem naš strežnik vodi vso zgodovino o dostopu do te datoteke.

Zadeva ima le eno hudo lepotno napako - ceno, ki se giblje mimogrede tam okoli 20k€.

Žal za enkrat še nisem zasledil česa podobnega v OpenSource izvedbi. Če je komu kaj po funkcionalnosti podobnega poznano, bo informacija zagotovo zanimiva še za koga.

Če uporabljaš recimo storitev Ubuntu One lahko v Thunderbird 15+ preprosto vpišeš podatek za svoj Ubunto One uporabniški račun in nastaviš velikost priponke, torej mejo po kateri se naj priponka naloži na Ubuntu One in se v sporočilo samodejno doda povezava in to je to.



Vir slike

Če bi rad lasten strežnik v tem trenutku ne vem, če že obstaja kakšna gotova rešitev, ker je zadeva novost, recimo ownCloud bi znal dodati podporo v prihodnje ali podpora recimo za (S)FTP, oziroma lahko se torej kot praviš zadeve lotiš tudi sam in jo prilagodiš svojim potrebam Filelink Providers.

Umakni greylisting in povej kako bo šlo.. No jaz vem kako gre brez greylistinga. Amavis + antivirus sta zelo zelo ozko grlo in brez greylistinga sta v delovnem času sposobna ubiti 4-5 leta staro dualcore dedicated mašino.