DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Sendmail ve verzi 8.13.1, konfigurace V10/Berkeley
a mám občas problém, že se daný soubor nepřepošle na soukromou adresu a to vždy na seznam.cz nebo email.cz
Přeposílání probíhá pomocí aliases. Na firemní adresu e-mail vždy přijde, ale přibližně 4x za den nedojde k přeposlání e-mailu na soukromou adresu. Posílám výpis z:
/var/log/maillog
[root@server ~]# cat /var/log/maillog | grep "Service unavailable"
Apr 18 13:44:20 server sendmail[10653]: o3IAeXCo009996: to=uzivatel1@email.cz, delay=01:03:47, xdelay=00:00:02, mailer=esmtp, pri=555534, relay=mx50.seznam.cz . [77.75.73.47], dsn=5.0.0, stat=Service unavailable
Apr 18 13:44:20 server sendmail[10653]: o3IAeXCo009996: o3IBiIPl010653: DSN: Serv ice unavailable
Apr 18 19:21:57 server sendmail[15967]: o3IHL5j4015950: to=uzivatel2@seznam.cz, del ay=00:00:13, xdelay=00:00:03, mailer=esmtp, pri=124603, relay=mx50.seznam.cz. [7 7.75.77.47], dsn=5.0.0, stat=Service unavailable
Apr 18 19:21:57 server sendmail[15967]: o3IHL5j4015950: o3IHLvj4015967: DSN: Serv ice unavailable
Apr 19 04:02:16 server sendmail[22400]: o3J22DoO022393: to=uzivatel3@seznam.cz, del ay=00:00:03, xdelay=00:00:02, mailer=esmtp, pri=974324, relay=mx50.seznam.cz. [7 7.75.77.47], dsn=5.0.0, stat=Service unavailable
Apr 19 04:02:17 server sendmail[22400]: o3J22DoO022393: o3J22HoO022400: DSN: Serv ice unavailable
Apr 19 13:21:59 server sendmail[1772]: o3JBL3Gp001761: to=uzivatel3@seznam.cz, dela y=00:00:12, xdelay=00:00:03, mailer=esmtp, pri=124603, relay=mx50.seznam.cz. [77 .75.77.47], dsn=5.0.0, stat=Service unavailable
Apr 19 13:21:59 server sendmail[1772]: o3JBL3Gp001761: o3JBLxGp001772: DSN: Servi ce unavailable
Apr 19 14:19:18 server sendmail[3186]: o3JCIW41003171: to=uzivatel4@email.cz, d elay=00:00:08, xdelay=00:00:02, mailer=esmtp, pri=801809, relay=mx50.seznam.cz. [77.75.73.47], dsn=5.0.0, stat=Service unavailable
Apr 19 14:19:18 server sendmail[3186]: o3JCIW41003171: o3JCJI41003186: DSN: Servi ce unavailable
Apr 19 20:34:01 server sendmail[11836]: o3JIXt7Y011829: to=uzivatel5@seznam.cz, delay=00:00:06, xdelay=00:00:02, mailer=esmtp, pri=74706, relay=mx50.seznam.cz. [77.75.77.47], dsn=5.0.0, stat=Service unavailable
Apr 19 20:34:01 server sendmail[11836]: o3JIXt7Y011829: o3JIY17Y011836: DSN: Serv
Nějak se mi nedaří přijít na to, kde je problém?
[root@server ~]# cat /var/log/maillog | grep o3RENeDs005184:
Apr 27 16:23:40 server sendmail[5184]: o3REMgDs005173: o3RENeDs005184: DSN: Service unavailable
Apr 27 16:23:41 server sendmail[5184]: o3RENeDs005184: to=guzivatel,huzivatel,houzivatel,luzivatel,puzivatel, delay=00:00:01, xdelay=00:00:01, mailer=cyrusv2, pri=270000, relay=localhost [[UNIX: /var/lib/imap/socket/lmtp]], dsn=2.0.0, stat=Sent
Apr 27 16:23:41 server sendmail[5184]: o3RENeDs005184: to=huzivatel@vodafonemail.cz, delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=270000, relay=e2sgw02.vodafone.cz. [217.77.161.170], dsn=2.0.0, stat=Sent (Ok: queued as C73515B763)
Apr 27 16:23:43 server sendmail[5184]: o3RENeDs005184: to=puzivatel@seznam.cz, delay=00:00:03, xdelay=00:00:02, mailer=esmtp, pri=270000, relay=mx50.seznam.cz. [77.75.73.47], dsn=5.5.4, stat=Service unavailable
Apr 27 16:23:44 server sendmail[5184]: o3RENeDs005184: to=guzivatel@seznam.cz, delay=00:00:04, xdelay=00:00:03, mailer=esmtp, pri=270000, relay=mx50.seznam.cz. [77.75.73.47], dsn=2.0.0, stat=Sent (Mail 16043 queued for delivery in session 56bf00000437.)
Apr 27 16:23:44 server sendmail[5184]: o3RENeDs005184: to=luzivatel@sms.eurotel.cz, delay=00:00:04, xdelay=00:00:00, mailer=esmtp, pri=270000, relay=smtp21.eurotel.cz. [160.218.160.37], dsn=2.0.0, stat=Sent (Ok: queued as 5111DF0005)
Apr 27 16:23:44 sksfw sendmail[5184]: o3RENeDs005184: o3RENeDt005184: return to sender: Service unavailable
[root@server ~]# cat /var/log/maillog | grep o3QH6CrK008668:
Apr 26 19:06:50 server sendmail[8668]: o3QH6CrK008668: from=<15e5a5b4da90e127b16916a8c89f212031cf9811e1e54ab40a80e3516e2bf15224e80697b021e2b0c6500ca8a1bbf261eb52ec8d1a11662e8f9f13e106393398@bounces.avenija.com>, size=51606, class=0, nrcpts=1, msgid=<201004261706.o3QH6CrK008668@sksfw.sksblansko.cz>, proto=ESMTP, daemon=MTA, relay=smtp93.avenija.com [91.198.190.93]
Apr 26 19:06:53 server sendmail[8668]: o3QH6CrK008668: Milter add: header: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,HTML_MESSAGE,\n\tMIME_HTML_ONLY,MISSING_MID,SPF_PASS,T_FRT_CONTACT,T_RP_MATCHES_RCVD\n\tautolearn=no version=3.3.1
Apr 26 19:06:53 server sendmail[8668]: o3QH6CrK008668: Milter add: header: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on server.domena.cz
Apr 26 19:06:53 server sendmail[8668]: o3QH6CrK008668: Milter add: header: X-Virus-Scanned: clamav-milter 0.96 at server.domena.cz
Apr 26 19:06:53 server sendmail[8668]: o3QH6CrK008668: Milter add: header: X-Virus-Status: Clean
Apr 26 19:06:53 server sendmail[8679]: o3QH6CrK008668: to=< guzivatel@ domena.cz>, delay=00:00:03, xdelay=00:00:00, mailer=cyrusv2, pri=112200, relay=localhost, dsn=2.0.0, stat=Sent
Apr 26 19:06:55 server sendmail[8679]: o3QH6CrK008668: to=guzivatel@seznam.cz, delay=00:00:05, xdelay=00:00:02, mailer=esmtp, pri=112200, relay=mx50.seznam.cz. [77.75.77.47], dsn=5.0.0, stat=Service unavailable
Apr 26 19:06:55 server sendmail[8679]: o3QH6CrK008668: o3QH6trK008679: DSN: Service unavailable
[root@server ~]# cat /var/log/maillog | grep o3REdcuL005566
Apr 27 16:39:57 server sendmail[5566]: o3REdcuL005566: Milter add: header: X-Virus-Scanned: clamav-milter 0.96 at server.domena.cz
Apr 27 16:39:57 server sendmail[5566]: o3REdcuL005566: Milter add: header: X-Virus-Status: Clean
Apr 27 16:39:59 server sendmail[5577]: o3REdcuL005566: to=< huzivatel@ domena.cz>, delay=00:00:21, xdelay=00:00:02, mailer=cyrusv2, pri=20712785, relay=localhost, dsn=2.0.0, stat=Sent
Apr 27 16:40:01 server sendmail[5577]: o3REdcuL005566: to=huzivatel@seznam.cz, delay=00:00:23, xdelay=00:00:02, mailer=esmtp, pri=20712785, relay=mx50.seznam.cz. [77.75.77.47], dsn=5.0.0, stat=Service unavailable
Apr 27 16:40:01 server sendmail[5577]: o3REdcuL005566: o3REe1uL005577: DSN: Service unavailable
[root@server ~]# cat /var/log/maillog | grep o3RENeDs005184:
Apr 27 16:23:40 server sendmail[5184]: o3REMgDs005173: o3RENeDs005184: DSN: Service unavailable
Apr 27 16:23:41 server sendmail[5184]: o3RENeDs005184: to=guzivatel,hauzivatel,huzivatel,luzivatel, puzivatel, delay=00:00:01, xdelay=00:00:01, mailer=cyrusv2, pri=270000, relay=localhost [[UNIX: /var/lib/imap/socket/lmtp]], dsn=2.0.0, stat=Sent
Apr 27 16:23:41 server sendmail[5184]: o3RENeDs005184: to=hauzivatel@vodafonemail.cz, delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=270000, relay=e2sgw02.vodafone.cz. [217.77.161.170], dsn=2.0.0, stat=Sent (Ok: queued as C73515B763)
Apr 27 16:23:43 server sendmail[5184]: o3RENeDs005184: to=puzivatel@seznam.cz, delay=00:00:03, xdelay=00:00:02, mailer=esmtp, pri=270000, relay=mx50.seznam.cz. [77.75.73.47], dsn=5.5.4, stat=Service unavailable
Apr 27 16:23:44 server sendmail[5184]: o3RENeDs005184: to=lukas.grim@seznam.cz, delay=00:00:04, xdelay=00:00:03, mailer=esmtp, pri=270000, relay=mx50.seznam.cz. [77.75.73.47], dsn=2.0.0, stat=Sent (Mail 16043 queued for delivery in session 56bf00000437.)
Apr 27 16:23:44 server sendmail[5184]: o3RENeDs005184: to=luzivatel@sms.eurotel.cz, delay=00:00:04, xdelay=00:00:00, mailer=esmtp, pri=270000, relay=smtp21.eurotel.cz. [160.218.160.37], dsn=2.0.0, stat=Sent (Ok: queued as 5111DF0005)
Apr 27 16:23:44 server sendmail[5184]: o3RENeDs005184: o3RENeDt005184: return to sender: Service unavailable
1) Právě ty e-maily se nevrátí, vrátí se jen ty e-maily co přesáhnou 18 MB, ty se vrátí ihned.
2) Logiku jsem hledal dlouho, ale bohužel na nic jsem nepřišel.
3) Podporu zkusím, sice na stránkách jsou kontakty dosti zmatené, ale snad se se domluvím.
(/www/rsyslog/netlog/email-smtpd7/smtpd-20100505.gz:2010/05/05 10:36:50 W2: [9595]: Received second RCPT TO with empty MAIL FROM address: uzivatel@seznam.cz (sid='257b00000089', ip='77.48.107.100', helo='server.domena.cz', from='', country='CZ', duration='00:00:02.052') {command.cc:exec():1388})
Takovéto emaily pak záměrně nedoručujeme.
Další chybou by mohlo být nastavení Vašeho SMTP serveru, který by neměl považovat SMTP komunikaci, která není uzavřena tečkou (".") za ukončenou a neměl by pak tyto zprávy mazat z fronty.
Nicméně vůbec netuším proč se poštovní server tak zachová, protože 100 e-mailů přepošle a pak třeba 1 nepřepošle. Ani nevím kde pořádně chybu hledat.
Mohl by prosím někdo poradit, kde hledat chybu, nebo jak to řešit?
Tiskni Sdílej: