IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
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: