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

Ti fogadtok már levelet RDNS nélkül?

Pár éve felvetődött a kérdés, hogy illő-e RDNS nélkül levelet küldeni, illetve mekkora illetlenség visszautasítani az ilyen leveleket. Akkor az lett a végeredmény, hogy azért az RDNS hiánya elég ok egy levél visszautasítására.

Mostanában azonban már - a naplók alapján - a gmail is sokszor próbál RDNS nélküli vagy hibás RDNS-sel rendelkező IP címekről levelet küldeni. Például egy mai bejegyzésben: "H=(mail-yx1-f44.google.com) [74.125.224.44]:58407", pedig a alt1.aspmx.l.google.com név feloldása jelenleg 74.125.131.26. De van amikor fel sem oldható a név.

Magamtól az gondolnám, ezek illetéktelen küldési kísérletek, ha nem tudnám, hogy valós gmail levelezésből is származnak ilyen bejegyzések.

Tudtommal a gmail általában igyekszik betartani az RFC-ket. Vagy már ez is csak a múlt?

Így 2025 derekán illő még RDNS alapján szűrni, vagy már annyira váltogatják az IP címeket, hogy elavult ez a szűrési mód?
 

Német agybaj újratöltve: Illegálissá válhat a reklámblokkolás, börtön is járhat majd érte

Illegálissá válhat a reklámblokkolás, börtön is járhat majd érte Európában?

Hamarosan illegálissá válhat a reklámok blokkolása a weboldalakon, amiért akár börtönbüntetést is járhat majd - legalábbis Németországban. Egy, a napokban meghozott döntésével ugyanis a német Szövetségi Legfelsőbb Bíróság (BGH) kimondta, hogy a weboldalak kódja is lehet a szerzői jog által védett alkotás, amik engedély nélküli módosítása a szerzők engedélye nélkül így kimerítheti a szerzői jog megsértésének bűncselekményét is.

Is Germany on the Brink of Banning Ad Blockers? User Freedom, Privacy, and Security Is At Risk. – Op [blog.mozilla.org]

Springer vs Adblock Plus enters another round

(Láthatóan a forrás pcforum mint malac a jégen küzd az reklámblokkolás ellen, de nem sok sikerrel :-)

Phishing a Cisco támogatásával

Honeypotom kellemes esti szórakozást dobott fel egy phissing levél képében. A levelező szerverem adminja tájékoztatott, hogy 7 levelem van visszatartva és klikkeljek a lenti linkre:
https://secure-web.cisco.com/1aur891QxqfxRaoPbe2SixJVRc1OGSqy0cvne9f52k…

Lévén a levelező szerveremnek én vagyok az adminja és a melóhelyen még nem szívtam annyi hidrazint, hogy magammal levelezzek, utánatúrtam a linknek.
A dolog innen kezdve a klasszikus pingpongos, javascriptes átküldözgetéses történetbe torkollik, ami a grillráccsos hosttól a tinyurl-en keresztül egy https://u64.rspglmb.org/sec oldalra landol, ami szintén egy faék egyszerű javascriptes oldallal próbálja behúzni a emailünkhöz tartozó jelszót.

A dologban nincs újdonság, egyedül az induló link csomagolása.
 

Halva született kezdeményezés az EU 18 éves kort ellenőrző "pornókapu" app-ja

Ahogyan az várható volt, már szinte születése pillanatában kijátsszák az EU bürokratáknál láthatóan sokkal értelmesebb és leleményesebb tini gyerekek a pornó-kaput:

https://cyberplace.social/@GossiTheDog/114915518256108559

A videójátékok segítettek a rendszer kijátszásában. 

Logrotate.d: napi rotálás kimaradása

Be van állítva a mail.log fájlra, hogy a logrotate naponta rotálja, mégis tegnap egy napot kihagyott. Előtte is rotált, ma is rotált. Mi lehet az oka?

A logrotate.d/mail fájl tartalma:

/var/log/mail.log
{
    rotate 378
    daily
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

A /var/lib/logrotate/status fájlban minden nap, azaz tegnap is bekerült az aktuális napi dátum.

A naplóban mindhárom napon szerepelnek a következő sorok:

Starting logrotate.service - Rotate log files...
logrotate.service: Deactivated successfully.
Finished logrotate.service - Rotate log files.

Néha még a "logrotate.service: Consumed 2.218s CPU time." sor is szerepel, de más nem, azaz hibaüzenet sincs.

A cron naplójában sem látok semmi furát, eltérést a napok között, nincs hibaüzenet.

Az /etc/logrotate.conf fájlban nincs globálisan megadva a "size" paraméter.

A nem rotált naplóból látszik, hogy minden nap sok sor kerül bele, így a "notifempty" opció sem okozhatta.

Van ötletetek, miért marathatott egyben a tegnapi és a tegnapelőtti log?

Kinek kell az APNG?

Ennek a topiknak a kapcsán gondolkodtam el, hogy mégis, mi haszna? Használná valaki?

Mert hát, ha egy weblapra valami kis izgő-mozgó biszbasz kell, arra sokkal jobb és hatékonyabb a GIF. De még rövid videókra is, mert elég sokat fejlődtek a kvantáló és dithering algoritmusok (aki nem hiszi, látogasson el a giphy-re).

Ha meg valakinek tényleg szűkös a GIF, azoknak régóta ott a WEBP, ami szintén elérhető minden böngészön, kezel palettás képeket, true-color képeket, alfa csatornát és animációt is (nem összekeverendő a WEBM-mel, ami csak videókra jó, transzparens animációkra nem). Egyszóval mindent tud, amit az APNG akar nyújtani, csak hát sokkal jobb a tömörítése.

Szóval a kérdés az, lát-e valaki gyakorlati hasznot abban, hogy szabvány lett az animált PNG? Szerintetek meg fog ugrani az APNG képek száma a wenoldalakon ezután, ha ezidáig elhanyagolható volt annak ellenére, hogy eddig is támogatták a böngészők?

ps: az, hogy az APNG nem hatékony és szar, nem újdonság. Az eredeti PNG fejlesztők is így gondolják, ezért inkább átdolgozták, és a hivatalos PNG oldalon is az MNG-jüket próbálják propagálni helyette (ez se mai gyerek, 1998-as, mégse volt képes ledönteni a GIF-et ez se a trónról).

Exim: túl sok hibás címzett blokkolása ip alapon

Próbálom Exim alatt korlátozni, hogy egy IP címről csak mondjuk 5 hibás címzettre tudjon megpróbálni levelet küldeni valaki. Sajnos az eddig próbálkozásaim nem sikerültek. Az exim kézikönyvben nem is látok per_ip opciót a ratelimit-hez.

Ha valaki csinált már ilyet, megköszönnék egy működő szabályt.