On Fri, Dec 12, 2014 at 11:09:53AM +1100, Mark Andrews wrote:
> We could just do this correctly and use SRV records to point to
> keyserver servers running over TLS. The keyserver can do whatever
> local canonicalisations that are required. The SMTP server could
> even be performing this role on a different port. That way you
> only have to enter the canonicalisation rules once.
>
> This also gets rid of the complaints about being able to walk the
> zone.
Since this is the DANE working group, those would be DANE TLSA
authenticated servers, designated via a suitable SRV record.
The presence of the SRV record itself would signal adoption of the
protocol by the domain.
However, this makes the protocol much more complex. Mail clients
that just do local submission and did not need a TLS stack, would
now need to implement HTTPS, and we'd end-up defining a rather
complex protocol layered over that.
DNS does scale better.
If we're really going to do this as a direct query to the remote
domain (and not a DNSSEC lookup), perhaps the right application
protocol is some sort of minimal SMTP over SSL on a port indicated
by the SRV record:
<tcp connect>
C/S: <TLS handshake>
C: SMIMEA "Frank.Jr."@example.com
S: 250-3 1 1 <blob1>
S: 250 3 1 2 <blob2>
<TCP disconnect>
HTTP seems like much too much baggage, and the above could actually
be an additional service operated as part of the MTA, (the email
administrator would not need to be either a DNS administrator or
a webmaster). The SMTP server would know how/whether to case-fold
the address.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
