Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.
V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.
Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.
Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
I have not contacted the authorities, though maybe I should have done that.Uvazujes o bonzovani?
a pak jsou schopny identifikovat kupceA k čemu jim to je? Resp. jak mohou dokázat, že si autor nezměnil text sám? Buď má kniha DRM a pak je to jedno, nebo je to prostě jen text a ten si může modifikovat kdo chce jak chce.
btw jak to pak resis v MUA, kdyz (regulerne) odpovidas na email a chces mit v "MAIL FROM" ten alias, na ktery mail prisel?V Thunderbirdu to jde dopsat ručně, ale mám pocit, že jsem to snad ještě ani jednou nepotřeboval. E-shopy jsou v pohodě s tím, když se zachová předmět (číslo objednávky) příp. message ID a From může být klidně jiná.
btw jak to pak resis v MUA, kdyz (regulerne) odpovidas na email a chces mit v "MAIL FROM" ten alias, na ktery mail prisel?V NeoMutte to rieším takto:
set reverse_name = yes set use_envelope_from = yes alternates ^regex_mojich_adries$
k hledání úniků asi jako dobrý ale si myslim že uplně nejvíc spamu stejně de přímo z těch samotnejch různejch služeb kde byl mail použitej při registraci :O :/
nóó a když ty adresy boti jakoby parsujou co tam třeba jako zkusit strčit uplně nazačátek slovíčko 'noreply' třeba by takovej mail zahazovali :O :O :D ;D byl by problém s registračníma formulářema nebo to neřešej?? :O :O
Náhodné/unikátní adresy používám už dlouho, mám je třeba i na blogu nebo na stránkách svých projektů. Jinak to používám hlavně pro obchody a různé služby. Pár postřehů:
abc.iug30cs5@def.example.com
nikoli jen abc.iug30cs5@example.com
a asi tak jednou se mi stalo, že to neprošlo přes validaci v nějakém formuláři a jednou mi obchodník volal, že adresa je neplatná – tak jsem mu řekl, že nemůže být neplatná, kdy mi na ni od něj přišlo potvrzení objednávky. Nakonec mi tam fakturu poslal ručně a to taky prošlo.info
, sales
, atd.Nápad na zlepšení, který jsem zatím neimplementoval: Občas by se hodilo mít možnost generovat si alias offline, aniž bych ho musel zakládat na poštovním serveru. Na to by stačilo sdílené tajemství a hash/hmac – měl bych offline aplikaci, které bych zadal vstup (název/doménu příjemce) a vrátila by mi platnou e-mailovou adresu. např. "franta.abclinuxu.cz." + hash("abclinuxu.cz", "tajemství") + "@example.com"
. Na poštovním serveru by bylo stejné tajemství a stejný algoritmus (jde to napsat v SQL), takže by server věděl, na jakých adresách má přijímat poštu. K tomu by byla samozřejmě černá listina adres, které sice algoritmu+tajemství odpovídají, ale přijímat na nich už nic nechceme.
Další věc je, jak tu hromadu aliasů dostat do e-mailového klienta, aby na ty zprávy člověk mohl odpovídat (u obchodů to obvykle není potřeba, ale jinak se to hodí). Tady by šlo udělat rozšíření do Dovecotu, ze kterého by si pak klient mohl přes zvláštní IMAP příkaz vytáhnout ty aliasy. U dnešních klientů je dost otravné a hloupé, že při odpovídání automaticky vyplní výchozí adresu (pokud daná adresa není nakonfigurovaná jako identita pro odesílání) a neupozorní uživatele na to, že odpovídá z jiné adresy, než na jakou zpráva přišla. Takže může dojít k nežádoucímu úniku soukromé/výchozí adresy k někomu, kdo měl znát jen tu unikátní, kterou měl přidělenou. Tohle by šlo řešit doplňkem do e-mailového klienta (provizorně je dobré si jako výchozí odesílací nastavit nefunkční adresu a účet, ze kterého nejde nic poslat).
Občas by se hodilo mít možnost generovat si alias offline, aniž bych ho musel zakládat na poštovním serveru.Tomu se rika domenovy kos - mam takhle definovany email spamy@ a vsechny maily ktere prijdou na nezkonfigurovany alias skonci "v kosi". Diky tomu do formularu na internetu muzu napsat pred zavinacem cokoliv a vim ze to ve spamy@ najdu (a muzu odtud i poslat odpoved prostym prepsanim From: hlavicky (coz umi treba mutt)).
Doménový koš je něco jiného. Já chci spam1 okamžitě odmítnout ještě v rámci SMTP relace2 a ne se jím pak prohrabávat v nějakém koši.
[1] což zahrnuje i zprávy přicházející na neexistující adresy – podstata doménového koše
[2] aby odesílatel věděl, že jeho zpráva nebyla přijata – mimochodem, tohle by měl být standardní přístup – nesnáším současnou praxi, kdy někteří poskytovatelé hází náhodné e-maily do spamu nebo je rovnou mažou a odesílatel se o tom nijak nedozví – tohle ničí e-mailovou technologii jako takovou a dělá ji to nepoužitelnou
aby odesílatel věděl, že jeho zpráva nebyla přijataTo je celkem problematické. Může se stát to, že se informace o odesílateli ztratí nebo pochází z nedůvěryhodného zdroje (odesílatel, mezilehlý SMTP server, …), takže potom může být i tato odpověď nevyžádanou poštou. I jedna zpráva na schránku informovaného by mohla informujícímu způsobit škodu – například okamžité mazání budoucích zpráv od informujícího – protože informovaní mohou mít jednoho provozovatele, který by to mohl považovat za spam. Příklad: Odesílatel posílá zprávu na SMTP server A, ten ji pošle na server B a ten doručí zprávu Vám. Pokud si server A a B nemohou důvěřovat, hlavičky identifikující odesílatele (např.
From
) se potom na serveru B nemohou použít pro adresování zprávy skutečnému odesílateli. Signalizace po SMTP také často není realizovatelná – spojení může být uzavřeno ještě před doručením.
Trochu jsem se na tohle téma rozepsal ve vedlejší diskusi: Reputační systém a vratné zálohy + anti-spam
Teraz som z toho už úplne mimo, veď VoIP by malo mať v sebe priamu funkcionalitu SMS.Má. SIP umožnuje posielať plain text správu cez MESSAGE príkaz. A ktomu špeciálne kvôli VoLTE bol vymyslený spôsob ako poslať RPDU obsah SMS správy ako binárku cez SIP MESSAGE. Oboje sa dá teda chápať ako "priama funkcionalita vo VOIP". Ibaže nič z toho nie je poskytované pre geografické/nomadické čísla na VOIP linkách v ČR. Čo sa týka funkcionalít geografických a nomadických čísel na VOIP/SIP linkách v ČR, tak tam je proste iba preklopená analógová časť na nasamplovaný zvuk v RTP zabalený do UDP paketov. A keď služby na analógovej linke behali in-band cez modem (ako FAX alebo SMS), tak patričný zvuk je rovnako prenášaný ako zvuk na VOIP/SIP linkách. Je tu ale jeden menší pokrok v oblasti FAXu cez VOIP. Na prenos FAX po VOIP existuje protokol T.38. Definuje ako zabaliť binárny FAX do UDP a teda už nepoužívať modem v hlasovej časti cez RTP. VOIP brány po ceste ho zvyknú podporovať.
Ak to teda poskytovatelia neblokujú kvôli spamerom, ale to by blokovali odosielanieJa som zatiaľ písal iba o prijímaní obsahu. Posielanie je naozaj zablokované a neposkytované z geografických a nomadických čísel asi u všetkých operátorov (analógových aj VOIP) až na výnimku, monopol O2-CZ. Tzn. funguje to iba pre analógové pevné linky, kde si užívateľ platí "vysoký tarif". Proste ak chce niekto poslať SMSku na ľubovoľné české geografické/nomadické číslo (či už zo sim karty nejakého mobilného operátora alebo cez nejakú webovú/komerčnú službu), tak SMSku normálne pošle a jeho operátor ju doručí operátorovi O2-CZ, ktorý sa ďalej postará o doručenie na konkrétne geografické/nomadické číslo jedným z tých haluzných spôsobov. A to bez ohľadu na to akého operátora má príjemca.
Tiskni
Sdílej: