On Tue, Aug 16, 2016 at 11:49:34AM +0200, Daniel Margolis wrote:
> I don't think this is incompatible with what you say. Refreshing doesn't
> have to be synchronous from the sending MTA's perspective; it just has to
> happen before the message is perm-failed. Your suggested implementation
> seems to be:
>
> 1. Temp fail the message.
IMNSHO, the draft should unequivocally recommend soft failure on
policy failure. Presumably policy failure is in most cases a
transient condition, that the receiving domain will attempt to
remediate as soon as they become aware of it. (Cue in-band
notification, :-)
> That has the same properties as the "synchronous" implementation. So I
> think we can change the language here, but I do think it's important that
> perm failures are not generated from stale policies.
See above, more generally, I would discourage perm failures on
policy failure. Persistent policy failure will result in eventual
message expiration. Many sending systems implement "delay warnings"
for internal senders, so that mail that's been in the queue for
some designated time results in a notice to the sender that their
mail is struggling to get through, and may indeed ultimately bounce.
> So in short, I think we can either (or both) a) *require* a check of the
> TXT record before send (totally reasonable) or b) require at least one
> check before a perm fail.
I read the current draft to require an HTTPS policy check on failure
even when the DNS TXT record showed no change. Perhaps I misunderstood.
I do think it makes sense to require a TXT record check on every
delivery, but mention that any consequent HTTPS policy fetch may
be asynchronous.
In the asynchronous case, the first few messages to a domain never
seen before, may be vulnerable to active attack. As they are
anyway, since the TXT record could well have also been suppressed.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
