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 — Define an SPF record

Google — Requirements for bulk senders (5,000+/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 7489 §3.1.2 — SPF-Authenticated Identifiers

In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.

RFC 7489 §6.6.2 — Determine Handling Policy

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

Google — Add a DMARC record

Google — Requirements for bulk senders (5,000+/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 — MX record values and troubleshooting

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 — Requirements for bulk senders (5,000+/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 — MX record values and troubleshooting

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 — Requirements for bulk senders (5,000+/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 — Require TLS for secure message transport

Google — Requirements for bulk senders (5,000+/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.

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

Azt vizsgálja, hogy szerepel-e valamelyik hivatkozás egy fenyegetéseket nyilvántartó adatforrásban. Egyetlen listázott hivatkozás is blokkolja a levelet, függetlenül attól, hogy minden más megfelelő-e.

Ha sikertelen: Távolítsa el. Ha a saját domainjéről van szó, akkor a rendszer kompromittálódását kell kezelnie, mielőtt bármi mást küldene.

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 7489 §6.3 — General 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.

p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records).

Google — Requirements for bulk senders (5,000+/day)

RFC 2369 §3.2 — List-Unsubscribe

List-Unsubscribe `compliance.list_unsubscribe`

Tartalmaz-e az üzenet olyan leiratkozási fejlécet, amelyet egy levelezőkliens használni tud. A Gmail és a Yahoo megköveteli ezt a tömeges feladóktól, és a hiánya minden mástól függetlenül szűrési tényező.

Ha sikertelen: Adjon hozzá egy List-Unsubscribe fejlécet HTTPS URI-val. 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 — Requirements for bulk senders (5,000+/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.

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 — Requirements for bulk senders (5,000+/day)