Hi Harald,
On 01/12/2015 14:34, Harald Alvestrand wrote:
If I understand this draft correctly, I object.
It says:
2. When using email service discovery procedure specified in
[RFC6186] the client MUST also use the right hand side of the
email address as another "reference identifier" to compare
against SRV-ID identifier in the server certificate.
If I understand RFC 6186 correctly, a (possibly large scale) IMAP email
service provider that wishes to serve a new domain "example org"
according to RFC 6186 must do two things:
- Update internal tables of its servers with inforamation about that domain.
- Populate the DNS of the domain served with an _imap record.
If I understand this draft correctly, the server will have to do one
more thing:
- Change its certificate to include a complete list of all the domains
it is serving, and have its CA sign off on that certificate.
Yes, or alternatively, one can do one of two other things:
1) use Server Name Indication TLS extension. At the moment none of the
email specs requires it. But maybe it is something that the draft should
encourage.
2) run each domain on its own IP/port, then each IP/port can use
separate certificate with a single domain.
As Dave Cridland pointed out, POSH (RFC 7711) is trying to solve the
problem of hosting multiple domains, but its use is not defined for
email yet. I think it is out of scope for this document.
The reason it cannot provide one certificate per served domain is that
neither this specification nor any other specification I have found says
that the client MUST include any distinguishing information (such as a
Server Name Indication) that says what name it is expecting the server
to provide service for.
That is correct, see above.
Given the popularity of multi-domain mail servers (my own tiny little
mail servers has 9 domains it calls its own, some of which I do not wish
to advertise), I see this as a problem.
If I have misunderstood the issue, I apologize.
Best Regards,
Alexey