On Tue, Mar 22, 2016 at 11:10:57AM +0100, Daniel Margolis wrote:
> Thanks for the feedback to both of you. I don't disagree; I think Viktor
> makes a very solid point in favor of simplicity. In addition, a report-only
> protocol could be extended to support arbitrary error reporting; an
> out-of-band (e.g. HTTP) channel to share delivery failures between domains
> strikes me as useful in the general case.
>
> Separately, because we're already assuming providers (both sending and
> receiving) make a choice on implementing DANE and/or webPKI, I don't think
> actually splitting the two makes it any more or less complex to implement,
> or should discourage adoption of one or the other mechanism.
>
> So I would say I'm feeling a bit in favor of Viktor's suggestion, but I'd
> like to chat a bit more with my co-authors and think about it first. ;)
Great. One more question. I see that there are parallel
non-overlapping threads on this proposal on tha UTA and IETF-SMTP
lists. Is either the "primary" forum for discussing this proposal?
Should people be encouraged to cross-post? Should the IETF-SMTP
users who want to discuss it be encouraged to shift the discussion
here?
> Viktor, as an aside regarding the hosted mail scenario, we already had the
> suggestion to move the HTTPS endpoint to something like "_
> smtp_sts.example.com/current". If we do that, the customer (example.com)
> can make this a CNAME for "_smtp_sts.hostingdomain.com", who can use SNI to
> serve the policy with the customer's cert (assuming the customer trusts the
> hosting provider with this; for domains that don't operate their own HTTPS
> endpoint this seems to me to be likely). For the more complex case, the
> cron setup you describe doesn't seem too onerous, I agree.
Prepending a fixed sub-domain label is fine as an extra bit of rope
to support various forms of indirection.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
