Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Server1 193.193.193.1 server1.neco.cz Server2 193.193.193.2 server2.neco.cz Server3 193.193.193.3 server3.neco.cz Server4 193.193.193.4 server4.neco.cz Server5 193.193.193.5 server5.neco.czVše funguje a pomocí parametrů
inet_interfaces = 193.193.193.1,...2, ....3,... smtp_bind_address = 193.193.193.1mu tedy říkám posílej vše jako server1.neco.cz a poslouchej i na ostatních adresách které máš po starých serverech. Problém nasatává ve chvíli kdy komunikuje nějaký server na starou adresu a dozví se že tam poslouchá postfix ale představí se jako SERVER1 A NE NAPŘÍKLAD JAKO SERVER2 jak svázat greting name s jednotlivími IP ?? a nebo ještě lépe svázat i virtualdomains a transport s jednotlivími IP např doménu domena1.cz odesílej jako Server 1 a třeba relay domen dle transport odesílej jako Server5 Díky za nakopnutí :)
jak svázat greting name s jednotlivími IP ??napada ma jedine toto: pre kazdu IPcku spustis jednu instanciu demona smtpd. kazdej nastavis ine 'myhostname'. teda do master.cf pridas nieco taketo:
193.193.193.1:25 inet n - n - - smtpd -o myhostname=server1.neco.cz
193.193.193.2:25 inet n - n - - smtpd -o myhostname=server2.neco.cz
193.193.193.3:25 inet n - n - - smtpd -o myhostname=server3.neco.cz
193.193.193.4:25 inet n - n - - smtpd -o myhostname=server4.neco.cz
193.193.193.5:25 inet n - n - - smtpd -o myhostname=server5.neco.cz
/etc/postfix/main.cf: virtual_alias_maps = hash:/etc/postfix/virtual /etc/postfix/virtual: user@domain.tld user@domain.tld, user@domain.tld@autoreply.mydomain.tld /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: autoreply.mydomain.tld autoreply: /etc/postfix/master.cf: # ============================================================= # service type private unpriv chroot wakeup maxproc command # (yes) (yes) (yes) (never) (100) # ============================================================= autoreply unix - n n - - pipe flags= user=nobody argv=/path/to/autoreply $sender $mailboxa výsledek je tento :
< moje@mydomain.tld>): Command died with status 1: "/path/to/autoreply". Command output: pipe: fatal: pipe_command: execvp /path/to/autoreply: No such file or directorykde udělali soudruzi z NDR chybu :( ?? napadá někoho něco ?
Problém nasatává ve chvíli kdy komunikuje nějaký server na starou adresu a dozví se že tam poslouchá postfix ale představí se jako SERVER1 A NE NAPŘÍKLAD JAKO SERVER2Jaký problém nastává? Text v HELO (nebo EHLO) je jenom informativní, můžete si tam napsat třeba "bla bla bla". Nějaký SMTP klient s tím podniká něco jiného, než že to zapíše do logu?
Received: from mxm.seznam.cz (mxl.seznam.cz [77.75.72.44])Pokud jen kontroluje, zda pro text v HELO existuje A záznam nebo MX záznam, není potřeba mít pro každého klienta jiný HELO. Navíc to může rozesílat stále jeden počítač s jednou IP adresou, protože se doména nemá na odesílaný e-mail žádný vliv. Takže pokud si tazatel nebude dávat tu práci, aby e-maily speciálně posílal z různých zdrojových adres, rozesílá vše jen z jedné IP adresy s jedním reverzním záznamem a tudíž by i pro tohle potřeboval jen jeden text pro HELO. Greeting message se ale podle mne týká textu odpovědi na HELO 250 (a úvodní 220), a to se netýká odesílaných e-mailů, ale přijímaných e-mailů. Pokud tohle někdo kontroluje, budou si ztěžovat dodavatelé svému správci, ne vaši zákazníci vám
RCPT TO
protokolu SMTP
), e-mail se pak odešle některému ze serverů, který je uveden u této domény v MX záznamech v DNS. Jak a kudy se a-mail bude odesílat, to je úplně jedno, jediné na čem záleží je, zda bude zvolený SMTP server e-mail ochoten doručit – ať už jako cílový server, který e-mail doručí do schránky, nebo jako SMTP relay.
no ale pre jednu domenu ktoru hostujem pre isteho providera chodia cez jeho SMTP relay ktory napriklad doklada do sprav paticku s textom blablabla doverne informacie... a neviem co esteJinými slovy chcete, aby pokud někdo v adrese odesílatele v obálce náhodou vyplní určitou doménu (což je celkem pravděpodobné, protože většina klientů tam doplňuje adresu zadanou uživatelem), a ten e-mail náhodou půjde přes váš server, aby se e-mail přeposlal na jiný server. K tomu můžete použít v Postfixu sender_dependent_relayhost_maps. Ovšem nevím, jak se to bude chovat v případě, že váš server je zároveň pro danou doménu cílový server, a e-mail bude mít v obálce danou doménu jako odesílatele i přijímce. Aby si ten e-mail pak ty dva servery nepředávaly sem tam do té doby, než to jeden z nich přestane bavit. Ovšem rozumnější by bylo uživatele nějakým způsobem autorizovat a přeposlání provádět pro zvolené uživatele. Protože pokud to budete rozlišovat jen podle domény uvedené v příkazu
MAIL FROM
, může si to přeposlání (a přidání oné patičky) zlomyslně vynutit kdokoliv, pro koho je váš server ochoten doručovat e-maily – tedy jednak všichni uživatelé počítačů v „lokální síti“ (tedy všechny počítače z mynetworks
), jednak kdokoli, kdo uvede jako cílovou doménu některou z těch, které máte v mydestination
, virtual_mailbox_domains
nebo relay_domains
.
... a ten e-mail náhodou půjde přes váš server, aby se e-mail přeposlal na jiný server.on ten e-mail pojde urcite von cez tento server bo uzivatelia ktory maju zriadeny mail v domene prejdu vsetci cez tento smtp... (ja viem, pisem hrozne nepochopitelne) zatial to riesim podobne ako bolo riesene hore nazov serveru tzn mam daemon-a spusteneho na dvoch ip a jeden ma nastaveny relayhost na server providera... inak ten smtp na ktorom toto robim je presne aj cielovy server pre domenu a tak to mam vyskusane v praxi ze si tieto maily servery nepreposielaju ani s relayhost ani s sender_dependant_relayhost_maps... ak totiz pride mail s RCPT TO: s touto domenou tak cez pipe to vybavi maildrop... vdaka za napad...
na uvod samozrejme TLS s SSL pouzivam a sender_depend... som skusal ale nevyhovovalo mi to prave pre to ze sa mohli najst uzivatelia ktory MAIL FROM: nemali vyplnene, vyplnali zle a podobne ...Pak asi můžete použít
smtpd_sender_restrictions
pro vynucení toho, aby autorizovaný klient poslal správnou hlavičku MAIL FROM, a pak použít zmíněný sender_dependent_relayhost_maps
pro předání jinému SMTP serveru.
193.193.193.1 mailpri.mojedomena.cz
193.193.193.2 mailsec.mojedomena.cz
v main.cf
smtp_bind_address 193.193.193.1
díky za nápad
ip
z balíčku iproute2
.
Tiskni
Sdílej: