A teszt működése

RFC 4406 §4 — Record Selection

Feladóazonosító `auth.sender_id`

Ugyanaz az ellenőrzés, mint az SPF, de a boríték helyett a From fejlécben szereplő domainre futtatva. Más kérdésre ad választ: arra, hogy az olvasó által látott domain engedélyezi-e az üzenetet küldő szervert. Egy üzenet megfelelhet az SPF-nek a borítékja alapján, miközben a látható domain egyetlen küldőt sem hitelesít.

Ha sikertelen: Tegyen közzé SPF-rekordot a From fejlécben szereplő domainhez, ne csak a platform által megadott visszapattanási domainhez.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban és legfeljebb 0.5 pont a 10-ből a klasszikus pontszámban.

After the above steps, there should be one record remaining and evaluation can proceed.

SPF `auth.spf`

Az SPF egy DNS-rekord, amely felsorolja, hogy mely szerverek küldhetnek az Ön domainje nevében. A fogadó szerver kiolvassa a címet a borítékból, lekéri az adott domain rekordját, és ellenőrzi, hogy a kapcsolódó IP szerepel-e benne. Jelentjük az eredményt és a rekord kiértékeléséhez szükséges DNS-lekérdezések számát, mert a kiértékelés tíznél leáll, és minden ezen túli érték sikeres ellenőrzés helyett állandó hibának számít.

Ha sikertelen: Tegyen közzé egy rekordot, amely kizárólag a küldési platformját nevezi meg. Ha az Öné közel van a tízlekérdezéses korláthoz, lapítsa ki a nem használt include elemeket (egy ma még sikeresen ellenőrzött rekord hibássá válik azon a napon, amikor egy szolgáltató hozzáad egy saját include elemet).

Levonás: legfeljebb 18 pont a 100-ból a saját pontszámunkban és legfeljebb 1 pont a 10-ből a klasszikus pontszámban.

RFC 7208 §4.6.4 — DNS Lookup Limits

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

RFC 7208 §2.6 — Results of Evaluation

Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.

Google — Set up SPF

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

SPF-igazítás `auth.spf_alignment`

Azt jelzi, hogy a visszapattanási cím egyezik-e az olvasó által látott From címmel. Az SPF a borítékot engedélyezi, a DMARC pedig csak akkor veszi figyelembe ezt az engedélyezést, ha a kettő igazodik egymáshoz.

Ha sikertelen: Kérjen a küldési platformjától egy visszapattanási aldomaint a saját domainje alatt. Ha a DKIM már igazodik, ez nem sürgős, de tartalék nélkül marad arra az esetre, ha a DKIM továbbítás közben érvénytelenné válik.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban és legfeljebb 0.5 pont a 10-ből a klasszikus pontszámban.

RFC 9989 §4.4.2 — SPF-Authenticated Identifiers

Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Infrastruktúra és hírnév

A gép és a cím, amelyről az üzenetet elküldték, valamint az, amit az internet többi része már gondol róluk.

A küldő állomásnév feloldható `infra.a_record`

Az, hogy a HELO során közölt állomásnévhez tartozik-e egyáltalán címrekord.

Ha sikertelen: Tegyél közzé A rekordot ahhoz a névhez, amelyet a kiszolgálód közöl.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban és legfeljebb 3 pont a 10-ből a klasszikus pontszámban.

RFC 5321 §5.1 — Locating the Target Host

If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.

Google — Set up MX records

Tiltólisták `infra.dnsbl`

Azt, hogy a küldő IP szerepel-e a fogadó rendszerek által ténylegesen használt tiltólisták bármelyikén. A listánkat az egyes zónák saját dokumentált tesztpontja alapján ellenőrizzük, nem pedig internetes keresésből állítjuk össze, mert egy megszűnt zóna NXDOMAIN választ ad, ez pedig „tisztának” tűnik.

Ha sikertelen: Kövesse a listázást végző szolgáltató webhelyén található törlési eljárást. Egy jelentős zónán való szereplés teljesen megakadályozza a levelek kézbesítését, ezért ezt kezelje minden más előtt az oldalon.

Levonás: legfeljebb 25 pont a 100-ból a saját pontszámunkban és legfeljebb 3 pont a 10-ből a klasszikus pontszámban.

RFC 5782 §2.1 — IP Address DNSxL

Each IPv4 address listed in the DNSxL has a corresponding DNS entry.

RFC 5782 §5 — Test and Contact Addresses

IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.

Google — Postmaster Tools: reputation and delivery errors

RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)

HELO-név `infra.helo`

Az a név, amellyel a küldő kiszolgáló az SMTP-beszélgetés elején azonosítja magát. Teljes képzésű, feloldható tartománynévnek kell lennie.

Ha sikertelen: Állítsd a levelezőkiszolgáló állomásnevét a tartományod egy valós nevére, ne egy konténerazonosítóra vagy belső névre.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban.

The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

MX rekord `infra.mx`

Az, hogy a From fejlécben szereplő tartomány képes-e levelet fogadni. Enélkül a válaszoknak és a visszapattanó leveleknek nincs hová érkezniük, a szűrők pedig rossz jelként értékelik, ha egy küldő tartomány nem képes levelet fogadni.

Ha sikertelen: Tegyél közzé MX rekordot ahhoz a tartományhoz, amelyről küldesz, még akkor is, ha az csak egy havonta egyszer ellenőrzött postafiókba irányít.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban és legfeljebb 3 pont a 10-ből a klasszikus pontszámban.

RFC 5321 §5.1 — Locating the Target Host

The lookup first attempts to locate an MX record associated with the name.

Google — Set up MX records

Fordított DNS `infra.rdns`

Az, hogy a küldő IP visszafelé feloldható-e egy állomásnévre, és hogy ez az állomásnév előrefelé ugyanarra az IP-re oldható-e fel. A kétirányú egyezés a lényeg: egy bárhová mutató PTR könnyen beállítható, egy egyező pár viszont bizonyíték arra, hogy a cím a tiéd.

Ha sikertelen: Kérd meg az IP tulajdonosát, hogy a PTR-t egy általad felügyelt névre állítsa, és győződj meg arról, hogy ehhez a névhez tartozik egy visszafelé mutató A rekord.

Levonás: legfeljebb 12 pont a 100-ból a saját pontszámunkban és legfeljebb 1.5 pont a 10-ből a klasszikus pontszámban.

RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Átviteli titkosítás `infra.tls`

Az, hogy az üzenet TLS-kapcsolaton keresztül érkezett-e, és milyen titkosítócsomaggal. Minden korszerű rendszer egyezteti ezt; a titkosítatlanul érkező üzenet árulkodik a küldési beállításokról.

Ha sikertelen: Engedélyezd a STARTTLS használatát a küldő kiszolgálón. Ezt már minden elterjedt platform támogatja, ezért az itteni hiba általában azt jelenti, hogy saját üzemeltetésű továbbító található az útvonalon.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban.

RFC 3207 §2 — STARTTLS Extension

The STARTTLS extension to SMTP is laid out as follows:

Google — Send email over a secure TLS connection

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Spamszűrő motorok

Hogyan értékelik az üzenetet a független tartalomszűrők. Egy helyett két motor, mert egyetlen motor pontszáma az adott motor véleménye.

AI-bíráló `spam.ai_judge`

Egy modell a technikai megállapítások és a tartalmi mérések alapján megbecsüli, hogyan kezelné az üzenetet egy modern gépi tanulási szűrő. A tényeket látja, nem az üzenettörzs szövegét.

Ha sikertelen: Önmagában csak részlet. A becslése bekerül az alábbi összesített eredménybe.

Csak tájékoztatásul jelenik meg. Soha nem befolyásolja a pontszámot.

Összesített eredmény `spam.panel`

Egyetlen szám a választ adó motoroktól, úgy súlyozva, hogy a leghatározottabb eredményt ne lehessen egyszerűen kiátlagolni. A SpamAssassin és a Postmark egyetlen szavazatnak számít, mert közös szabálybázist használnak.

Ha sikertelen: Haladjon végig az egyes megállapításokon. Ez a sor akkor változik, amikor azok változnak.

Levonás: legfeljebb 25 pont a 100-ból a saját pontszámunkban.

How this score is calculated

Postmark SpamCheck `spam.postmark`

Egy harmadik vélemény, alapértelmezés szerint kikapcsolva. A végpontja a teljes üzenetet fogadja, és annak egyetlen részét sem tudjuk kitakarni anélkül, hogy tönkretennénk a mérést, ezért a bekapcsolása annak elfogadását jelenti, hogy minden tesztelt üzenetet átmásolunk egy harmadik félhez.

Ha sikertelen: Nincs teendő. Ha ki van kapcsolva, az ellenőrzés ezt jelzi, ami nem ugyanaz, mint a sikeres eredmény.

Csak tájékoztatásul jelenik meg. Soha nem befolyásolja a pontszámot.

Rspamd `spam.rspamd`

Egy második, függetlenül fejlesztett szűrő. Elég gyakran nem ért egyet a SpamAssassin eredményével ahhoz, hogy érdemes legyen megkérdezni, ezért szerepel itt.

Ha sikertelen: Önmagában csak részlet. Ennek a motornak a véleménye az összesített eredménybe kerül, nem kap külön pontszámot.

Csak tájékoztatásul jelenik meg. Soha nem befolyásolja a pontszámot.

SpamAssassin `spam.spamassassin`

A klasszikus szabályalapú szűrő, amely továbbra is a legtöbb e-mail-tesztelő eszköz motorja. Minden aktiválódott szabály szerepel a súlyával együtt.

Ha sikertelen: Az összpontszám helyett az aktiválódott szabályokat nézze meg. A legtöbb könnyen megszüntethető, amint látható, mely szabályokról van szó.

Levonás: legfeljebb 3 pont a 10-ből a klasszikus pontszámban.

Apache SpamAssassin — rule documentation

Tartalom

Maga az üzenet: a szerkezete, a hivatkozásai, a képei és mindaz, amit egy szűrő megvizsgál a döntés előtt.

Képek alt szövege `content.alt_attributes`

Tartalmaznak-e a képek alt attribútumokat. A levelezőprogramok alapértelmezés szerint blokkolják a távoli képeket, ezért az első néhány másodpercben az alt szöveg közvetíti az üzenetet.

Ha sikertelen: Írjon a jelentést közvetítő alt szöveget, és soha ne hagyja enélkül a fő vizuális elemet.

Levonás: legfeljebb 4 pont a 100-ból a saját pontszámunkban és legfeljebb 0.5 pont a 10-ből a klasszikus pontszámban.

Hivatkozások elérhetősége `content.broken_links`

Azt vizsgálja, hogy a levélben lévő hivatkozások működnek-e. Egy hibás hivatkozás egy hírlevélben azonnal bizalomvesztést okoz, és a szűrők is észreveszik.

Ha sikertelen: Javítsa vagy távolítsa el őket. Ellenőrizze a követési domaint is: ha lejár, egyszerre minden hivatkozás elromlik.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban és legfeljebb 1 pont a 10-ből a klasszikus pontszámban.

Script és iframe `content.forbidden_tags`

Tartalmaz-e a HTML olyan címkéket, amelyeket egyetlen levelezőprogram sem futtat. A legjobb esetben eltávolítják őket, a legrosszabb esetben pedig a megkerülési kísérlet jeleként kezelik.

Ha sikertelen: Távolítsa el a script, iframe, object és embed elemeket. Minden interaktív tartalomnak egy hivatkozás mögött van a helye.

Levonás: legfeljebb 10 pont a 100-ból a saját pontszámunkban és legfeljebb 1 pont a 10-ből a klasszikus pontszámban.

RFC 2046 §5.1.4 — Alternative Subtype

A szöveg és a HTML aránya `content.html_text_ratio`

Mennyi jelölés található az üzenetben az olvasható szöveghez képest. Az egyetlen mondat köré épített, jelölésekkel teli oldal olyan forma, amelyet a szűrők felismernek.

Ha sikertelen: Olyan szöveges részt írjon, amely ugyanazt mondja, mint a HTML, ne helyőrzőt.

Levonás: legfeljebb 3 pont a 100-ból a saját pontszámunkban és legfeljebb 0.3 pont a 10-ből a klasszikus pontszámban.

Systems should recognize that the content of the various parts are interchangeable.

RFC 2046 §5.1.4 — Alternative Subtype

Szöveges és HTML-részek `content.html_version`

Tartalmaz-e az üzenet egyszerű szöveges alternatívát a HTML mellett. Egyes szűrők figyelembe veszik a hiányát, és minden képernyőolvasónak szüksége van rá.

Ha sikertelen: Küldjön multipart/alternative formátumot valódi szöveges verzióval, ne üres résszel vagy olyan sorral, amely azt mondja, hogy böngészőben tekintse meg.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban.

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

HTML-méret `content.html_weight`

Mekkora a HTML-rész. A Gmail nagyjából 102 KB felett levágja az üzenetet, a többit pedig egy hivatkozás mögé rejti, így a leiratkozási lábléc is eltűnik.

Ha sikertelen: Csökkentse a soron belüli CSS és az ismétlődő stílusblokkok mennyiségét (a legtöbb sablon belefér a korlát harmadába, miután eltávolította a nem használt szabályokat).

Levonás: legfeljebb 3 pont a 100-ból a saját pontszámunkban és legfeljebb 0.3 pont a 10-ből a klasszikus pontszámban.

Képek mérete `content.images_weight`

A levél által betöltött képek teljes mérete. A nagy méretű képek miatt a levél lassan töltődik be telefonon, a csak képekből álló leveleket pedig a szűrők gyanúsnak tekintik.

Ha sikertelen: Tömörítse őket, és győződjön meg arról, hogy a levél kikapcsolt képmegjelenítés mellett is olvasható.

Levonás: legfeljebb 3 pont a 100-ból a saját pontszámunkban és legfeljebb 0.3 pont a 10-ből a klasszikus pontszámban.

Látható hivatkozások céljai `content.link_mismatch`

Összehasonlítja a szövegben szereplő domaint a HTTP-átirányítások utáni céllal. Egy köztes követődomain önmagában nem bizonyít megtévesztést.

Ha sikertelen: Használja a céldomaint vagy leíró szöveget. Az elérhetetlen célok ellenőrizetlenek maradnak.

Levonás: legfeljebb 3 pont a 100-ból a saját pontszámunkban.

Hivatkozások megítélése `content.malicious_links`

Ellenőrzi az URL-eket a fenyegetési listákon. Egy találat nem jelenti, hogy minden címzett blokkolja az üzenetet.

Ha sikertelen: Vizsgálja meg a jelzett célokat, és cserélje le vagy távolítsa el a veszélyes linkeket. Egy régi bejegyzés nem bizonyít jelenlegi fertőzést.

Levonás: legfeljebb 40 pont a 100-ból a saját pontszámunkban.

Mellékletek ellenőrzése `content.malware`

Azt vizsgálja, hogy a mellékletek tartalmaznak-e ismert kártevőt. Azokon a telepítéseken, ahol az ellenőrző ki van kapcsolva, ez azt jelzi, hogy az ellenőrzés nem futott le, nem pedig azt, hogy a mellékletek tiszták.

Ha sikertelen: Ha ez riasztást ad, állítsa le a küldést, és derítse ki, mi található azon a gépen, amelyen a levél készült.

Levonás: legfeljebb 60 pont a 100-ból a saját pontszámunkban.

ClamAV — how detection works

Előnézeti szöveg `content.preheader`

Az előnézeti sor, amelyet a levelezőprogram a tárgy mellett jelenít meg. Enélkül azt jeleníti meg, ami elsőként szerepel a levéltörzsben, ez pedig általában a böngészőben való megtekintésre mutató hivatkozás.

Ha sikertelen: Adjon hozzá egy rejtett előnézeti szövegblokkot a levéltörzs első elemeként.

Levonás: legfeljebb 2 pont a 100-ból a saját pontszámunkban.

RFC 5322 §2.2 — Header Fields

Tárgysor `content.subject`

A hossz, a kis- és nagybetűk használata, valamint a szűrők által pontozott minták. A dekódolt tárgysort mérjük, így egy cirill vagy CJK tárgysort szövegként, nem pedig a kódolása alapján értékelünk.

Ha sikertelen: Tartsa körülbelül 60 karakter alatt, kerülje a csupa nagybetűs írást és a felkiáltójeleket.

Levonás: legfeljebb 3 pont a 100-ból a saját pontszámunkban.

Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

RFC 2047 §2 — Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar.

Rövidített hivatkozások `content.url_shortener`

Nyilvános rövidítőn keresztül vezetnek-e a hivatkozások. A rövidítők elrejtik a célhelyet, a szűrőket pedig pontosan arra tanították, hogy ezt gyanúsnak tekintsék.

Ha sikertelen: A saját domainjére hivatkozzon, vagy használja a platform követési domainjét a saját domainje egyik aldomainjén.

Levonás: legfeljebb 5 pont a 100-ból a saját pontszámunkban és legfeljebb 0.5 pont a 10-ből a klasszikus pontszámban.

RFC 9989 §4.7 — DMARC Policy Record Format

Tömeges feladók szabályai

A Gmail és a Yahoo által a nagy mennyiségben küldők számára közzétett követelmények. Ezek a körlevelekre vonatkoznak, és kimaradnak azoknál az üzeneteknél, amelyek nem tűnnek annak.

Közzétett DMARC-házirend `compliance.dmarc_present`

Közzétesz-e egyáltalán DMARC-rekordot a From tartománya, attól függetlenül, hogy ez az üzenet megfelelt-e neki. A Gmail és a Yahoo megköveteli ezt a tömeges feladóktól.

Ha sikertelen: Tegyen közzé egy rekordot. A p=none elegendő a követelmény teljesítéséhez, és feldolgozható jelentéseket biztosít.

Levonás: legfeljebb 6 pont a 100-ból a saját pontszámunkban.

If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none".

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

RFC 2369 §3.2 — List-Unsubscribe

List-Unsubscribe `compliance.list_unsubscribe`

Azt jelzi, hogy az üzenet tartalmaz-e olyan leiratkozási fejlécet, amelyet a levelezőprogram fel tud dolgozni. A Gmail és a Yahoo ezt megköveteli a tömeges feladóktól, a hiányát pedig minden mástól függetlenül szűrik. A szabály a körlevelekre vonatkozik. Az olyan levél, amely a címzettet egy feliratkozás megerősítésére kéri, vagy arról tájékoztatja, hogy a feliratkozás sikerült, egyetlen személynek szól olyasmiről, amit az imént tett; a CAN-SPAM ezt tranzakciós vagy kapcsolati üzenetnek nevezi, és sem a Gmail, sem a Yahoo nem követel meg hozzá leiratkozási fejlécet. Ezért ez az ellenőrzés először elolvassa a levelet. A lista fejlécei nélküli feliratkozás-megerősítés, üdvözlőlevél, tranzakciós levél vagy értesítés nem kap levonást, és a jelentés közli, hogy minek minősítette a levelet. Az ajánlatokkal kibővített üdvözlőlevél valójában a körlevél első kiadása; lista fejlécei nélkül az ellenőrzés nem tudja megkülönböztetni a kettőt, és feltételezés alapján nem ad levonást. Ha a levél List-Unsubscribe vagy List-Id fejlécet tartalmaz, Ön maga nyilvánította listás levélnek, és az ellenőrzés ugyanúgy lefut, mint eddig.

Ha sikertelen: Adjon hozzá egy HTTPS URI-t tartalmazó List-Unsubscribe fejlécet. Erre minden küldési platform képes.

Levonás: legfeljebb 10 pont a 100-ból a saját pontszámunkban és legfeljebb 1 pont a 10-ből a klasszikus pontszámban.

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

RFC 8058 §4 — Additional Requirements

Egykattintásos leiratkozás `compliance.one_click_unsubscribe`

A szigorúbb forma: egy HTTPS URI, egy „List-Unsubscribe-Post” fejléc és egyetlen érvényes DKIM-aláírás, amely mindkét fejlécet lefedi. Mindhárom szükséges, különben a fogadó nem jeleníti meg a gombot. A List-Unsubscribe ellenőrzéshez hasonlóan ez is a körlevelekre vonatkozik, nem a megerősítő vagy üdvözlőlevélre.

Ha sikertelen: A szokásos hiba az aláírás: a platformok aláírják a „List-Unsubscribe” fejlécet, de megfeledkeznek a „List-Unsubscribe-Post” fejlécről. Mindkét fejléc nevének szerepelnie kell ugyanazon aláírás h= címkéjében.

Levonás: legfeljebb 8 pont a 100-ból a saját pontszámunkban.

The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.

RFC 8058 §3.1 — Mail Senders

The List-Unsubscribe header field MUST contain one HTTPS URI.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day