č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
- 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.
- 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
- K výsledku vyhledávání Whois je přidáno 5 výchozích aliasů v testované doméně. Výchozí aliasy jsou:
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
Další poznámky lze najít v CPS 4.2.2 Řízení ověření - Řízení domény
Nemohu přidat své doménové jméno pro CAcert (Doménové jméno neexistuje)
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)
- Má Vaše doména definován MX záznam?
- Má Vaše doména txt záznam SPF alespoň s uvedením mx?
- Například "v=spf1 mx ~all"
- Ukazuje Váš MX záznam na správně definovaný smtp server?
- Neběží na veřejném smtp serveru uvedeném v MX greylisting?
- Opakované odeslání e-mailu za 2 až 20 minut.
- 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
- 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"
- 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"
- Ukazuje Váš MX záznam na správně definovaný smtp server Outlook 365?
- 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
- Má Vaše doména definován MX záznam?
- Má Vaše doména txt záznam SPF alespoň s uvedením mx?
- Například "v=spf1 mx ~all"
- Ukazuje Váš MX záznam na správně definovaný smtp server?
- Má Váš e-mail server pevnou IP adresu ve veřejném Internetu?
- Je zpětný překlad této IP adresy opět názvem Vašeho e-mail serveru?
- 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.
- 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)
- 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.)
- Odpovídá jméno stroje uvedené ve Vaší konfiguraci MTA jménu stroje definovanému v záznamu MX Vaší domény?
- 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.
- 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
- 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.
- 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é