Web, mail, IRC, IM, hálózatok

Van egy saját domainem, az emailt is erről intézem. Az Odroidon futó OpenSMTP-6.8 a T-Online smarthost segítségével küldi ki a leveleket, ez a módszer vált eddig be a legjobban.

Vasárnap (12.01) óta a kimenő leveleim nem mennek el. Az OpenSMTP logban ezt látom:

Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp connected address=192.168.1.1 host=sagemcom
Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp authentication user=transitive result=ok
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp message msgid=14246fd3 size=635 nrcpt=1 proto=ESMTP
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp envelope evpid=14246fd31c10153b from=<transitive@akarmi.hu> to=<transitive@celcim.hu>
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp disconnected reason=quit
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta connecting address=smtp+tls://84.2.46.3:25 host=mail.t-online.hu
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta connected
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta error reason=SSL certificate check failed
Dec 03 06:24:49 486 smtpd[3150]: smtp-out: Disabling route [] <-> 84.2.46.3 (mail.t-online.hu) for 15s
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta connecting address=smtp+tls://84.2.44.3:25 host=mail.t-online.hu
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta connected
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta error reason=SSL certificate check failed
Dec 03 06:24:51 486 smtpd[3150]: smtp-out: Disabling route [] <-> 84.2.44.3 (mail.t-online.hu) for 15s
Dec 03 06:24:53 486 smtpd[3150]: smtp-out: No valid route for [connector:[]->[relay:mail.t-online.hu,port=25,smtp+tls,auth=cred:t-online,mx],0x0]
Dec 03 06:25:00 486 smtpd[3150]: 0000000000000000 mta delivery evpid=14246fd31c10153b from=<transitive@akarmi.hu> to=<transitive@celcim.hu> rcpt=<-> source="-" relay="mail.t-online.hu" delay=12s result="TempFail" stat="Network error on destination MXs"
Dec 03 06:25:04 486 smtpd[3150]: smtp-out: Enabling route [] <-> 84.2.46.3 (mail.t-online.hu)
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp connected address=154.203.197.56 host=<unknown>
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid command: Command not supported"
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp disconnected reason=disconnect
Dec 03 06:25:06 486 smtpd[3150]: smtp-out: Enabling route [] <-> 84.2.44.3 (mail.t-online.hu)

A certificate még évekig jó, nem járt le. Nekem kicsit gyanús, hogy "kerek dátummal" (12.01) leállították a t-online smarthostot, vagy valamit módosítottak rajta. Egyelőre nem tudom kideríteni, mi történt.

Ha valakinek van infója, azt megköszönném, illetve ötleteket is szívesen fogadok, mi mehetett félre. A küldés SMTP+TLS-sel stb megy, nem titkosítatlan 25-ös porton keresztül...

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Kisilabizáltam, hogy snq- a következő parancs kimenetéből idézett (ez nekem új volt):

openssl s_client -host mail.t-online.hu -port 465

és itt valóban benne van a certificate panasz. Ha jól értelmezem, a "chain of trust" sérült meg, mivel nem volt a gépemen root certificate (?), amivel a T-Online certjét verifikálni lehetett volna. 11.30-ig volt, valószínűleg 12.01-én lecseréltek a certet egy Sectigosra.

Debianon az /usr/share/ca-cerificates alatt van egy rakat cert, ide kellett betenni a mail.t-online.hu-hoz tartozó root certet, majd hívni egy update-ca-certificates -et.

Fedorán nem találtam előre telepített certeket, itt az /etc/pki-ca-trust/source/anchors könyvtárba kellett bemásolni a hiányzó certet, majd kiadni az update-ca-trust parancsot.

Ezek után a feljebb leírt openssl s_client ... parancs már nem panaszkodik, és az OpenSMTPd-m is szépen tud küldeni levelet ismét mindenhiova.

Köszönöm a segítséget!

Sziasztok

Adott a következő smb.config részlet:

### full audit ########

    vfs objects = full_audit
    full_audit:prefix = %u|%I|%m|%S
    full_audit:failure = connect
    full_audit:success = audit_file mkdirat write pwrite renameat ftruncate  unlinkat openat read pread snap_delete
    full_audit:facility = local5
    full_audit:priority = NOTICE
    path = /data/Fileserver

##########################

Ha az openat benne van, akkor 1db mappa megnyitásakor, (dokumentacio) melyben 1db almappa van (helyisegrajzok, de oda bele sem lépek, csak látom), ennnyi sor generálódik (hozzászólásba illesztem).

Miért olvassa fel ennyiszer?

Cél: Mappák és fájlok olvasásáról logom legyen. A kliensek sajnos folyamatosan sasolják a mappákat és ezek tonnányi sort generálnak.
Elég volna mappába lépéskor egy. Fájl felolvasáskor 1.
Nem tudom számít-e, de öröklő ACL-ek vannak a szülő mappákon, fájlokon.

Üdv!

A https://hup.hu/node/180937 alapján.

Hosszú jogi procedúra után a Bíróság megkérte az adatokat a google-től az alábbi szöveggel:

Az alábbi válasz érkezett a Google felől:

https://ibb.co/dfF2kWW

Kérdésem lenne, hogy ki mit lát ebben a válaszban? Lát valaki bármit is?

A Bíróság úgy értékelte, hogy érdemi válasz nem érkezett.

Téves volt esetleg a megkeresés mikéntje? A szövegezés nem volt egyértelmű, avagy csak a Google-t egyszerűen nem érdekli az egész, hiszen nem gyilkosságról van szó, és nem is lett odaírva a megkeresés oka?

Mit jelentenek az 1.2.1.2. alatt beikszelt részek?

Volt már valakinek hasonló megkeresése a Google felé? (Ami esetleg sikeres(ebb) is volt?)

Köszi a válaszokat.

Érdeklődni szeretnék, hogy hogyan viszonyul egymáshoz a play áruházból letölthető máv alkalmazás és a webes felület (ami most áll, mint ló a jégen). Tehát, ha mondjuk a weben regisztrálok, az érvényes a mobilon is? A mobilon vásárolt jegyek megjelennek a webes felületen is és fordítva is?

Köszönöm a válaszokat!

nem erdekel ha vegigmegy, csak ne ebresszen fel. elsosorban YT-hoz kene.

update:

valoban, nem irtam sem azt, hogy nem lesz sem elofizetes, sem blokkolni nem akarom, de akkor most irom :)

# ufw status
Status: active

To                         Action      From
--                         ------      ----
Anywhere                   DENY        52.0.0.0/9
Anywhere                   DENY        3.16.0.0/13
Anywhere                   DENY        3.12.0.0/14
Anywhere                   DENY        18.192.0.0/10
Anywhere                   DENY        18.188.0.0/14
Anywhere                   DENY        3.128.0.0/9
Anywhere                   DENY        18.118.0.0/15

Valakinek van meg otlete, esetleg listaja, hogy milyen tartomanyok menjenek meg a levesbe? Persze en is ossze tudnam szedni a tegnapi-mai loggok alapjan, de vsz nem en vagyok az elso, aki... Koszi :)

Kicsit bovebben: ez a "claude" nevu AI(?) kitalalta, hogy biztos abbol fog tanulni hogy egy szem(!), egyebkent login-hez kotott oldalt nezeget, ugy napi ~millios nagysagrendben. Marmint oke, az tok megnyugtato, hogy itt tart ez az egesz technologia. Meg az is otletes, hogy a nem hasznalt cloud instance-okat befogjak ilyen crawling melokra. De akkor egyreszt csinalja ezt jol, masreszt meg azert megiscsak zavaro az egeszsegesnel nagyobb load es sok felhizott logfile... szoval igy marad a nevelesi celzatu deny, meg ezzel a nehany fentivel sikerult az eredeti nehany %-ara visszadobni a query-ket. Gyors rakeresessel csak annyit talaltam az alapproblemarol hogy "igen, ez a szar leszar minden robots.txt-t meg hasonlo celzast", de igy ennyi... 

Sziasztok,

Kivételesen Windows-on lenne szükségem IIS-t beállítanom, hogy reverse proxyként működjön egy websocket szerver felé.
Kis keresgélés után össze is raktam az alábbi konfigot:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
          <rules>
            <rule name="WebSocket">
              <match url="^ws/(.*)" />
              <action type="Rewrite" url="http://172.28.85.230:8087/{R:1}" />
              <conditions>
                        <add input="{HTTP_UPGRADE}" pattern="websocket" />
                        <add input="{HTTP_CONNECTION}" pattern="upgrade" />
              </conditions>
            </rule>
          </rules>
        </rewrite>
    </system.webServer>
</configuration>

A proxyzás működik is csak hogy, az IIS egészen addig nem szolgál ki több HTTP kérést (statikus tartalmaknál sem) amíg be nem csukom a websocket kapcsolatot a böngésző <-> szerver között.
Találkozott már valaki ilyesmivel?

Windows 11 Home-on próbáltam

Helló,

PHP+MySQL/Sqlite alapú CalDAV (naptárhoz) megoldást keresnék, 1 felhasználósat. Eddig csak kb. a sabre.io (elvileg ez van az owncloudba is?), még pontosabban ennek Baïkal pluginjét, valamint a DAViCal -t találtam, amit aktívan fejlesztenek. Az lehet, hogy ezen kívül nincs más megoldás? 

Esetleg ismertek ilyesmit, vagy használtok, ami bevált?

Adsense-t használok jelenleg az oldalamon.

Az érdekelne, hogy mekkora bevételnövekedést ért el valaki. Nem kell feltétlenül prebid.js. Lehet más is ami Adsendse alternatíva.

Bugos a dovecot (2.3.*) maildirlock tool-ja, emiatt nem használható. Általában azt mondja rá a dovecot, hogy a maildirlock már elavult, mentéshez használd a dsync-et. Azonban mappatömörítéshez még mindig a maildirlock-ot ajálnja.

Itt-ott meg-pach-elik a maildirlock.c-t de elkerülném az újrafordítást. Ha jól látom, ez a utiliti csak egy "dovecot-uidlist.lock" fájlt hoz létre a Maildir mappában, és a time paraméter értelemzésénél terminál el.

Van aki beleütközött már ebbe a problémába, és van rá megoldása?

Jó megoldás lehet a maildirlock helyett manuálisan létrehozni ezt a lock fájlt, és mappatömörítés után törölni, vagy lehet ezzel szemben valami ellenérv?