Švýcarská AI centra EPFL, ETH Zurich a CSCS představila otevřený vícejazyčný velký jazykový model (LLM) s názvem Apertus. Vyzkoušet lze na stránce Public AI Inference Utility.
Byl vydán Linux Mint 22.2 s kódovým jménem Zara. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze novou XApp aplikaci Fingwit pro autentizaci pomocí otisků prstů nebo vlastní fork knihovny libAdwaita s názvem libAdapta podporující grafická témata. Linux Mint 22.2 bude podporován do roku 2029.
Čínská společnost Tencent uvolnila svůj AI model HunyuanWorld-Voyager pro generování videí 3D světů z jednoho obrázku a určené trajektorie kamery. Licence ale nedovoluje jeho používání na území Evropské unie, Spojeného království a Jižní Koreje.
Blender Studio se spojilo s kapelou OK Go a výsledkem je videoklip k písni Impulse Purchase. Stejně jako samotný 3D software Blender je i ve videoklipu použitý animovaný chlápek open source. Kdokoli si jej může stáhnout a upravovat.
Zig Software Foundation stojící za programovacím jazykem Zig publikovala finanční zprávu za rok 2024. Současně s prosbou o finanční příspěvek.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za srpen (YouTube). Vypíchnuta je podpora Tabulek Google, implementace Gamepad API a Cookie Store API nebo také podpora WebGL na Linuxu.
openSUSE Leap 16, včetně Leap Micra 6.2+, nově nabízí 24 měsíců podpory pro každé vydání. To je dva roky aktualizací a stability, což z něj činí nejdéle podporovanou komunitní distribuci vůbec. Leap se tak stává ideální platformou pro všechny, kdo hledají moderní, stabilní a dlouhodobě podporovanou komunitní Linux distribuci.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal dne 3. 9. 2025 VAROVÁNÍ před hrozbou v oblasti kybernetické bezpečnosti spočívající v předávání systémových a uživatelských dat do Čínské lidové republiky a ve vzdálené správě technických aktiv vykonávané z území Čínské lidové republiky. Varováním se musí zabývat povinné osoby podle zákona o kybernetické bezpečnosti.
Americká internetová společnost Google nemusí prodat svůj prohlížeč Chrome ani operační systém Android. Rozhodl o tom soud ve Washingtonu, který tak zamítl požadavek amerického ministerstva spravedlnosti. Soud ale firmě nařídil sdílet data s jinými podniky v zájmu posílení konkurence v oblasti internetového vyhledávání. Zároveň Googlu zakázal uzavírat dohody s výrobci mobilních a dalších zařízení, které by znemožňovaly
… více »Prvního září ozbrojení policisté zatkli na na londýnském letišti Heathrow scénáristu a režiséra Grahama Linehana, známého především komediálními seriály Ajťáci, Otec Ted nebo Black Books. Během výslechu měl 57letý Graham nebezpečně zvýšený krevní tlak až na samou hranici mrtvice a proto byl z policejní stanice převezen do nemocnice. Důvodem zatčení bylo údajné podněcování násilí v jeho 'vtipných' příspěvcích na sociální síti
… více »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:
