Byla vydána květnová aktualizace aneb nová verze 1.79 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.79 vyšlo také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Jak to bude s podporou rastrového grafického formátu JPEG XL ve webových prohlížečích? Google ji nedávno z Chrome a Chromia odstranil (#1178058#c84). Jednou z novinek beta verze Safari 17 je ale právě podpora JPEG XL. Vráti se JPEG XL do Chrome a Chromia (#1451807)? Dění kolem JPEG XL lze sledovat například na r/jpegxl.
Byla vydána nová stabilní verze 6.1 (aktuálně 6.1.3035.51) webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 114. Přehled novinek i s náhledy v příspěvku na blogu. Nový Vivaldi se pro Bing tváří jako Microsoft Edge (upravený User-Agent) a díky tomu v něm funguje Bing Chat. Vylepšeny byly Pracovní prostory (Workspaces). Podrobný přehled v Changelogu.
Linuxová distribuce ArchLabs Linux po šesti letech vývoje končí. Dobbie to zabalil.
David Tschumperlé v obšírném článku se spoustou náhledů shrnuje vývoj multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie) za poslední rok a půl.
Vývojáři postmarketOS vydali verzi 23.06 tohoto před šesti lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, Plasma a Sxmo. Aktuálně podporovaných zařízení je 30.
Byla vydána distribuce openSUSE Leap verze 15.5 (poznámky k vydání). Jde o konzervativní distribuci odpovídající komerčnímu SUSE Linux Enterprise 15, nyní Service Pack 5. Mělo jít o poslední aktualizaci Leap v současné podobě před přechodem na Adaptable Linux Platform s „neměnným“ základem, ale padlo rozhodnutí, že v roce 2024 ještě vyjde Leap 15.6 s podporou do konce roku 2025.
Alyssa Rosenzweig v příspěvku na blogu oznámila, že Asahi Linux už zvládá OpenGL 3.1. Dokončuje se podpora OpenGL ES 3.1. Dalším krokem bude Vulkan 1.0.
Intel nedávno představil a pod licencí SIL Open Font License (OFL) na GitHubu zveřejnil font Intel One Mono. Font je určen především pro zobrazování textu v emulátorech terminálu a vývojových prostředích (Přehled fontů s pevnou šířkou).
Na redditu byly publikovány zajímavé QR kódy vygenerované pomocí Stable Diffusion. Přehled použitého softwaru v článku na Ars Technica.
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: