Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.8. Novinky zahrnují lepší podporu vzdálené plochy, sdílení a nahrávání obrazovky a řadu drobností napříč uživatelským rozhraním (úplný seznam změn, shrnutí ve wiki).
Apple představil 7palcový displej Apple HomeView s podporou Apple Intelligence a Siri AI pro ovládání chytré domácnosti, novou řadu vybavení chytré domácnosti Apple Home Collection, další generaci HomePodu mini a novou Apple TV 4K. Apple HomeView není v Evropské unii v prodeji, jelikož umělá inteligence Siri v rámci systému iOS v EU momentálně není k dispozici. Apple spolupracuje s EU a snaží se najít cestu, jak situaci vyřešit.
KDE slaví 30 let. Přesně před 30 lety, 14. října 1996, poslal Matthias Ettrich do diskusní skupiny comp.os.linux.misc zprávu, která započala historii projektu KDE. Důležité milníky jsou zobrazeny na časové ose.
Byl vydán Mozilla Firefox 158.0. Stejně jako Chrome 155 s podporou JPEG XL (test). Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 158 bude brzy k dispozici také na Flathubu a Snapcraftu.
Svobodný kancelářský balík ONLYOFFICE (Wikipedie) byl vydán ve verzi 10.0. Jak online Docs, tak i offline Desktop Editors. Přehled novinek také na YouTube.
Mozilla představuje Firefox Enterprise určený jako podnikový prohlížeč pro organizace s přísnými požadavky na bezpečnost, správu a dodržování předpisů. S profesionální podporou. Dostupný je zatím ve Francii, Německu, Rakousku a Švýcarsku.
Kybernetický útok zasáhl nejméně 150 supermarketů Intermarché a několik prodejen řetězců Leclerc a Coopérative U. Chladicí jednotky napadených obchodních domů byly nastaveny na nepřetržité odmrazování a teplota v nich mnohdy vystouala až nad 50°C. Škody napáchané na chlazeném a mraženém zboží budou patrně dosahovat miliónů eur.
… více »Stát Kalifornie zažaloval výrobce 3D tiskových filamentů Polymaker. Vrchní soud San Diego County tvrdí, že firma propagací svých výrobků mezi příznivci 3D tištěných zbraní podporovala výrobu takzvaných 'ghost guns' (DIY zbraní) a že její PLA filament pro 3D tiskárny lze za těchto okolností považovat za součást určenou k výrobě střelné zbraně. Žaloba požaduje mimo jiné finanční sankce a soudní zákaz činnosti, Polymaker se hájí tím, že filament je běžný a sám o sobě legální produkt. Celý text žaloby (PDF na Google Drive).
V červnu byla představena aplikace Myna pro převod řeči na text v prostředí desktopu Ubuntu. Včera byla Myna zpřístupněna širší komunitě Ubuntu formou technologické ukázky dostupné v Ubuntu 24.04 LTS, Ubuntu 26.04 LTS a Ubuntu 26.10 s GNOME na Waylandu.
Ubuntu 27.04 bude Tenacious T-Rex.
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:
