On Sat, Nov 28, 2015 at 03:32:22PM +0000, Alexey Melnikov wrote: > > Some guidance on > > how to check/configure vanity domains may be appropriate, IMHO. > > If you can suggest some specific text, that would be great? Well, from vanity domains are not different from non-vanity domains. The choices are the same, vanity or not. >From the MUA's perspective, the domain to validate is typically the domainname of the explicitly configured servers (I've not seen much adoption of RFC6186, but perhaps I've not looked hard enough). In which case it is up to the domain owner and service operator to agree on suitable names for the IMAP/POP/SUBMISSION servers, and ensure that corresponding certificates are in place. In the brave new world of RFC6186, the new primary reference identifier is the appropriate SRV-ID based on the domainpart of the user's email address, with the DNS-ID for interoperability with current practice. The target servername from insecure DNS lookups is not automatically an acceptable reference identifier. RFC6186 suggests user confirmation, and we all know how well that typically works (yes, with a particularly attentive and knowledgeable user it can shorten the process of MUA account setup). For clients that support DNSSEC and perhaps DANE, using the target server name from RFC6186 SRV records becomes an option that may not require user confirmation. Once one trusts DNS for the reference ID, one may as well trust it for the certificate validity, at which point we're looking at essentially 7672 with s/MX/SRV/g. In any case, I don't see how "vanity" domains are particularly different. At present, in most cases the user will configure explit submission and imap (or POP) server names, and connections to these will employ PKI in the usual way. Some domain owners want the submission server name to stay in their own domain, so they can switch providers without having users update MUA settings. These are the most complex configurations, where RFC6186 might have helped, if only it were actually supported by MUAs and DNSSEC were more widely deployed. Instead we're left with the complexity of TLS virtual hosting with providers needing to field some sort of certificate (DNS-ID or SRV-ID) associated with each such domain. I don't know how workable that's turning out to be. The last bit complexity is in the vanity domain's SPF and DKIM records, so that the hosting provider's submission servers can originate mail for the vanity domain. -- Viktor.