česky | english


Jak pracuje Ping test pro nový účet nebo novou doménu

(Ping test se používá i pro přidání nové e-mail adresy k již existujícímu účtu, viz zde.)

CAcert používá dvě metody vytvoření seznamu možných e-mailových adres pro odeslání testovacího ping e-mailu za účelem ověření domény:

Vytvoření seznamu e-mailových adres

  1. Vyhledání e-mailové adresy ve Whois
    • Vyhledávání e-mailových adres ve Whois prohledá databázi WhoIs na možné e-mailové adresy registrujícího se, tech-c (technický kontakt) a admin-c (administrativní/správní kontakt). Je-li nalezeno více e-mailových adres, budou sjednoceny.

  2. Výchozí sada e-mailových aliasů + testovaná doména
    • K výsledku vyhledávání Whois je přidáno 5 výchozích aliasů v testované doméně. Výchozí aliasy jsou:
      • root
      • hostmaster
      • postmaster
      • admin
      • webmaster
       Příklad:  testdomain.tld
      
       Whois testdomain.tld
         dá výsledek:   administrator@provider.tld
      
       Proto výsledný seznam, kam poslat testovací "ping" e-maily, bude:
      
        * administrator@provider.tld  -> adresa vyhledaná ve Whois
        * root@testdomain.tld         -> 1. výchozí alias
        * hostmaster@testdomain.tld   -> 2. výchozí alias 
        * postmaster@testdomain.tld   -> 3. výchozí alias
        * admin@testdomain.tld        -> 4. výchozí alias
        * webmaster@testdomain.tld    -> 5. výchozí alias

Uživatelův výběr jedné e-mailové adresy, kam bude odeslán testovací e-mail ("ping")

Aspoň jedna z výše uvedených e-mailových adres musí už být aktivována, aby ping e-mail uspěl a doména byla ověřena. To znamená: internetová brána MTA (záznam MX nebo záznam A pro doménu) musí ping e-mail přijmout, takže zvolený e-mailový alias (alespoň postmaster) musí být v dobrém funkčním stavu a aktivní podle internetových principů [Requests for Comments, RFC]).

Uživatel si nyní musí vybrat jednu z těchto e-mailových adres vytvořených systémem, kterou použije, aby vrátil testovací ping e-mail systému CAcert.

Další informace

Typické konfigurační problémy u příjemce Ping testu

Nedostal jsem potvrzující e-mail a používám veřejný e-mailový server

(Například seznam.cz, outlook.com, gmail.com, volny.cz)

  1. Má Vaše doména definován MX záznam?
  2. Má Vaše doména txt záznam SPF alespoň s uvedením mx?
    • Například "v=spf1 mx ~all"
  3. Ukazuje Váš MX záznam na správně definovaný smtp server?
  4. Neběží na veřejném smtp serveru uvedeném v MX greylisting?
    • Opakované odeslání e-mailu za 2 až 20 minut.
  5. Není greylisting veřejného e-mail serveru konfigurován na chybný kód odpovědi 5.x.x namísto 4.x.x?
    • Greylisting musí odpovědět smtp kódem 4.x.x (momentálně nejsem dostupný, opakujte později)

(Ostatní body 6-13 uvedené níže řeší majitel veřejného serveru, na nějž musíte správně odkázat.)

Nedostal jsem potvrzující e-mail a používám cloudové řešení MS Office 365 Outlook

  1. Má Vaše doména definován MX záznam pro Outlook 365?
    • Například "<vašedoména.TLD> MX preference = 10, mail exchanger = <vašedoména-TLD>.mail.protection.outlook.com"

  2. Má Vaše doména txt záznam SPF s uvedením include pro Outlook 365?
    • Například "v=spf1 ip4:<Vaše pevná IPv4-adresa v Internetu> include:spf.protection.outlook.com -all"

  3. Ukazuje Váš MX záznam na správně definovaný smtp server Outlook 365?
  4. Neběží na smtp serveru Outlook 365 uvedeném v MX greylisting?
    • Opakované odeslání e-mailu za 2 až 20 minut.

(Ostatní body 5-13 uvedené dále řeší Microsoft.)

Nedostal jsem potvrzující e-mail a mám vlastní e-mailový server

  1. Má Vaše doména definován MX záznam?
  2. Má Vaše doména txt záznam SPF alespoň s uvedením mx?
    • Například "v=spf1 mx ~all"
  3. Ukazuje Váš MX záznam na správně definovaný smtp server?
  4. Má Váš e-mail server pevnou IP adresu ve veřejném Internetu?
  5. Je zpětný překlad této IP adresy opět názvem Vašeho e-mail serveru?
  6. Neběží na Vašem smtp serveru uvedeném v MX greylisting?
    • Opakované odeslání e-mailu za 2 až 5 minut, v závislosti na intervalu opakování nastaveném na Vašem e-mail serveru.
  7. Není greylisting na Vašem e-mail serveru konfigurován na chybný kód odpovědi 5.x.x namísto 4.x.x?
    • Greylisting musí odpovědět smtp kódem 4.x.x (momentálně nejsem dostupný, opakujte později)
  8. Zkontroloval(a) jste jméno stroje v MTA (Mail Transfer Agent, přenos zpráv protokolem SMTP) na svém e-mail serveru? (Tj. v SMTP protokolu se musí Váš e-mail server správně ohlásit.)
  9. Odpovídá jméno stroje uvedené ve Vaší konfiguraci MTA jménu stroje definovanému v záznamu MX Vaší domény?
  10. Je zvolený e-mailový alias konfigurován podle konfigurace Vašeho MTA? a/nebo je alias pro návraty definován v konfiguraci Vašeho MTA jako přijatelný příjemce?
    • Řešení zacyklených vracejících se e-mailů

       Příklad:  yoursubdomain.testdomain.tld
      
       Whois yoursubdomain.testdomain.tld odkazuje na Whois testdomain.tld
         výsledek: administrator@provider.tld
         administrator@provider.tld není Vaše volba
      
       Takže zde je výsledný seznam adres, kam budou odeslány testovací ping e-maily:
      
        * root@yoursubdomain.testdomain.tld         -> 1. výchozí alias
        * hostmaster@yoursubdomain.testdomain.tld   -> 2. výchozí alias 
        * postmaster@yoursubdomain.testdomain.tld   -> 3. výchozí alias
        * admin@yoursubdomain.testdomain.tld        -> 4. výchozí alias
        * webmaster@yoursubdomain.testdomain.tld    -> 5. výchozí alias
      
        kde je individuální záznam MX nastaven na yoursubdomain.testdomain.tld
      
        Jiný e-mailový alias nefunguje.
      
        Řešení: Vytvořte e-mailový alias z výše uvedeného seznamu.
  11. Existuje záznam Whois pro Vaši doménu, o kterou jde?
    • Standardně neexistují vlastní záznamy Whois pro subdomény.
    • Pak je Váš výběr omezen na seznam aliasů 5 "známých" doménových jmen (viz výše)
       Příklad:  yoursubdomain.testdomain.tld
      
       Whois yoursubdomain.testdomain.tld  odkazuje na Whois testdomain.tld
         dá výsledek:   administrator@provider.tld
      
       Takže výsledný seznam adres, kam odeslat testovací pong e-maily, bude:
      
        * administrator@provider.tld                -> adresa vyhledaná ve Whois
        * root@yoursubdomain.testdomain.tld         -> 1. výchozí alias
        * hostmaster@yoursubdomain.testdomain.tld   -> 2. výchozí alias 
        * postmaster@yoursubdomain.testdomain.tld   -> 3. výchozí alias
        * admin@yoursubdomain.testdomain.tld        -> 4. výchozí alias
        * webmaster@yoursubdomain.testdomain.tld    -> 5. výchozí alias
      
        kde je individuální záznam MX nastaven na yoursubdomain.testdomain.tld
  12. Má Váš DNS link-lokální adresu IPv6? [link = spojení, kde není třeba routovat, například LAN]
    • domain.tld má adresu <a.b.c.d> (IPv4)

    • domain.tld má IPv6 adresu "fe80::224:21ff:fe21:aad5" (link-lokální)
    • ("fe80:…"), která je obdobná adrese IPv4 localhost (127.0.0.1). Tuto adresu nelze routovat.
    • CAcert používá IPv6 a nemůže dosáhnout na link-lokální adresu IPv6.
    • přibývá hlášení o problémech s chybně konfigurovanými definicemi ipv6 dns
      • hlášení chyby: "Failed to make a connection to the mail server" (Nezdařilo se spojit se serverem el. pošty)
      • nasnadě je "buď opravte nebo vypněte ipv6"
        • (ze zprávy uživatele) Toto vypadá jako problém; stop a restart interface vyřešil problém, nyní musím především zjistit, proč moje nastavení IPv6 selhalo.
    • Položte si otázku: mám v nastavení svého DNS konfigurován protokol IPv6?
    • Pokud je odpověď ANO, důkladně zkontrolujte nastavení IPv6 nebo postupujte podle předchozího návrhu.
  13. Používáte DNSSEC?
    • Jeden známý problém:
    • Je-li doména uvedena na úrovni registrace jako zabezpečená pomocí DNSSEC, avšak v zónovém souboru samotné domény není obsažen požadovaný klíč(-e), pak pomocí takového resolveru s podporou DNSSEC, jaký používáme v CAcert, je taková doména zcela nedostupná, a to z dobrého důvodu: DNSSEC klasifikuje takto chybně konfigurovanou (nebo i hacknutou?) doménu jako podvrženou.
    • Nepoužíváte-li Vy sami resolver DNSSSEC, nezjistíte žádnou chybu. Pouze testováním domény službou jako je http://dnscheck.sidn.nl/ tento specifický problém zjistíte.

Použití TLS 1.2 pro Ping e-mail

Od února 2019 instaloval CAcert pro Ping e-mail bezpečnostní protokol přenosu TLS 1.2 (RFC 5246), který umožňuje zřídit šifrované spojení pro přenos zpráv protokolem SMTP. Šifrované spojení lze úspěšně vybudovat, pokud příjemcův e-mailový server umí rovněž pracovat protokolem TLS 1.2 (dnes všechny veřejné e-mailové servery). TLS 1.2 nemá tak striktní požadavky na protistranu jako předchozí verze TLS, a tak Ping e-mail projde, i když třeba příjemcův server už nepřijímá nezabezpečené spojení. Rovněž odpadá striktní kontrola "obecné známosti" CA vydavatelů certifikátů na obou stranách přenosu.

Viz také


FAQ/HowThePingTestWorks/CZ (last edited 2019-03-06 11:02:24 by AlesKastner)