sziasztok,
adott egy domain.com, amihez tartozik levelezés is, amit egy szolgáltató biztosít. úgy alakult, hogy szükségessé vált egy másik levelezőszerver beüzemelése is, ami a subdomain.domain.com fiókok levelezését szolgálja ki, a domain.com levelezéstől (elvileg) teljesen függetlenül. ez utóbbit én raktam össze, ez az első mailszerver, amit életemben felhúztam, több leírás segítségével. Ubuntu 18.04, Postfix, Dovecot, RspamD.
működik is minden, de néha magas pontszámokat kapnak a kimenő levelek a fogadó oldali spamszűrőktől, amennyire meg tudom ítélni, ennek oka a hiányzó, vagy nem megfelelő SPF, DKIM és DMARC minősítés, aláírás. ám csak olyankor, ha user@domain.com címről küldök valami@subdomain.domain.com címre, ami forwardol több user@domain.com címre. ha user@subdomain.domain.com címről küldök, akkor látszólag minden rendben.
mail header user@subdomain.domain.com címről küldve:
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
mailszerver.szolgaltato.hu
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_PASS
autolearn=no autolearn_force=no version=3.4.2
Received: from mx.szolgaltato.hu (mx.szolgaltato.hu [x.x.x.x])
by mailszerver.szolgaltato.hu (Postfix) with ESMTP id XXXXXXXXXXXXXX
for <user@domain.com>; Sat, 8 Feb 2020 14:43:12 +0100 (CET)
Authentication-Results: MAILBE-DMARC; dmarc=pass header.from=subdomain.domain.com
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=x.x.x.x; helo=mail.subdomain.domain.com; envelope-from=user@subdomain.domain.com; receiver=user@domain.com
mail header user@domain.com-ról küldve valami@subdomain.domain.com-ra és onnan megkapva user@domain.com-ra:
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
mailszerver.szolgaltato.hu
X-Spam-Flag: YES
X-Spam-Level: *****
X-Spam-Status: Yes, score=5.2 required=5.0 tests=KHOP_HELO_FCRDNS,
PDS_TONAME_EQ_TOLOCAL_SHORT,SPF_HELO_NONE,SPF_SOFTFAIL autolearn=no
autolearn_force=no version=3.4.2
X-Spam-Report:
* 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
* 3.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
* 2.0 PDS_TONAME_EQ_TOLOCAL_SHORT Short body with To: name matches
* everything in local email
* 0.3 KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS
Received: from mx.szolgaltato.hu (mx.szolgaltato.hu [x.x.x.x])
by mailszerver.szolgaltato.hu (Postfix) with ESMTP id XXXXXXXXXXXX;
Fri, 7 Feb 2020 23:08:04 +0100 (CET)
Authentication-Results: MAILBE-DMARC; dmarc=none header.from=domain.com
Received-SPF: Softfail (domain owner discourages use of this host) identity=mailfrom; client-ip=x.x.x.x; helo=mail.subdomain.domain.com; envelope-from=user@domain.com; receiver=user@domain.com
Authentication-Results: mail.subdomain.domain.com;
dkim=none;
dmarc=none;
spf=pass (mail.subdomain.domain.com: domain of user@domain.com designates y.y.y.y as permitted sender) smtp.mailfrom=user@domain.com
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.9 (mx.szolgaltato.hu [0.0.0.0]); Fri, 07 Feb 2020 23:08:03 +0100 (CET)
a vonatkozó DNS bejegyzések:
dkim._domainkey.subdomain.domain.com TXT v=DKIM1; k=rsa; p=... 3600
subdomain.domain.com TXT v=spf1 a mx a:*.domain.com ip4: x.x.x.x ~all 3600
_dmarc.subdomain.domain.com TXT v=DMARC1; p=none; pct=100; aspf=r; adkim=r; 3600
amit szeretnék, hogy lehessen küldeni emailt user@domain.com-ról és user@subdomain.domain.com-ról egyaránt úgy a mail.subdomain.domain.com szerveren keresztül, hogy azt mindhárom rendszer (SPF, DKIM, DMARC) hitelesítse. mivel az eddigi leírások elolvasása, DNS generator tool-ok és checker-ek használata nem segített rajtam, ezekben kérem a segítségeteket (tapasztalatok alapján):
- mit olvassak el, ami segít megérteni, mit hogyan állítsak be, amiből kellően mély tudást szerezhetek "elsőbálozóként"?
- merrefelé, mely konfigurációs vagy DNS beállításokban keressem a leírt problémára a megoldást?
- van-e olyan tool, ami jelentősen könnyíti a konfigurálást, tesztelést?
- milyen további info szükséges a hibakereséshez?
köszönöm!
- 1131 megtekintés
Hozzászólások
A domain és a subdomain minden rekordja legyen fasza külön-külön. Ennyiből nem derül ki...
- A hozzászóláshoz be kell jelentkezni
nekem sem derül ki ennyiből, mire gondolsz. DNS rekordokra? melyikre? melyik nincs külön? mi nem derül ki?
ha a DNS rekordokra érted, ott nem adhatok meg akármit a domain.com-ra, mert megy alatta egy subdomaintól független mail szolgáltatás.
- A hozzászóláshoz be kell jelentkezni
Értem. De az első lépés az, hogy a domain és a subdomain minden levelezéssel kapcsolatos bejegyzése rendben legyen, külön-külön. Ha mind a kettőről tudsz levelet küldeni külső címre, ahol nem pontozzák le a SPF, DKIM és DMARC kapcsán, akkor azt kizártad, hogy ezekkel van baj.
Ezek után azt kell megnézned, hogy a forward kapcsán melyik SMTP szerver bassza el a fejléceket, mert ahogy nézem, van egy forward.
- A hozzászóláshoz be kell jelentkezni
reméltem, hogy ez kiderül a nyitó postból: mindkettőről tudok levelet küldeni úgy, hogy nem pontozzák le, egyedül akkor van gond, ha forward van közben. a fenti fejlécekből nekem úgy tűnik, ilyenkor az én SMTP szerverem nem hitelesít, ezért pontozza le a szolgáltató.
- A hozzászóláshoz be kell jelentkezni
Szerintem ez a gond:
Received-SPF: Softfail (domain owner discourages use of this host) identity
A dubdomain.domain.com DNS-ében legyen ott a mail.subdomain.domain.com IP-je az SPF rekordban.
- A hozzászóláshoz be kell jelentkezni
ott van: subdomain.domain.com TXT v=spf1 a mx a:*.domain.com ip4: x.x.x.x ~all 3600
x.x.x.x mindenhol a mail.subdomain.domain.com (és egyben a subdomain.domain.com) publikus IP-je.
- A hozzászóláshoz be kell jelentkezni
Szerintem kezd ott, hogy küldj egy levelet a jelenlegi beállításaiddal a https://www.mail-tester.com/ -on látható email címre, és utána nézd meg, hogy mit mond róla. Ha az ott látható dolgokat kijavítod, akkor azzal sokat léphetsz előre a normális működés felé :)
https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
- A hozzászóláshoz be kell jelentkezni
a dkimvalidator.com-ot próbáltam, igaz csak az első verziót, arra kb. ugyanazt mondta, mint a mail header:
Result: pass (Mechanism 'a' matched)
Result code: pass Local Explanation: subdomain.domain.com: x.x.x.x is authorized to use 'user@subdomain.domain.com' in 'mfrom' identity (mechanism 'a' matched) spf_header = Received-SPF: pass (subdomain.domain.com: x.x.x.x is authorized to use 'user@subdomain.domain.com' in 'mfrom' identity (mechanism 'a' matched)) receiver=dkimvalidator.com; identity=mailfrom; envelope-from="user@subdomain.domain.com"; helo=mail.subdomain.domain.com; client-ip=x.x.x.x
SpamAssassin Score: -0.099 Message is NOT marked as spam Points breakdown: 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain
de kösz, megnézem azt is.
- A hozzászóláshoz be kell jelentkezni
Éppen a napokban tettem rendbe a dolgokat a saját domainem kapcsán (Debian / Exim páros), mert meguntam, hogy a Gmail időnként SPAM-nek gondolja a leveleimet főként az SPF / DKIM hiánya kapcsán.
A fenti oldal kifejezetten sokat segített a tesztelésben.
Ami nehezítés volt, hogy Gmail címet is szerettem volna megoldani úgy, hogy ezen a szerveren megy keresztül (nem kell külön konfigurálni a címeket), és ebből van kettő is, amiket másként kell authentikálni a Gmal SMTP-je felé...
...persze a saját domain levelezését közvetlenül intézi a szerver.
- A hozzászóláshoz be kell jelentkezni
sajnos a fenti tool nem fogad forwardolt emaileket, így alkalmatlan az én problémám vizsgálatára. találtam másik, hasonló oldalt, ami viszont fogad forwardolt leveleket is, abból is csak az derült ki, amit eddig is láttam a fejlécekben: dkim=none.
megoldás az lenne, ha kiderülne, miért nem kapnak dkim aláírást a forwardolt mailek az rspamd-től, mit és hogyan kellene konfigurálni a szerveren, hogy ez megtörténjen.
esetleg az, ha kiderülne, hogy ez eleve nem lehetséges, ezért vagy azért.
- A hozzászóláshoz be kell jelentkezni
Ez egy egész jó tool:
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
köszönöm, igen, ezt és pár hasonlót végigpróbáltam már. az a baj, hogy ezek csak az alapeseteket nézik, hogy passzolnak-e a subdomain.domain.com-hoz a vontkozó DNS rekordok. magyarul csupa zöld pipát kapok mindegyikre, de hogy mit kellene átkonfigurálnom hogyan, az nem derül ki ezekből.
- A hozzászóláshoz be kell jelentkezni
ennél még nagyobb probléma, hogy amit ezekből eddig próbáltam, egyik sem fogad forwardolt mailt, csak explicite To:-val oda címzett levelet. ez pedig lehetetlenné teszi, hogy a saját, speciális esetemet teszteljem velük (forward).
tud valaki olyat, ami fogad forwardolt mailt is?
- A hozzászóláshoz be kell jelentkezni
ha mással is szembejönne ugyanez a probléma: a forwardolt emailek esetében az SPF hitelesítést megoldotta az SRS (ubuntun, postfixhez: apt-get install postsrsd).
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mailszerver.szolgaltato.hu
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_PASS
autolearn=no autolearn_force=no version=3.4.2
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=x.x.x.x;
Authentication-Results: mail.subdomain.domain.com;
dkim=none;
dmarc=none;
spf=pass (mail.subdomain.domain.com: domain of user@domain.com designates y.y.y.y as permitted sender) smtp.mailfrom=user@domain.com
a leírások alapján vannak hátulütői is: átírja a return-path-t (valóban, de eddig úgy tűnik, megoldják az email kliensek), illetve nem kap emiatt DMARC-ot (eddig se kapott...). tesztüzem.
még a forwardolt DKIM-et szeretném megoldani valahogyan. valami azt súgja, hogy ez Postfix milter config lesz, vagy ARC modul config, vagy valami ilyesmi, vagyis hogy a forwardolt leveleket meg sem kapja most az RspamD valamiért, azért nem írja alá (és ha igaz a gyanú, akkor jó eséllyel nem is ellenőrzi, hogy spam-e.)
tippeket, ötleteket, merre keresgéljek, mit próbáljak ki, továbbra is köszönettel fogadok.
- A hozzászóláshoz be kell jelentkezni
fejlemények: sikerült rávennem az ARC modult, hogy írja alá a forwardolt leveleket:
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=subdomain.domain.com; s=dkim; t=1581513482;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=BeWKeSjOrGMo+2u2T8Ax9sD4J/WxdhJE1vM3Qf6UzrQ=;
b=yUMyaVzWviQD6Wkk7xRQuriHKwYIpj8gm92SSfwRI1ZPZpJYG0AAgo+CkLQ+8L/8RyBJd5
8dNzNXADQt6Ufn5/nzdQyeOVusjvG7d7ZPn6WkfoLI9H9lmJe9eqK5y4BIGTfvxkF1uiTP
Jvg8AatxtROv9RUn6hyukCr4BJGhjlI=ARC-Seal: i=1; s=dkim; d=subdomain.domain.com; t=1581513482; a=rsa-sha256;
cv=none;
b=kt9sF+rNtaEhd3+4PFZuRJhx/GLSj7yTxCeaNyiKUYDRbCxEZSg7kd06VgOd165LCJqxs0
4b1gd0s56yuz7FGVilRMxFIMm8VUrHdSsr2+pYLUrpmjqxkgH2dhNoxA7pTStFPK2+TH2P
Yh7iXWhWbuwVz4AHfm4ymBuZ16xYtQA=ARC-Authentication-Results: i=1;
mail.subdomain.domain.com;
dkim=none;
spf=pass (mail.subdomain.domain.com: domain of user@domain.com designates y.y.y.y as permitted sender) smtp.mailfrom=user@domain.com
mégsem kap valamiért DKIM hitelesítést:
Authentication-Results: mail.subdomain.domain.com;
dkim=none;
dmarc=none;
spf=pass (mail.subdomain.domain.com: domain of user@domain.com designates y.y.y.y as permitted sender)
ötletek, mi lehet ennek az oka?
- A hozzászóláshoz be kell jelentkezni
bár olvastam ennek ellentmondó állításokat is (miszerint a DKIM túléli a forwardot, szemben az SPF-fel), most éppen úgy tűnik, hogy koncepcionálisan ez nem így van. azaz forwardolt levelek esetén a szerver elvből nem vállal felelősséget a küldőért, hiszen jöhet bárhonnan az eredeti, ezért nem ad DKIM aláírást. ha jól értem, éppen erre találták ki 2016-ban az ARC-ot, ami csak a forwardolót hitelesíti, és ugyanúgy a fogadó szerverekre van bízva, mennyit foglalkoznak ezzel, mint a DKIM vagy SPF esetén, a különbség pusztán annyi, hogy sokkal kevesebb szerver nézi az ARC minősítést, mint a többit, mert nem terjedt még el annyira.
ha ez így van, akkor a legtöbb, amit egy forwardolt mail esetén kihozhatok, az SPF és az ARC. ezek meg is vannak. klassz lenne, ha valaki, aki ebben sokkal tapasztaltabb és tájékozottabb, megerősítene vagy cáfolna, de egyelőre úgy fest, én vagyok az első ezen a fórumon, aki mail szolgáltatást próbál felhúzni, alapvető funkciókkal...
- A hozzászóláshoz be kell jelentkezni
"egyelőre úgy fest, én vagyok az első ezen a fórumon, aki mail szolgáltatást próbál felhúzni, alapvető funkciókkal..."
Ebben azért nem lennék biztos :)
Debian Linux rulez... :D
RIP Ian Murdock
- A hozzászóláshoz be kell jelentkezni
én sem feltételezném, ezért is kértem itt segítséget, de mégiscsak azt tapasztalom, hogy alapnak tűnő kérdésekre sem kapok választ senkitől. most vagy az van, hogy eleve bele sem olvasnak a topicba azok, akiknek ez a szakterülete / megoldottak már ilyet (nem valószínű), vagy senki nem tudja a választ a kérdéseimre (nem valószínű), vagy nem akar segíteni, aki amúgy tudna (nem valószínű). szóval részemről passz.
- A hozzászóláshoz be kell jelentkezni
Én pl. elég nagy mail rendszert üzemeltetek (~5M+ mail per nap), de ilyen issue-ba nem futottam még bele.
azaz forwardolt levelek esetén a szerver elvből nem vállal felelősséget a küldőért
Az idézett részt nem értem.
Ha forwardolsz egy mailt, akkor a közbenső szerverek nyilván nem írják alá a header-t. De attól még a header-ben ott marad az eredeti sender domain és a sender szerver általal aláírt header, azt meg a recipient szervernek ki kellene tudnia bontani és tudnia kellen csekkolni. Itt a bukta csak az SPF-en lehetne, hogy domainA.com levele végül domainB.com -tól érkezik meg domainC.com -ra aki domainA.com SPF-jét nézi amiben nincs benne domainB.com
Bajnak akkor kellene lennie, ha a forwardoló szerver az eredeti sendert is átírná domainB.com -ra de nem cserélné le a DKIM-et a sajátjára.
- A hozzászóláshoz be kell jelentkezni
az idézett rész simán lehet félreértés részemről. de akkor mi lehet a magyarázat arra, hogy ha a lista@subdomain.domain.com címre küldök mailt a user@domain.com-ról, az pedig forwardol a masikuser1@domain.com, masikuser2@domain.com stb. címekre, akkor a fogadott leveleknek nincs DKIM aláírása? ha user@subdomain.domain.com-ról küldök, akkor van.
- A hozzászóláshoz be kell jelentkezni
A user@domain.com levelezőszervere ráteszi a DKIM aláírást? Egyáltalán azon a szerveren keresztül adod fel a leveled, vagy a saját levelezőszerverednek adja közvetlenül a MUI?
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
ott a pont: nem teszi rá:
Authentication-Results: MAILBE-DMARC; dmarc=none header.from=domain.com
Received-SPF: Pass (sender SPF authorized)
innentől az én szerverem sem tudja aláírni?
igen, a domain.com-hoz tartozó, külső szolgáltató SMTP-jén keresztül kapja a saját mail.subdomain.domain.com mailszerver ilyenkor. (mi az a MUI? mail kliens?)
- A hozzászóláshoz be kell jelentkezni
MUI = Mail User Agent, a levelezőprogram.
innentől az én szerverem sem tudja aláírni?
Ha nem tudod az ő DKIM rekordjaikban publikált publikus kulcsaikhoz tartozó privát kulcsot (vagy nincs publikálva DKIM rekodjuk, amire tippelek abból, hogy nincs aláírva), akkor nem fogod tudni aláírni - ez az egésznek a lényege, hogy az eredeti küldő (egész pontosan a levél fejlécekben levő küldő, nem az SMTP protokollban használt küldő, a kettő ugye nem feltétlenül azonos...) az aláírással bizonyítja, hogy valóban az ő infrájukról ment a levél.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
- A hozzászóláshoz be kell jelentkezni
kezd kitisztulni a kép, köszönöm. akkor amit saját szerverileg meg lehet tenni az ügy érdekében, azt megtettem, ezek szerint.
(akkor az MUA :)
- A hozzászóláshoz be kell jelentkezni