Debian dnes slaví 32 let. Ian Murdock oznámil vydání "Debian Linux Release" 16. srpna 1993.
Policisté zadrželi odsouzeného drogového dealera Tomáše Jiřikovského, který daroval ministerstvu spravedlnosti za tehdejšího ministra Pavla Blažka (ODS) bitcoiny v miliardové hodnotě, a zajistili i darovanou kryproměnu. Zadržení Jiřikovského může být podle ministerstva důležité k rozuzlení kauzy, která vypukla koncem května a vedla ke konci Blažka. Zajištění daru podle úřadu potvrzuje závěry dříve publikovaných právních
… více »Administrativa amerického prezidenta Donalda Trumpa jedná o možném převzetí podílu ve výrobci čipů Intel. Agentuře Bloomberg to řekly zdroje obeznámené se situací. Akcie Intelu v reakci na tuto zprávu výrazně posílily. Trump minulý týden označil Tana za konfliktní osobu, a to kvůli jeho vazbám na čínské společnosti, čímž vyvolal nejistotu ohledně dlouholetého úsilí Intelu o obrat v hospodaření. Po pondělní schůzce však prezident o šéfovi Intelu hovořil příznivě.
Společnost Purism stojící za linuxovými telefony a počítači Librem má nově v nabídce postkvantový šifrátor Librem PQC Encryptor.
VirtualBox, tj. multiplatformní virtualizační software, byl vydán v nové verzi 7.2. Přehled novinek v Changelogu. Vypíchnou lze vylepšené GUI.
Eric Migicovsky, zakladatel společnosti Pebble, v lednu oznámil, že má v plánu spustit výrobu nových hodinek Pebble s již open source PebbleOS. V březnu spustil předprodej hodinek Pebble Time 2 (tenkrát ještě pod názvem Core Time 2) za 225 dolarů s dodáním v prosinci. Včera představil jejich konečný vzhled (YouTube).
Byla oznámena nativní podpora protokolu ACME (Automated Certificate Management Environment) ve webovém serveru a reverzní proxy NGINX. Modul nginx-acme je zatím v preview verzi.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.08. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Společnost Perplexity AI působící v oblasti umělé inteligence (AI) podala nevyžádanou nabídku na převzetí webového prohlížeče Chrome internetové firmy Google za 34,5 miliardy dolarů (zhruba 723 miliard Kč). Informovala o tom včera agentura Reuters. Upozornila, že výše nabídky výrazně převyšuje hodnotu firmy Perplexity. Společnost Google se podle ní k nabídce zatím nevyjádřila.
Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250812 mikrokódů pro své procesory řešící 6 bezpečnostních chyb.
To je klasicka mazurka odmitat/neodmitat. Ja jsem pro to, abychom se vybourili pri hodnoceni :) Tam to tem pitomcum rozesilajicim primo ze sveho notebooku schovanym za IP bez rDNS spocitam. Prave proto bych je rad poucil, ze tady uz davno existuji zpusoby posilani mailu, ktere jim zaruci doruceni do inboxu misto do spam folderu.
Jaký je tedy způsob, který mi zaručí doručení do inboxu místo do spam folderu? S takovou zárukou jsem se zatím nesetkal.
pitomcum rozesilajicim primo ze sveho notebooku schovanym za IP bez rDNS
Bohužel spam rozesílají botnety. Takto pouze získáte reprezentativní vzorek všech pracovních stanic s pravděpodobnostím rozdělením má/nemá reverz.
davno existuji zpusoby posilani mailu, ktere jim zaruci doruceni do inboxu misto do spam folderu
Tyto způsoby fungují jen u těch správců, kteří si takto nastaví server. A to jen dokud si všichni nezavedou reverz.
Předpovídám, že jak poroste přísnost správců serverů, poroste i tlak postižených uživatelů na jejich ISP, aby zavedli reverz. Tudíž tato heuristika se sama zadusí.
Pokud mi chcete tvrdit, ze vyhodnocujete mail jen na zaklade obsahu, tak vam neverim :)
Jinak jsem znacne optimistictejsi v tom, ze s tim, jak provideri budou omezovat prime odesilani mailu ze stanic na port 25 a nutit lidi odesilat maily pres mail server providera, lidi zacnou postupne stale vice posilat (a to treba vasi i mou zasluhou) maily pres port 587, kde se neda nic poslat bez autorizace. Takze tato heuristika se sama nezadusi.
Jenom drobný detail: SMTPS na TCP/587 je zavrženo ve prospěch TLS uvnitř SMTP. Třeba Exim jej ani nepodporuje.
Ne, ne, SMTP uvnitr SSL (SMTPS) je TCP port 465, TCP port 587 je SUBMISSION - TLS uvnitr SMTP je mozne.
a jestli to exim nepodporuje, meli by se nad tim hosi zamyslet - viz RFC 4409 http://tools.ietf.org/html/rfc4409
Prave proto bych je rad poucil, ze tady uz davno existuji zpusoby posilani mailu, ktere jim zaruci doruceni do inboxu misto do spam folderu.Ty způsoby neexistují, protože stejně jako někdo používá k označování spamu test na existenci rDNS záznamu, který o spamu či hamu nevypovídá vůbec nic, někdo jiný používá zase jiné podobně nesmyslné testy (třeba zda rDNS záznam neobsahuje číslo). Takže nakonec se stejně najde někdo, jehož nějaké prapodivné pravidlo pro rozlišování „spamu a hamu“ porušíte.
do inboxu misto do spam folderu.
Už samotná existence spam folderu je problém -- když ho zavedeš, tak se tam stejně člověk musí chodit koukat, jestli tam nespadnul nějaký důležitý mail. Nebo žije s rizikem, že se některé maily prostě zahazují a padají do žumpy , více méně náhodně. To není zrovna příjemný pocit -- ani pro příjemce, ani pro odesílatele. IMHO je lepší dělat co nejvíc kontrol v době příjmu pomocí SMTP, kdy se dá mail ještě vrátit tomu, kdo jej skutečně posílá (ať už je to spamer nebo normální odesílatel), ale když už ten mail přijmeme, tak ho doručit.
Což je případ onoho „vracení“ – to znamená, že se e-mail nedoručí a je to (možná) oznámeno odesílateli. Jenže co ten s tím může udělat
Mně by teda přišlo přívětivější, kdyby se mi e-mail vrátil a já mohl dotyčnému třeba hned zatelefonovat, než aby ten e-mail skončil ve složce se spamem a dotyčný se do ní možná po týdnu podíval, nebo ji po měsíci vymazal, protože už tam má tisíc mailů a nechce se mu to třídit.
P.S. AFAIK by o tom nedoručení měl být odesílatel informován určitě, ne jen možná (pokud zrovna nespadne poštovní server v ten nejméně vhodný okamžik).
P.S. AFAIK by o tom nedoručení měl být odesílatel informován určitě, ne jen možná (pokud zrovna nespadne poštovní server v ten nejméně vhodný okamžik).Odesílatel by měl být dle RFC určitě informován, ale v praxi je informován jedině v případě, kdy zprávu odmítne server hned v úvodní komunikaci. Pokud totiž informace o chybě znamená vygenerovat a poslat zpět e-mail, rozumně nakonfigurované servery to dnes neudělají (i když tím porušují RFC) – v drtivé většině případů to totiž znamená poslat spam (protože odesílatel je falešný). Odesílat chyby zpět e-mailem půjde až bude rozšířené ověřování odesílatele (SPF nebo lépe DKIM) – pak půjde chybovou zprávu odeslat v těch případech, kdy si server během přijímání e-mailu ověřil, že odesílatel je pravý.
Dale mnoho serveru spravuji lide neznali/mimo obor, kteri na upozorneni nereaguji, protoze moc nevi, co s tim, a "ono to nejak funguje" apod. proste nerozumi ani technicke ani organizacni strance veci. Verim, ze existence takoveho seznamu s prislusnymi vysvetlenimi, jak co napravit by jim vyrazne pomohla a ulehcila by jim pripadnou "akci". Taky by to umoznovalo aspon trochu tlacit i na vyslovene lemply. Prece jen pritomnost firemniho mail serveru na seznamu pochybnych serveru nevyvolava v managementu libe pocity.Takovým správcům můžete stejně dobře rovnou napsat. Pokud nepomůže to, nepomůže ani přítomnost na nějakém seznamu.
Ano, tady, já se hlásím! U mého (rodinného) mail serveru mi poskytovatel odmítl nastavit rDNS, bohužel.
Když už jsem tu tak roztomile OT, tak dnes mi přišel spam, jestli si nechci dát rozeslat spam:
Subject: Promote your business _7365 Date: Thu, 14 May 2009 05:46:03 -0500 For x@atlas.cz: 1. Provide e-mail lists as your require. 2. Customize this e-mail list for you and send your letter to the lists. * We also provide broadcast server to send e-mails. Please contact us with any questions. Contact e-mail: Contact@whjy.net
Holt, krize uděřila i na spammery :)
Presne tak, "bohuzel". Je to pro vas minus pri automatickem hodnoceni obsahu mailu. Proc se chcete tvarit, ze to neni minus? Ja prece nemluvim o seznamu osob urcenych k poprave. Urcite byste taky radeji providera, ktery vam to umozni.
Proc se chcete tvarit, ze to neni minus?
Co přesně znamená tato otázka? Na kterou část mého příspěvku reaguje?
Samozřejmě bych byl rád, kdyby mi můj provider buď nastavil rDNS, nebo oddelegoval classless subnet velikosti 1 pro IPv4 a pořádný subnet pro IPv6. Jenže takového providera nemám.
Pokud nemate rDNS nebo rDNS a DNS nesouhlasi, projevi se to v hlavickach emailu a tudiz Bayesovsky filtr pri hodnoceni vaseho emailu vas posune smerem k podobnym emailum. Dle mych zkusenosti jde spise o spam nez o ham. I kdyz p.Jirsak, zda se, ma svuj filtr nauceny na opacne vyhodnocovani :)
Je to pro vas minus pri automatickem hodnoceni obsahu mailu.Já bych tu větu trochu upravil: Je to pro vas minus pri hloupém automatickem hodnoceni obsahu mailu.
Nehodnotte cizi hodnoceni. Je to zpupne a nesmyslne.
Prekvapujete mne. Po tom, jak ja tridim sve emaily, je vam kulovy. Mne naopak prijde mimoradne hloupe zanedbavat kriterium s takovou vahou, ze nekteri ho pouzivaji k odmitani emailu.
Resite nesmyslny seznam "blbe zkonfigurovanych serveru", ktery by sel jiste lepe zneuzit nez pouzit.
Kdyz nekdo poukazuje na to, ze se snazite pouzivat nesmyslna kriteria, tak ho jeste napadate a na rozumne argumenty neslysite.
Ostudu si tu zrejme udelate Vy a nikdo jiny...
v hlavickach mailu je zaznamenano, zda odesilatel ma rDNS v poradku ci neA kde se tam tahle informace vezme? Tak ji tam nevkládejte a Bayes se k ní nedostane. A i když tam zůstane, Bayes zjistí, že je tahle informace k ničemu a dá jí váhu nula celá nula nic. V tom případě ale vůbec nechápu, k čemu potřebujete nějaký seznam špatně nakonfigurovaných serverů -- prostě si přidáte při příjmu do e-mailu hlavičku, ve které bude Ip adresa protějšku převedená přes DNS zpět na název, případně tam přidáte ještě další hlavičku, která tenhle název převede zpět na IP adresu. A tenhle e-mail předhodíte Bayes filtru. K čemu tam potřebujete nějaký seznam serverů?
Takze nevite, jak funguje Bayes.Normálně funguje tak, že se učením na spamu a hamu naučí rozeznávat spam od hamu. Jak funguje u vás, to nevím, ale z vašich komentářů se zdá, že vám moc nefunguje.
Vetsina lidi udrzuje stroje v poradku.Já za "vpořádku" považuju to, že mám veškerý ham ve složce s doručenou poštou a drtivou většinu veškerého spamu doručeného na mou adresu ve složce spam. A takto to také mám. Tj. neexistuje nic, co by bylo automaticky označeno za spam a smazáno, aniž bych to mohl později dohledat.
Já se taky hlásím, já zas nechci u svého malého serveru platit providerovi za rDNS nekřesťanský poplatky, takže nemám.. Nechce přez nás někdo posílat spam, ať taky splním normu? Řešíte tu blbosti.
Neexistuje nekde u nas seznam nasich blbe zkonfigurovanych spamfilteru mailserveru - neco jako tabule hanby :) ? Filtrovani podle nesouhlasici rDNS a DNS jmena apod.
toto je kvalitni prispevek!
Tiskni
Sdílej: