Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Ahoj, vyznáte se v tom?
Maily jsou odeslané z gmail.com a jdou na preposilaci@server.cz kde jsou přeposlány na cilovy.server.cz. Na cílovém serveru je antispamové řešení (Cisco IronPort), které je, na základě SPF, dost tvrdě vyřadí (by-default).
Z uvedených hlaviček tomu rozumím tak, ze si ověří přeposílací server, což dopadne dobře, ale pak ověřuje stejný způsobem původní zdroj (gmail.com) a to už tak moc nebere...
Pokud je to odjinud, tak to vypadá stejně, jen místo SoftFail je tam Pass nebo (asi) častěji Neutral (třeba pokud je zdroj seznam.cz). Může být někde nějaká chyba, špatného nastavení (krom nastavení spam filtru). Vypadá to, že ve stejné kombinaci (gmail.com + ten preposilaci server) se to děje vždy, ale vyměníme-li gmail nebo vyměníme-li preposilaci@server.cz a tak, je to v pohodě (možná se to děje i při více kombinacích, ale v tom počtu se to těžko zjišťuje).
Info: IP XX.XX.XX.XX je všude stejná a je to adresa preposilaci@server.cz.
cilovy.server.cz a preposilaci@server.cz jsou úplně jiné servery (nenechte se zmást doménou server.cz).
Received-SPF: SoftFail (cilovy.server.cz: domain of uzivatel@gmail.com is inclined to not designate XX.XX.XX.XX as permitted sender) identity=yyyyy; client-ip=XX.XX.XX.XX; receiver=cilovy.server.cz; envelope-from="uzivatel@gmail.com"; x-sender="uzivatel@gmail.com"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (cilovy.server.cz: no sender authenticity information available from domain of preposilaci@server.cz) identity=xxxx; client-ip=XX.XX.XX.XX; receiver=cilovy.server.cz; envelope-from="uzivatel@gmail.com"; x-sender="preposilaci@server.cz"; x-conformance=spf_only
Řešení dotazu:
Brani tvemu preposilacimu serveru, aby se tvaril jako zdroj emailu z @gmail.com.
On se nijak netváří o jen přeposílá poštu, tak jak má (aspoň si to myslím, až si to nebudu myslet budu kontaktovat jeho adminy...).
Podle tvého vyjádření by to znamenalo, že žádný přeposlaný e-mail nemůže být doručen a některé kombinace evidentně jsou (většina) a některé ne (potvrzenu mám jednu), a nevidím žádný rozdíl v hlavičkách emailů/kombinací.
Vis, o cem je vubec SPF?Matně tuším ;) - je mi jasné jak to prakticky funguje u přímo doručeného e-mailu, ale už ne jak to prakticky může fungovat/funguje u přeposlaného.
Sorry nějak jsem výše přehlídl -t txt.
Pravděpodobně mám problém s porozuměním psaného textu (a jedno v jakém jazyce) - čím víc toho čtu, tím méně to chápu.
SPF při přímém posílání chápu (tam není co řešit), ale při přeposílání jsem to stále nepochopil, ale vyšli mi divné závěry:
že je lepší nemít na své doméně nastaven spf záznam, abych nekompikoval přeposílání,
že SoftFail není takový průser, a antispam řešení by to mohlo pustit,
že s tím stejně nic neudělám krom toho, že donutím cílové adminy aby zmírnili restrikci.
No protože jsem to pochopil tak, že pokud záznam nemáš a někdo to přepošle tak bude email označen jako none, ale pokud jej máš a někdo to přepošle, tak bude označen jako SoftFail. A automatické přeposílání emailů je velmi používaná věc.
Ano nastavil jsem si záznam (počkal na probublání) a je to „hezké“, přímo poslaný email je Pass (jak psal alkoholik a jak je to i ve specifikaci).
No jo, ale když ani jeden server není tvůj, nebo jen jeden…Co dělat v případě když jde email z gmail-u na schránku provozovanou jako součást web hostingu (tedy kontrolu na DNS jo, nad serverem jako takovým ne) a je to přeposlané na firemní schránku, kde je to zahozeno? (Ano, můžu zařídit vypnutí filtru, ale nebudu sahat adminům do kompetencí, i když asi budu muset, protože mi začíná být jasné, proč se už několik důležitých e-mailů ztratilo, bo lidi ve světě na různých mobilních zařízeních, jsou tímto někdy odstřeleni…)
Konkrétní situaci bych mohl a chtěl vyřešit tím, že bych chtěl po provozovateli schránek (hostingu) aby něco udělal, ale furt nevím co by měl udělat, stále jsem v tunelu a nevidím to světlo na konci...
Dík, to z odkazu jsem četl už včera.
Tak znovu, asi to blbě vysvětluji.
Už nevím jak... :(
A proč si firma nechává posílat maily na seznam a pak si je přeposílá zase jinam do firmy AB.Firma si NIC nenechá posílat na seznam, ale někdo třeba 'zákazník' nebo 'zaměstnanec' nebo 'úřad', nebo jiné 'uskupení' pošle email a ten dojde někam (mimo kompetenci firmy AB) a tam někde je to přeposláno do firmy AB a třeba i do firmy BC atd.
Pokud jste ta firma AB tak nechápu proč máte mail na seznamu a přeposíláte si ho na AB.OT: Dalo by se říct, že jsem několik firem ;), ale to s tím vůbec nesouvisí.
A když už to tak děláte tak si server v firmě AB nastavte aby ty přeposílané správy přijímal.Protože tomu tak není, tak to nelze a nelze ani předjímat, z kterých serverů to bude potřeba, a z kterých ne, změny mohou být časté a logicky se na to dojde až pokud se jinak potvrdí, že e-maily nechodí (a přišli o zakázku, informace, peníze…), protože o tom IT samozřejmě neví, co se kde domluví. A taky to nelze třeba pro zaměstnance, aby si nahlásili z kterých přeposílačů si budou poštu přeposílat a byl by seznam asi hodně dlouhý.
Jinak samozřejmě chápu že je někdy třeba přeposílat maily mezi firemníma servery ovšem ty jsou pak pod moji kontrolou a můžu si nastavit co se přijme a co ne nezávisle na tom co odesílající strana má nastavené.Tam je to naprosto jasné a žádný problém nenastává to je „soukromý poštovní úřad“, ale ono je tak nějak třeba komunikovat s tím venku...
Prostě podle mě hledáte problém tam kde není - pokud váš server nechce přijímat maily tak mu povolte ten přeposílající server před vyhodnocením SPF. A pro odesílání ze své domény mu korektně nastavte SPF záznam.Já ho nehledám, on tam je, nechodí pošta, z části soukromá (a povolená), z části „polo-pracovní“ a hlavně z části „pracovní a důležitá“, protože prostě jde přes něaký forwarder a chodit tak bude, je na tom postavena i spousta business-u, to není něco co můž(u|eme) změnit.
Nezlobte se firma má mít firemní mail a na ten se mají maily posílat.Tak tady už cítím absolutní bezmoc. Vždy to firma AB má.
Samozřejmě pokud chcete přijímat všechny maily které přepošle kdokoliv tak těžko pak můžete používat SPF a pak musíte použít jiné filtry a jiné nástroje pro filtraci spamu.Přeposlání emailu je korektní operace a ano budu muset nechat dopad SPF na klasifikaci emailu zmírnit. Nicméně pokud si přeposílač zařídí SRS (, které furt ještě moc nechápu), tak stejně budeme příjmat maily od kohokoliv kdo je přepošle. SPF nemá řešit problém přeposílání, to jen zásadně komplikuje, ale má řešit podvržené posílání.
Vždy je to o tom že nějaký mail se může stratit - prostě to není bezpečná komunikace.No to je bez debat, svět není ideální, ale záleží na tom jaké je riziko.
A teď si musíte uvědomit zda budete aplikovat nějaké filtry a nebo budete přijímat vše a pak to bude nějaký člověk kontrolovat zda je to spam nebo neJenže pokud jsem to dobře viděl, tak na základě tohoto SPF filtru bylo vyřazeno několik desítek možná malé stovky e-mailů denně na několik set schránek a z čehož hodně vysoké procento bylo vyřazení ne-spamu, takže vůči několika desítkám tisíc e-mailů vyřazených jinými analýzami, je ten filtr kontra produktivní, zvláště když definuje tak vysokou prioritu pro zahození (tedy, že je ten email označen jako hodně-zlý, takže jej nevidí uživatel ani ve své složce spamů, které plní spamové řešení).
Protože i regulérní mail se může hodit do spamu a někdo ho může smazat a vy o tu zakázku přijdete.To je normální, ale opět záleží na tom riziku, SPF filtr zahazuje velmi vysoké procento regulérních emailů a odfiltrovává sám o sobě velmi malé procento spamu.
nebo preposilaci server korektne prepsal hlavicku, dostanes pass.
Kterou hlavičku má přepsat?
Předjímám: pokud 'From', tak to rozhodně není korektně, ale prasárna nejhrubšího zrna.
Ale bude to asi správná stopa, bo stejným způsobem přeposlaný e-mail odněkud na seznam.cz a doručený na cílový server má od seznamu doplněnou/opravenou hlavičku Return-Path: na postmaster@seznam.cz a tam je SPF filtr šťastný, bo tam má Pass.
Pokud se to udělá obráceně zůstává tam Return-Path: na user@seznam.cz a je tam Normal a je možné že na základně nějakých seznamů/listů je google zlejší než seznam tak dostane vice bodů.
Doplnění k terminologii:
preposilaci@server.cz je ten kde je emailová schránka, do které byl email určen a kde se na základě filtru provede přeposlání/přesměrování e-mailu na cilovy.server.cz.
Na tom není nic složitého, každý poskytovatel schránek ti umožňuje jednoduše nastavit filtr a přeposlání doručeného emailu kamkoliv, vždy je to normální distribuce informace, možná dokonce těch schránek, jako přestupních stanic na veřejných serverech jako seznam.cz apod. bude možná více, než těch přímo primárně používaných.
Dělá to tak každý třetí až pátý uživatel emailu (jen takový tip), to je celý důvod.
preposilaci@server.cz, má být preposilaci.server.cz, to je chyba při přepisování reálných adres.
Zamyslet nad čím? Jak nahradit funkcionalitu automatického přeposílání/distribuce emailů na různé adresy a domény, například podle odesílatele či předmětu? Jo to bych mohl, ale fakt nevím jak... :)
Taky jsem to tak pochopil a z toho mi plyne, že SPF pokud se striktně uplatní zabíjí e-mail komunikaci obecně a tomu se mi nechce věřit, navíc kdž je to tak, že pokud SPF záznam není na odesílací doméně uvedený je to vyšší garance průchodu emailu.
Já v zásadě nic kontrolovat nemůžu, můžu donutit administrátory v tomto konkrétním případě vypnout cílovou SPF kontrolu, sranda je že v whitelistu už jsou doplněny banky, gov a další instituce, protože pak nechodí spousta důležitých e-mailů, protože opravdu velká část komunikace je automaticky přeposílána.
Jak píšu tady je to o užívaní, ne o nastavení a z principu, jak to stále chápu já a odmítám se s tím smířit, by musel takový gmail mít spf záznam na celý internet - nebo raději žádný. Schází tam ta paralela s listovní poštou, kde pošta může být přeposílána (na žádost adresáta) a odesílatel může v určitých případech explicitně uvést, že toto není možné, nicméně to se mu pak ta pošta vrátí jako nedoručitelná.
Nastavil jsem si na jedné doméně v=spf1 include:muj.isp.cz ~all, '-' je sebevražda, a '~' je zmrzačení SPF a já mu chci ublížit, bo mě to točí 
- a uvidím jaké budou zkušenosti.
SRS stránky jsem procházel, ale úplně jsem nepochopil a stále nechápu 'CO' je potřeba přesně udělat na přeposílači, aby přeposlaná pošta byl v cíli akceptovaná. Z webu jsem to úplně nepobral, z některé, už nevím které implmentace jsem vyrozuměl že se mění Return-Path hlavička ale je toho víc. Čekal jsem, že mi někdo řekne „ty si vůl, stačí tam dopsat hlavičku, a/nebo udělat ono“, ale vypadá to, že se budu muset podívat do nějakého pajšlu detailně, abych se případně z konkrétním poskytovatelem mohl bavit nebo se aspoň ptát po implementaci něčeho.
NEBO se jen jednoduše hloupě zeptám, s použitím pouze termínů SPF a SRS.
Super, Jak? Proč?
Jak má dvě úrovně jak řešit naprosto běžné situace (třeba taková prkotina přeposílání důležitých e-mailů na email, na kterém jsi a jiný nemáš k dispozici, nebo seznam adresátu se neustále mění a toho co to posílá to nezajímá, to dělá/má na starosti někdo někde jinde), a jak všem vysvětlit, že tyto věci co byly a jsou běžně k dispozici, nemají používat.
Proč ... a zakažme i přístupy z vyhledávačů, vždyť každý má znát adresu serveru kam leze... 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
30.11.2013 12:46
?all, pokud to pude přímo, bude to Pass a poku to někdo přepošle bude to jako by ten záznam tam nebyl
)
Jasně je to částečně problém, tak to pošlu jako user dál a to potom projde.
Received: v čele dopisu. Myslím, že ochrana proti takové možnosti je jednou jednou z důležitých antispamových ochran.
Jasně, jenže to je právě nežádoucí, to je de-facto nová pošta, tedy i pole FROM už je někdo jiný a pokud by se to takto mělo dít automaticky, tak je to nepoužitelné. To už by pak filtrování (myšleno rozdělování, ne antispam) pošty v cíli bylo téměř nemožné, protože by šlo jen operovat se zpráva obsahuje (původního odesílatele) a když má někdo vélké desítky či stovky emailů denně, tak prostě potřebuje filtrovat na základě sender.
Ono to má jasná řešení, buď kašlat na SPF, nebo jen na základě SPF udělit jen velmi malý počet bodů na atni-spamu a postupně by měli poskytovatelé implementovat SRS (jestli je to tedy řeší).
A kdokoliv přidává TXT spf záznam by měl zvážit jestli -all je dobrý nápad (dnes fakt není :)), a kdokoliv poskytuje hosting apod. by měl mít minimálně ~all nebo spíš ?all, tak jak má třeba seznam a další, bohužel proč je toto celé vlákno je to, že gmail má ~all, kdyby měl ?all bylo by to OK. (Ale aspoň jsem si spoustu věcí přečetl )
Nechceš chápat nebo nechápeš?
V tomto případě banka pošle email na tvůj soukromý email u poskytovatele XY, a ty si u provozovatele XY nastavíš automatické přeposlání do firmy AB na svůj účet a ve firmě AB je mail zahozen. No a tam je ten problém.
Dodatek: A teď si představ, že to není soukromý email, ale třeba email společnosti FA vlastnící daný bankovní účet, která má tři zaměstnance a provozuje emaily na své doméně u poskytovatele XY a na základě dohody mezi FA a AB, mají být tyto výpis posílaní i do firmy AB (třeba jen na omezenou dobu). Tak firma FA si u provozovatele nastaví filtr a zajistí přeposílání věcí z banky a ejhle dozví se, že neplní svou část dohodu protože výpisy nechodí.
Neutral, v podstatě Frantu-Pepu neomezuji. Ale SPF záznam mám, takže pokud jde email přímo na Frantu je čistější než křišťál.
Maily jsou odeslané z gmail.com a jdou na preposilaci@server.cz kde jsou přeposlány na cilovy.server.cz. Na cílovém serveru je antispamové řešení (Cisco IronPort), které je, na základě SPF, dost tvrdě vyřadí (by-default).1/ user@gnail.com pošle zprávu na franta@firma.cz. Vaše SPF se zde neuplatňuje, zprávu přijmete 2/ franta@firma.cz přepošle na pepa@firma.cz Je to mezi Vašima servery (v rámci serveru), ty si snad věří. 3/ franta@firma.cz přepošle na frantík@seznam.cz Tam SPF máte nastavené, že je to z Vašeho serveru a seznam.cz nemá důvod nevěřit odeslané zprávě a frantíkovi ji doručí 4/ user@gmail.com pošle na frantík@seznam.cz (tam není Vaše SPF - to neovlivňujete). frantík@seznam.cz přepošle do firmy na franta@firma.cz. Proč by se zde uplatnilo Vaše SPF? Kde tedy vzniká problém? Prosím ještě jednou pro nechápavého...
Nikdo nic neprovádí, vtom je ta finta - ono se to děje ;)
Pomůže, tento popis.
Jinak je to bod 4/ ,jen s tím, že antispam na firma.cz ověřuje spf záznam u seznam.cz, a ptá se na gmail.com.Workaround je prostý a nutný „nesoulad SPF = nepatrná váha nedůvěrohodnosti na antispamu“ a je pokoj, protože jinak to vyřešit prostě nelze (bo asi většina přeposílačů to nijak neřeší a používá to tak spousta „uživatelů“).
Nic ve zlém, ale jak se zamyslíš, jak já (jestli je to tedy vykání ;)) s maily pracuji, tak se i zamysli, jak s nimi pracují ostatní, třeba ti dojde, že to dělá velká část uživatelů tzn. na svém hostingu, ve své emailové schránce si přeposílá poštu jinam, takže není v mé moci jakkoliv změnit chování uživatelů, stejně tak jakkoliv změnit chování „přeposlacích serverů“, může jen zařídit na koncovém uzlu, který je pod mým nějakým vlivem, aby ty maily byly propouštěny.
A když se zamyslím nad tím proč některé maily přeposílám já, tak prostě nevidím jinou možnost, jak zařídit doručení emailu tam kam chci, pokud nejsem schopen on-line ovlivňovat odesílatele aby odesílal tam kam zrovna potřebuji (což je ujetá blbost), tak prostě ty emaily přepošlu tam, kde je zrovna či trvale potřebuji.
A dokonce i když mám možnost odesílatele ovlivňovat, protože jsem to automatický-já v jiné identitě (třeba nějaký server mail), tak nechci to nastavit rovnou tam, kam to momentálně chci doručovat, protože to ubírá na flexibilitě, něco se změní a já budu na dvaceti místech přestavovat kam odesílat, ne, prostě to chodí na sběrné místo a tam se to distribuuje kam je třeba a na sběrném místech je všechno hezky pohromadě, jak má být. Automatické přeposílání emailů není chyba.
Já jsem o to dřív nijak nezajímal, stačilo mi vědět, že něco takového existuje a při pokládání dotazu jsem nějak předpokládal, že to má fungovat i pro přeposlanou poštu.
Ono je něco jiného při stovkách spamů a něco jiného při desítkách tisíc, takže pokud mám nějak ovlivňovat odpovědné, tak musíme najít rozumný kompromis a fčul asi už vím dost, abychom se domluvili.
No a navíc, jsem si někde spf záznam doplnil, nicméně fčul váhám, jak už jsem psal, jestli ~all nebo ?all, druhá volba je vlastně jak to bylo před tím (tedy bez záznamu), ale při přímém odeslání pošty je to Pass.
Ano, a právě proto si říkám, že ?all je optimální pro věřejný zlý svět, kde jsou lidi, firmy, korporace, úřady, banky, EU fondy tak nezodpověndí že si přeposílají poštu. Přímo odeslaný email je v pořádku ověřený a přeposlaný je „neutrální“ ani špatný ani dobrý. Pokud bych byl v kontrolovaném prostředí tak nastavím ~all nebo -all, protože tam přesně vím co se má dít a co se může a co ne.
Pokud příjemce toto udělá natvrdo, tak je to jeho věc, ale pokud je to velká firma, tak dostane admin brzo po čuni.
Ono forwardovat pořádně není možné pokud není server pod plnou kontrolou a pak to asi taky není žádná prdel, pořádně lze forwardovat jen mez předem známými servery.
SPF je informace pro příjímací server (nikoli příjemce) o tom jak odesílací server (nikoli odesílatel) hodnotí to, co se s poštou děje.
Po pravdě je mi naprosto putna co bude dělat seznam s příchozí poštou, to je věc toho kdo tam tu poštu má - to neovlivním. Ale není mi jedno, když mail jdoucí z google přes seznam nedojde do firmy protože google říká „SoftFail“ (obráceně dojde, protože seznam říká Neutral). Nikdo ve firmě není odpovědný za chování člověka, co ten email poslal a ten člověk neudělal nic zlého, jen si prostě nastavil automatické přeposílání, které je tu s námi 300let a vždy fungovalo a stále je normálně na většinou portálů nabízeno a je to součástí spousty automatického třídění pošty a postoupení informací.
Ale ovlivním to, jak se nastaví spam filtr ve firmě a ovlivním i své domény aby říkaly, že „nechválený“ forward považují za 'NEUTRAL'.
Nevím o tom, že by jakýkoliv „portál“ (provozovatel schránek) měnil 'From' při pře-poslání pošty na základě filtru a kdyby jo, tak je to na odstřel, a bylo by to nechtěná feature, jak pro odesílatele, tak pro příjemce. To by pak chtělo nové zařízení /dev/auto-chaos .
Můžeme vymyslet hlavičku „Automatick-forward:“ a poštu zapouzdřit a naučit s nimi klienty pracovat a nebo třeba zmíněné SRS implementovat do forwarderů.
Nadto pokud nekdo preposila mail a nechava ve from puvodniho odesilatele, je to dobytek a nic jinyho nez > /dev/null si nezaslouzi.To je ale blbost.
...ale nechápu proč by někdo měl přeposílat hromadu mailů automaticky přes seznam centrum a další servery.Sestup z výšin na pevnou zem. Takové věci se prostě dějí.
..s tímto nic neuděláš pokud ty přeposílací servery budou spf používat tak se to prostě bude strácet a můžeš se stavět třeba na hlavu.Máš v zásadě pravdu.
Ale automaticky všechno přeposílat na seznam ... je prostě blbostNení to zase až taková blbost. Představ si, že maily chodí na firemní server, do práce a tam si je zaměstnanci normálně čtou. Pak se stane, že mají hrozný fofr a že by si potřebovali doma přečíst odpověď na mail, který má přijít až v pátek pozdě odpoledne. Protože jsou poučení uživatelé, zajdou za administrátorem firemního Exchange, jestli by jim poštu nemohl přeposílat na seznam. Administrátor je dobrém rozmaru a nastavení provede. Zaměstnanec je nadmíru spokojený, jeho šéfové taky a přeposílání zůstane v provozu. A pak se stane, že některé maily nedojdou. A nedocházejí. Zaměstnanec se diví, administrátor Exchange tvrdí, že je všechno v pořádku, na firemním serveru pošta je a přeposílání je nastavené. Začnou otravovat tebe, který máš na starosti linuxový stroj, který všechnu firemní poštu přebírá a posílá dál. No a ty zjistíš, že prostě některá pošta je odmítnuta přijímající stranou. A teď co? Já bych například zahodil Exchange i s jeho licencemi a na centrální server bych dal linux a nějak bych si poradil i s tímhle. Ale nejde to. Tak mám server se Sendmailem uprostřed, rád bych nasadil SRS, ale nevím, kde vzít funkční řešení. Mám ještě jiné servery, kde může časem dojít k problémům, ale zatím to naštěstí funguje. Měl jsem zůstat u qmailu, tam to zřejmě jde, ale už mě tenkrát nebavilo ho pořád kompilovat a pak zjišťovat, že všichni používají Sendmail.
Zbav se toho vše, hromada apod. několikrát jsem muvedl slovo filtr, pokud je to vše a trvale je to otázka k myšlení, ale taky to chyba být nemusí. :)
Otázka jedna, možná bližší situace, jak si necháváš posílat důležité notifikace s různých „běžných“ serverů v různých destinacích a jak to uděláš, když je vás pak více a odpovědnosti se mění.
Otázka dvě: Automatický forwarding na jedné doméně nebo mezi předem stanovenými servery pod jednotnou kontrolou je v pořádku, ale mezi nezávislými subjekty už ne?
Otázka 3: Má se začít zpracovávat přeposílání ručně a lidé se domluvit se na nějakých obskurní pravidlech, aby bylo možné i email přeposlaný v přeposlané destinaci ve schránce nějak zatřídit dle sender a ne re-sendera?
Nemám dobrý den, takže „do prdele“ jaká firma přeposílá tuny (předpokládám, že je to zas víc něž jsi uvedl minule), a do „do prdele“ přes jaké pochybné centrum, kde furt na ty kraviny chodíš?
Tam také zústavají
Přístup na firemní emaily není vůbec předmětem a ze SPF či přeposíláním to nemá vůbec nic společného.
To je normální a běžné, ale to se děje v rámci firmy.
Ne, tady by to chtělo opustit úzký průzor a začít přemýšlet jinak a o tom co jsem už několikrát napsal, ne o nějaké vnitrofiremní politice práce s maily.
Ano to neovlivním, ale nebudu stresovat mnou odeslanými maily a vnucovat jim nějakou ideu, že si mou poštu si nesmí přeposílat.
Má smysl na to PS odpovídat? naposledy:
Nevím co je hromada, je jich tolik, kolik je třeba. Zaměstnanec má přístup JEN k firemnímu mailu, takže pokud je mu umožněno dostávat soukromou poštu, tak není jiná možnost než přeposlat, člověk oficálně pracuje pro více firem, každou chvíli někde jinde a buď má možnost používat jiné schránky nebo nebo ne, když ne tak opět nemá jinou možnost, když ano tak je to nepohodlné. Přes seznam a centrum to obvykle dělají zaměstnanci, malé firmy to dělají přes někde provozované schránky na vlastní doméně, ale z principu odesílatele neovlivní, protože by si tam musel za chvíli dát všechny a oni potřebují automaticky forwardovat poštu někam jinam. Velké firmy/korporace/fondy to dělají kvůli flexibilitě, protože spolupracuje velké množství subjektů a koordinuje to jeden subjekt a ten jen nastavuje pravidla a není v jeho moci ovlivňovat jak odesílatele, tak příjemce. A pak je tam skupina mobilních zařízené v obskurních destinacích, kteří si vydupou povolení odeslání emailu alespoň na konkrétní email, ale holt potřebují posílat i často někam jinam, tak si nastaví filtr podle předmětu a všichni jsou spokojení.
Prostě to, že ty si něco myslíš neznamená, že si to myslí ostatní a nebo že mají možnost postupovat podle tvé myšlenky ;)
But don't worry, there are SRS plugins for major opensource MTAs.Já jsem worry, protože to není pravda. Pro Sendmail není žádné řešení, jak použít na forwarderu SRS.
Jo-jo, já jsem to už pochopil. A udělal si z toho patřičné závěry, a bude moct na jejich základě, konkrétní případ, fakticky řešit.
Jen jsem se asi dostal v některých vláknech do role obhájce chování velké části (se mnou nesouvisejících) uživatelů pošty a přeposílání obecně. Pozitivní je, že jsem schopen teď zdůvěryhodnit odeslaný email (kdybych to potřeboval), ale při přeposílání mu zachovat původní status (myšleno doplnit na danou doménu spf záznam s patřičnými údaji a ukončený ?all).
Co je ale podstatnější, váš server tak aktivně šíří spam.To snad ne. A zprávy mailer-daemona končívají ve spamu? Ach jo, obávám se, že vám nerozumím.
Mail neexistujícímu zaměstnanci snad zamítnete rovnou v rámci spojení.Ano Já nějak nechápal, jestli máte na mysli odcházející poštu nebo příchozí. Příchozí pošta se SPF_FAIL dostane patřičný počet trestných bodů a pokud se k tomu načte dostatek dalších, tak to spadne do spamu a nic se nikam neposílá - to je asi to, co jste mysleli s tou amplifikací spamu. Koukám do logu a nevidím, že bychom zasekli nějakou poštu jen kvůli SPF_FAIL. Já jsem ale mluvil o opačném případu - mám striktní SPF a pokud to někdo přepošle na některé české velkoservery, tak ty se chovají jinak - zaříznou email vždy a chybovou hlášku pošlou odesilateli. Aspoň v několika případech které jsem řešil to tak bylo. Ale to je třeba se zeptat jejich adminů, jak to mají udělané. Přeposílání našem serveru řeším málokdy, neboť uživatelé mají zakázano posílat pracovní záležitosti na veřejné servery. No a pokud je to potřeba, pak buď přepsat procmailem header nebo upozornit, aby jako return address nepoužívali pracovní adresu.
No a o tom to celé je, už jsem to tady někde psal, nezajímal jsem se jak přesně spf funguje a nevěděl jsem, že je téměř nemožné přeposlat email tak aby spf prošlo. Proto ten dotaz. Holt na daném řešení už nesoulad spf + zdroj s gmail je, jak to tak vypadá, vždy likvidační, ale s těmito informacemi už lze pracovat a uvést to do lepšího stavu.
No a došel jsem na to tak, že holt si nechávám ze své domény přeposílat některou poštu, na „tento“ email, a nějak mi vrtalo v hlavě, proč jsem to vyřídil až z dvoudenním zpoždění, když jsem se o tom mohl dozvědět dřív, tak jsme si to prošli a rozsvítilo se i pro jiné případy, a mnohem důležitější.
No a zbytek debat je o tom, jak je přeposílání zlé, a že, má být firma odpovědná za část nesouvisejícího světa, která přeposílá, nebo že přece má tuto poštu zahodit, protože je zlá. No a proti stojí, že tu poštu chceme a nejsme odpovědní za to, jak se k nám dostane, a že přeposílání je dobrá praktika, ale není ji možné realizovat v souladu ze SPF, protože je to mimo kontrolu. A taky, že je to nejčistější možnost jak si může zaměstnanec nechat své důležité zprávy doručit ihned, protože může být třeba týden od možnosti jinak zprávy číst odříznutý (a samozřejmě nepoužívá firemní email pro soukromé účely primárně) a spoustu dalších důvodů, kde některé jsem už několikrát popsal.
Pokud nesedí SPF záznam, tak slušný server to přijme a pak teprve vyhodnotí spolu s dalšími kritérii, jestli poštu zahodí jako spam nebo ne.
Zahazovat ji rovnou, klidně může taky, ale na firemnímu serveru, či jiném, co chce komunikovat, bych to moc nedoporučoval, bo se ztratí spousta žádané pošty, říct si na jen tak, že k nám se žádná pošta nechváleně forwardovat nesmí je sice fajn, ale prostě se to děje, takže když to admin tak nastaví, tak asi brzo dostane jasný úkol k nápravě „aby chodila pošta“.
Odesílatel není odpovědný za chování adresáta, a cílový server za chování forwarderu.
Pokud nedostanu odpověď, tak nemůžu ověřit že pošta nedošla, takže to prostě nelze ověřit na odesílacím ani na forwardovacím serveru, tedy to nemůže být jeho úkolem.
1.12.2013 14:08
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
29.12.2013 12:44
MMMMMMMMM | skóre: 44
| blog: unstable
| Valašsko :-)
From SRS0+BT2X=WE=odesilatel.cz=martin@cilova-domena.cz Sun Dec 29 12:28:49 2013
Return-Path: <SRS0+BT2X=WE=odesilatel.cz=martin@cilova-domena.cz>
X-Original-To: prijemce@cilova-domena.cz
Delivered-To: prijemce@cilova-domena.cz
Received: by mail.cilova-domena.cz (Postfix, from userid 908)
id E352F5E010FE; Sun, 29 Dec 2013 12:28:48 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cilova-domena.cz
...
From: "martin@odesilatel.cz" <martin@odesilatel.cz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: prijemce@cilova-domena.cz
Subject: Test SRS
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
:)
hint: odesláno z martin@odesilatel.cz na prijemce@cilova-domena.cz; v případě, že by měl prijemce@cilova-domena.cz nastaveno přesměrování někam jinam (např. do jinam.cz) a pro doménu odesilatel.cz by byl nastaven striktní SPF záznam, který povoluje odesílat jeho jménem pouze příslušným MX serverům, tak kontrola na straně jinam.cz bez problémů projde, protože jako obálkový odesílatel tu nebude martin@odesilatel.cz, ale SRS0+BT2X=WE=odesilatel.cz=martin@cilova-domena.cz; pokud by nedošlo k přepisu adresy, kontrola SPF na straně jinam.cz by zjistila, že server mail.cilova-domena.cz není oprávněn posílat e-maily jménem @odesilatel.cz a přesměrování by bylo porušeno (běžný jev bez SRS)
Tiskni
Sdílej:
