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

[megoldva] Visszapattant egy levelem. Meg szeretném találni miért, és hogy tudom megjavítani.

Van két domain, hívjuk az egyiket egyik.uk-nak, a másikat meg másik.com-nak.

Van egy Google Workspace előfizetés, amit az egyik.uk domainnel hoztam létre.

A Google Workspace-ben van még 3 bejegyzés:
egyik.uk           - Primary domain
subdomain.egyik.uk - Secondary domain
másik.com          - User alias domain for egyik.uk
egyik.uk.test-google-a.com

Gmail aktív az első háromra.

Mindhárom domain-ből tudok gee@ felhasználóval emailt küldeni.

De amikor ma próbáltam valakinek a gee@másik.com címről emailt küldeni, az visszapattant.

Remote server returned '550 5.7.509 Access denied, sending domain másik.com does not pass DMARC verification and has a DMARC policy of reject.'

A message headerekből nem sokat értek (adminisztráltam smtp szervereket, és értettem a headerek jó részét, de ez még az SPF, DKIM, DMARC előtt volt). Azt hiszem, ezek lehetnek számunkra fontosak:

Authentication-Results: spf=pass (sender IP is 2607:f8b0:4864:20::92e)
 smtp.mailfrom=egyik.uk; dkim=pass (signature was verified)
 header.d=egyik-uk.20230601.gappssmtp.com;dmarc=fail action=oreject
 header.from=másik.com;compauth=fail reason=000
Received-SPF: Pass (protection.outlook.com: domain of egyik.uk designates
 2607:f8b0:4864:20::92e as permitted sender) receiver=protection.outlook.com;
 client-ip=2607:f8b0:4864:20::92e; helo=mail-ua1-x92e.google.com; pr=C

Ha jól sejtem, az a gond, hogy a másik.com domain valamiért nem engedélyezett küldő. Egyfelől nem értem, hogy a Google miért nem állította ezt úgy be, hogy bármelyik domain-ből tudjak emailt küldeni.

A kérdéseim most így kezdésként:

  • Van valahol valami weboldal, ahol tesztelni tudom, hogy jól vagy hibásan működik? Akár úgy, hogy beírom, mit akarnék, akár úgy, hogy küldök egy emailt a tesztelő email címre? Ezt azért, hogy ha vacakolok a beállításokkal, meg tudjam nézni, hogy sikerült-e kijavítani.
  • Van valami Google Workspace vagy DNS vagy nem tudommi beállítás, amivel meg tudom ezt javítani, vagy a DNS-ben kell kézzel átírnom sorokat?
  • A Google Workspace-be a második domain behozásakor vaciláltam a secondary és a user alias domain között. Ha átállítanám secondary-ra az segítene a helyzeten?

Bármi javaslat?

Egy adalék: mindkét domain a GoDaddy-n lett bejegyezve, és a Google Workspace a GoDaddy-hez kapcsolódott, amikor a domain-eket hozzáadtam.

EU ChatControl továbbgondolása

Üdv!

A téma apropója

Van egy reddit szál is a témáról, nem a pro és kontra oldaláról közelíteném meg a helyzetet, hanem hogy hogyan lehet megkerülni.
A személyes véleményem az, hogy szerintem egészen elképesztő, hogy ma a gondolatok és az információ szabad áramlását próbálják teljes kontroll alatt tartani mindenféle kamu indokokra hivatkozva.
Nem lennék meglepve, ha manapság a briteknél naponta több embert állítanának elő közösségi média posztjaik miatt, mint közlekedési szabályszegések miatt.

Szóval..

Én azt gondolom, hogy kezdésnek ha komolyabban elterjedne a BITchat vagy valamilyen mesh alapú rendszer, az igen nagy ugrás lenne.  Mindenkinek le kéne mondani az összes internet előfizetést és helyette starlinkre váltani, talán az IRC használata valamilyen titkosított formában, LoRa WAN üenetküldőket használni vagy például az új xiaomi telefonok képesek P2P üzemmódra, ez alapján valószínűleg technikailag mesh hálózatot is képesek lehetnek létrehozni, de egyelőre nem úgy működik a rendszer. Én azt gondolom, hogy nem véletlen az időzítés és nem lesz ilyen eszköz túl sok, ha ez kitudódik, így a későbbiek során akár még igen értékes eszközök is lehetnek. Mondom ezt úgy, hogy még csak most csordogálnak a 15T hardverek, (a sima 15, a Pro és az Ultra nem tudom ,hogy tudja-e ezt a funkciót) de a jelenlegi helyzetben szinte biztos, hogy lesz szoftveres megoldás a mesh létrehozására. Kézirádió is jó lehet, ott van lehetőség titkosított forgalmazásra is. Esetleg kalóz rádióállomások, a személyes találkozások a legvége... ez van. csak akkor el kéne dönteni, hogy ki is él diktatúrában. De ezeken az elvi dolgokon nem érdemes lovagolni, technikailag kell megoldani valahogy a kommunikációt.

Viszont van itt egy kis bibi. Nem olyan régen volt egy kis tapasztalásom, amit már most nem írhatok le (milyen vicces, hiszen még a rendelet nem lépett érvénybe) konkrétan. A lényeg az, hogy egy bizonyos helyen, egy bizonyos hatóság megnyomott egy bizonyos gombot, akkor felemelkedett egy bizonyos antenna és utána ott leesett az összes drón, és megszűnt mindenféle rádiókommunikáció (legalábbis azok, amiket hirtelen az ember használna): Bluetooth, WiFi, 4G és 2G mobilhálózat, 380-410 MHz-es sáv. Ezeket tudom, más tesztekre nem volt idő és lehetőség. Simán lehet, hogy a helymeghatározó szolgáltatásokat más ISM sávokat is zavart a berendezés. Erre talán az alacsony hullámhosszú rádiófrekvenciás eszközök lehetnek kerülő megoldás KHz-es sávban, de ahhoz meg kilométeres antenna kell szerintem. Szóval itt tartunk.

Akit érdekel a téma, lehet ötletelni. Még.
Mindenesetre a Telegram szerintem hamarosan elveszik, a Signal már rég elveszett, az ilyen Meta, Viber és társai meg soha nem is voltak megbízhatók.

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?