Multiplatformní multimediální knihovna SDL (Simple DirectMedia Layer) byla oficiálně vydána v nové major verzi 3 (3.2.0). Změny jsou popsány v README pro migraci aplikací z SDL 2 na SDL 3.
Wine bylo po roce vývoje od vydání verze 9.0 vydáno v nové stabilní verzi 10.0. Přehled novinek na GitLabu. Vypíchnuta je nová architektura ARM64EC a podpora High DPI škálování.
Edvard Rejthar na blogu zaměstnanců CZ.NIC představil nástroj deduplidog pro odstranění duplicitních souborů.
Společnost DeepSeek představila (𝕏) AI model DeepSeek-R1 (Hugging Face) srovnatelný s OpenAI o1 a uvolnila jej pod open source licencí MIT, tj. zdarma i pro komerční použití.
GKrellM (GNU Krell Monitors, Wikipedie), tj. grafická aplikace pro sledování systémů a různých událostí, byla po pěti a půl letech vydána v nové verzi 2.4.0. Přehled novinek na Gitea.
Americká první dáma Melania Trumpová vydala v předvečer manželovy inaugurace vlastní kryptoměnu. Jmenuje se $Melania. Donald Trump vydal vlastní kryptoměnu $Trump den před manželkou.
GNU Project Debugger aneb GDB byl vydán ve verzi 16.1. Podrobný přehled novinek v souboru NEWS.
Po 9 týdnech vývoje od vydání Linuxu 6.12 oznámil Linus Torvalds vydání Linuxu 6.13. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies. Odstraněn byl souborový systém ReiserFS.
19. ledna 2038 přeteče hodnota time_t na 32bitových systémech, na vyřešení problému roku 2038 (Y2K38) tedy zbývá 13 let. Např. Debian v uplynulém roce přešel na 64bitový čas. Bernhard Wiedemann z openSUSE sdílí chyby v sestavení rozšířeného softwaru.
Byla vydána druhá opravná verze 21.2 v dubnu loňského roku vydané verze 21 multimediálního centra Kodi (dříve XBMC, Wikipedie) s kódovým označením Omega.
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
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.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 $mailbox
a 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 directory
kde 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
(A opět, dotyční dodavatelé by ani neposlali e-mail na Seznam. Ne že by Seznam byl nějaký etalon vzorového mailserveru, ale administrátor, který by odolával stížnostem na to, že nechodí e-maily na/z Seznam, by musel mít opravdu hroší kůži.)
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:
