Na vývojářské konferenci Applu WWDC23 byla představena řada novinek (cz): brýle Apple Vision Pro, MacBook Air 15” s čipem M2, Mac Studio s čipem M2 Max nebo M2 Ultra, Mac Pro s čipem M2 Ultra, iOS 17, iPadOS 17, macOS Sonoma, watchOS 10, …
Chystá se poslední jarní Virtuální Bastlírna. Nachystejte si ledové kávy, mojita a vodní chladiče a pojďte se se strahovskými bastlíři pobavit o technice a bastlení! Ptáte se, co mají bastlíři za novinky? Například se ukázalo, že OLED s SSD1306 ve skutečnosti nejsou nutně jen černobílé. Vyšla také nová verze KiCADu včetně betaverze pluginu pro tvorbu databázových knihoven pro KiCAD v InvenTree a na internetu se objevil USB
… více »6. červen je dnem za skutečný internet (neboli Světový den IPv6). Již tradiční příležitost urgovat svého ISP, kdy zavede do sítě IPv6, ale také příležitost šířit osvětu i mezi netechnické uživatele. V současnosti má IPv6 v ČR jen cca 20 % uživatelů (podle statistik společností Akamai a Google).
Festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí Maker Faire Prague 2023 proběhne o víkendu 10. a 11. června na Výstavišti Praha.
Byla vydána verze 8.18 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Projekty Blink a Blinkenlights dospěly do verze 1.0. Jedná se o x86-64-linux emulátor a jeho TUI nadstavbu sloužící jako debugger. Blink je v porovnání s qemu-x86_64 menší a rychlejší.
Bylo potvrzeno, že Debian 12 s kódovým jménem Bookworm vyjde v tuto sobotu 10. června.
Byla vydána nová verze 2023.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení. Zdůraznit lze předpřipravené obrazy pro Hyper-V nebo to, že ve výchozím prostředí Xfce bylo PulseAudio nahrazeno multimediálním serverem PipeWire.
Tento týden byla vydána nová verze 1.52 webového prohlížeče Brave (Wikipedie, GitHub). Postavena je na Chromiu 114. Z novinek lze vypíchnout možnost povolit vertikální karty (vertical tabs). Také bylo představeno Brave Search API k vyhledávači Brave Search.
Matthias Clasen z Red Hatu oznámil v diskusním listu vývojářů Fedora Linuxu, že tým Red Hat Display Systems se zaměří na Wayland a podporu HDR na Linuxu a přestane spravovat RPM balíčky pro LibreOffice. V další major verzi RHELu už LibreOffice nebude. Pokud se nenajde správce balíčků pro Fedora Linux, zůstane pouze LibreOffice ve Flatpaku.
server1 = smtp.seznam.cz - jen odchozí, nic nepřijímá server2 = mx1.seznam.cz - přijímá maily pro @seznam.cz
1, Problém je, že servery někdy odpovídají přímo tomu stroji co rozesílá, místo aby provedly DNS MX dotaz a poslali to tomu stroji co je v DNS uveden. Předpokládám, že se to děje v rámci pořád navázaného smtp spojení, nebo něco podobného? Server1 se tváří že se o tu doménu stará a ty emaily "přijme", načež hodí hlášku že tam ta lokální schránka neexistuje.Jestli je hostname totozny s "domenou", tak to postfix bere jako default pro mydestination a snazi se ji taky lokalne dorucit. Pokud zmizi z mydestination, tak by mela byt routovana dle MX, pripadne dalsich definovanych mechanismu.
myhostname = server1.domena.czmůžu to smazat úplně - tedy může být postfix bez myhostname/mydomain? Nevím jestli nedělám moc velkou opičárnu, ale prostě potřebuju aby jeden server odesílal a druhý řešil bounce, odpovědi, běžné emaily atd - a nerad bych bych na prvním zprovozňoval lokální inboxy, otevíral porty atd.
Pokud zmizi z mydestination, tak by mela byt routovana dle MX, pripadne dalsich definovanych mechanismu.to ale bude posílat dle MX můj postfix ne? Tedy, ne že by to vadilo, jen mě ještě zajímá, jestli ty servery odpovídají opravdu v rámci navázaného spojení, místo aby si zjistily kam ukazuje Return-Path
můžu to smazat úplně - tedy může být postfix bez myhostname/mydomain?Ne, ja jsem mluvil o
mydestination
, ne o myhostname
, takze mydestination=
Jinak pocitej s tim, ze to ovlivni jakouli lokalni postu, tedy errory z cronu atp...
to ale bude posílat dle MX můj postfix ne? Tedy, ne že by to vadilo, jen mě ještě zajímá, jestli ty servery odpovídají opravdu v rámci navázaného spojení, místo aby si zjistily kam ukazuje Return-PathSamozrejme, bounce vzdy musi generovat to MTA, ktere nebylo schopne dorucit dal (nedostalo 250 pri end-of-data); co je vlastne return-path? Jen informace extrahovana z MAIL FROM, vlozena jako header. Nakladani s timto headerem ma sva specifika, nicmene to tebe ted moc zajimat nemusi, protoze pokud provadis submission na tom stroji, tak by tam tohle byt nemelo, to vlozi az server, ktery dorucuje finalne (do mailboxu). Tvuj server (ted jako klient) se pripoji nekam, predstavi se, rekne
MAIL FROM:<server1.domena.cz>
, dostane ok, rekne RCPT TO:<none@domain>
a nedostane ok a pokud je to jediny recipient, tak session ukonci a otevre novou v ktere dorucuje "bounce" na puvodce toho mailu (z MAIL FROM
), ktery nebyl schopen predat dal, t.j. musi zjistit, ka teremu serveru se pripojit; defaultne podle MX/A, pripadne podle definovaneho transportu, smart hosta, atp.
Na tomto chovani /nechovani je postaven cely spam. MAIL FROM a From: nemusi byt stejne a pokud servery prijmou cokoliv a resi to pozdeji, t.j. generuji bounces, pak davaji vsanc svou ip/domenovou reputaci a povetsinou do toho zatahuji treti stranu, ktera je pak prijemcem vsech tech bounces (backscatter).
Ne, ja jsem mluvil omydestination v main.cf vůbec nemám, mám tam pouze:mydestination
, ne omyhostname
, takzemydestination=
Jinak pocitej s tim, ze to ovlivni jakouli lokalni postu, tedy errory z cronu atp...
myhostname=server1.domena.cz inet_interfaces = loopback-only inet_protocols = ipv4 mynetworks = 127.0.0.0/8 alias_maps = hash:/etc/aliasespak už jen věci jako queue lifetime, destination concurrency, dkim milter atd. takže pomůže přidat "
mydestination =
" ?
maily pro roota mám forwardované na email úplně jinde, takže výpisy z cronu atd mi tam chodí.
Tvuj server (ted jako klient) se pripoji nekam, predstavi se, rekneaha - už to asi chápu, takže server to zkusí poslat na lokální mailbox, který tam není, a tak hodí hlášku pro postmaster@server1.domena.cz (mám nastaveno bounce_notice_recipient a error_notice_recipient na postmaster@server1.domena.cz) - což je ta hláška pro lokální inbox že "user not exist", no a postmaster mám přes aliases opět forwardovaný na jinou emailovou adresu - takže tím se mi to dostane... takže potřebuji jen postfix donutit k tomu aby pochopil že tam žádné lokální schránky nejsou - tím prázdným mydestination?MAIL FROM:<server1.domena.cz>
, dostane ok, rekneRCPT TO:<none@domain>
a nedostane ok a pokud je to jediny recipient, tak session ukonci a otevre novou v ktere dorucuje "bounce" na puvodce toho mailu (zMAIL FROM
), ktery nebyl schopen predat dal, t.j. musi zjistit, ka teremu serveru se pripojit; defaultne podle MX/A, pripadne podle definovaneho transportu, smart hosta, atp.
Na tomto chovani /nechovani je postaven cely spam. MAIL FROM a From: nemusi byt stejne a pokud servery prijmou cokoliv a resi to pozdeji, t.j. generuji bounces, pak davaji vsanc svou ip/domenovou reputaci a povetsinou do toho zatahuji treti stranu, ktera je pak prijemcem vsech tech bounces (backscatter).chápu - pokud ty bounce cizí server generuje sám, tak mu můžu podvrhnout nějaký fake cíl a oni ho zahltí odpovědma pokud jich bude dost - takhle fungoval i ten ntp DoS útok pokud vím.. Podle čeho se ten server v téhle fázi rozhoduje zda to přijme nebo odmítne? zkontroluje rDNS, SPF, blacklisty, pokud je to ze stejné domény mělo by to taky mít velkou váhu? (jako v mém případě). DKIM, content filter apod. jsou předpokládám v tuhle chvíli ještě mimo
$mydestination je defaultne $myhostname, localhost.$mydomain, localhost, co je v tvojom pripade ok.to jsem si myslel, ale trochu mě znejistil Kriegel tím "Ne, ja jsem mluvil o mydestination, ne o myhostname" - tak jsem radši vypsal co tam mám.
neodosielas nahodou maily s domenovou castou server1.domena.cz - niekto@server1.domena.cz?ano, přesně tak to odesílám - Return-path je bounce12345@server1.domena.cz, a "From" co vidí uživatel je info@server1.domena.cz (to bude asi i MAIL FROM?). Ty "From" adresy na tomhle stroji ale neexistují, a já potřebuju nějak postfix donutit aby NDR bounce zprávy posílal na ten druhý stroj kde je doménový koš
bounce12345@server1.domena.cz kam_chces@server2.domena.cz
mydestination v main.cf vůbec nemám, mám tam pouze:fajn, uz vis, co znamena defaultni
man postconf
takže pomůže přidat "mydestination =
" ? maily pro roota mám forwardované na email úplně jinde, takže výpisy z cronu atd mi tam chodí.
pokud to udelas takhle, tak ti forward pres aliasy nebude fungovat (to pouziva jen local agent, ktery ale v tomto pripade nebude vubec volan)
zkus mydestination=localhost.$mydomain, localhost
a roota adresuj jako root@localhost
takže potřebuji jen postfix donutit k tomu aby pochopil že tam žádné lokální schránky nejsou - tím prázdným mydestination?email fungue "per-domain". Postfix musi vedet, ze domena neni lokalni
Podle čeho se ten server v téhle fázi rozhoduje zda to přijme nebo odmítne? zkontroluje rDNS, SPF, blacklisty, pokud je to ze stejné domény mělo by to taky mít velkou váhu? (jako v mém případě). DKIM, content filter apod. jsou předpokládám v tuhle chvíli ještě mimotak to je prave to, na cem se vydelavaji $ :) je to kombinace vseho mozneho, od te nejnizsi urovne, t.j. jestli striktne dodrzuje protokol, reputace IP, rDNS, SPF je u bounces k nicemu, protoze prazdne MAIL FROM, stejnetak je pro mnohe pripady kontroverzni i pro normalni provoz, atd... tohle vsechno se da statisticky sledovat a pak s tim nakladat. Pro normalni "hobby" provoz nepotrebujes nic extra, uz jen kombinace par zakladnich a dostupnych kontrol ti odboura naprostou vetsinu. Jinak tyhle veci se obecne resi takto: mas namespace domena.cz, systemove veci posilas lokalne nebo do internetu s domenou server1.domena.cz, pripadne to maskujes. Pro masove zalezitosti mas separatni namespace, napr. bounces.domena.cz a s tou odesilas (MX pro vratky dle libosti). Pokud trackujes adresy, jestli jsou ok/nok, tak se podivej na VERP, odpadne ti slozitejsi parsovani nebo matchovani oproti databazi. Pokud ne primo VERP, tak pouziti "plus addressing" ma taky svoje vyhody, konkretne treba v tvem pripade, pokud bys posilal ve tvaru
bounces+12345@server1.domena.cz
, tak si muzes nechat nastaveni jak mas, jen nadefinujes alias bounces s cilem kos@server2.domena.cz a ses hotov.
Moznosti je spousta, zalezi, co mas, muzes a chces. Technicka realizace je az to posledni, co ti potvrdi, jestli je ten design zivotaschopny...
konkretne treba v tvem pripade, pokud bys posilal ve tvaru bounces+12345@server1.domena.cz
, tak si muzes nechat nastaveni jak mas, jen nadefinujes alias bounces s cilem kos@server2.domena.cz a ses hotov.
to "+" tam má nějaký speciální význam? není mi jasný jak nadefinovat alias když je tam doménový koš a každá adresa je jiná - tedy pro všechny adresy
Ano, je tam nastaveno něco jako VERP, celou tuhle opičárnu potřebuju proto že servery často odpovídaj dost šíleně - to že Out-of-office apod. chodí kolikrát na return-path místo na From nebo Reply-to už jsem si zvykl, ale za totální šílenost považuju NDR odpovědi s diakritikou, lahůdky jsou odpovědi kde je jen odesílatel, čas odeslání, a tělo obsahuje jen "user honza not found in domino directory", "user Ales not found", případně "ales@localhost not found" a podobně v milionu různých obměn - proto potřebuju tu adresu bezpečně určit podle adresy odesílatele.Neco jako VERP nemusi nutne znamenat VERP. VERP vyuziva prave toho, ze adresat (jeho adresa) je primo obsazena v MAIL FROM, tedy v adrese odesilatele. Problemy s dorucenim jsou pak reportovany zpet, na tuto 'MAIL FROM', ne na From nebo Reply-To (nekde vys jsem popisoval proc, ve zkratce mail server neparsuje 'DATA' cast, pri transportu operuje s 'MAIL FROM' a 'RCPT TO'). OoO je stejny pripad, je to automaticky generovana zprava, jde zpet na 'MAIL FROM'. Prave proto, ze jde zpet, mas tu zavadnou adresu naservirovanou primo pod nos, protoze je ve tvaru, jaky je u tebe v databazi, takze vis, ktera presne je spatne. Nemusis parsovat NDR, pokud te nezajima duvod, ktery stejne ruzne servery ne/reportuji kazdy jinak. Navic, pokud puvodni adresa prosla expanzi (jako ten ales@localhost) nemas rozumnou sanci machnout to s tou puvodni v databazi. Samo, ze muzes pouzit ten ciselny klic, ale je to dalsi vrstva abstrakce navic... Cteni tady
to "+" tam má nějaký speciální význam? není mi jasný jak nadefinovat alias když je tam doménový koš a každá adresa je jiná - tedy pro všechny adresyma vyznam definovaneho separatoru, vetsinou se pouziva plus, protoze se v "normalnich" adresach prilis nevyskytuje. Vyhoda je v tom, ze Postfix se k te adrese chova trochu jinak, resp. pri vyhledani bere v potaz ne/pritomnost toho detailu (to za plus). V podstate ti jde o to vse dostat na jedno misto a tam si to osetrit -- treba sieve skriptem, kterym se ten detail da matchovat velice jednoduse. Dalsi zpracovani a automatizace zalezi na mnozstvi a naslednych akcich. Mailing listy obecne trackujou pocet vracenych message za nejaky cas a pak vetsinou daneho user bud primo vyhodi nebo mu daji nejaky flag, ktery si pak manualne muze odstranit, teda pokud ma list nejake end-user administracni rozhrani... Cteni tady
man postconf
už jsi konzultoval?
Problém je, že servery někdy odpovídají přímo tomu stroji co rozesílá, místo aby provedly DNS MX dotaz a poslali to tomu stroji co je v DNS uveden. Předpokládám, že se to děje v rámci pořád navázaného smtp spojení, nebo něco podobného? Server1 se tváří že se o tu doménu stará a ty emaily "přijme", načež hodí hlášku že tam ta lokální schránka neexistuje.Ty přijímající servery určitě tomu vašemu serveru1 neposílají chybové e-maily, ani v rámci navázaného spojení (v navázaném spojení nelze poslat e-mail opačným směrem). Ty servery pouze vašemu serveru1 odpoví přímo v rámci spojení chybovým kódem (váš server pošle "tady posílám e-mail od X pro Y, e-mail je ABCD" a protější server mu odpoví "tenhle e-mail nepřijmu, důvod je XYZ"). Chybový e-mail z toho udělá až váš server. To, že se takový e-mail pokouší doručit lokálně, je pak chyba konfigurace toho vašeho serveru - zřejmě máte někde nastaveno, že má přijímat poštu pro
server1.domena.cz
.
Tiskni
Sdílej: