[...] > > > > We also appear to be OK with imposing delivery timeouts > that extend > > beyond the basic timeout set described in RFC5321, given > what it says > > in RFC2852 (from 2000). > > Murray, > > Rolf has a valid point. You are advocating email is to > radically change into an instant messaging scheme. > > Are you now suggesting any properly functioning mediator > must process ALL its messages as they arrive rather than > permitting moderator approvals or any realistic post > processing overhead? > > Such issues often confronts small servers to produce > somewhat erratic handling delays. > > "Conditional" authorization expiry is wholly unrelated to > protocol timeouts. A message being queued does not normally > obtain a fresh set of signatures. If you are going to > justify short expiry using RFC5321, why ignore Section > 4.5.4.1 and Section 7.1? > > It is fairly common for a system to shutdown while being > patched whenever an active exploit is noticed. Undelivered > messages are then queued and retried later. Unreasonably > short expiry will once again make DMARC a primary cause for > message disruption whenever DMARC asserts inappropriate > handling requests.
Doug rephrased my concern about short expiry times quite well. Of course author domains are free to choose what expiry they want, but the question is: is it OK to design a(n extension to a) protocol which don't take the existing status quo of Internet mail into account? /rolf _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
