On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy <[email protected]> wrote:
> On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < > [email protected]> wrote: > > >> But when somebody gets around to trying to exploit this window, sites >> with quick (re-)delivery to most of their recipients will probably want to >> cut the length of that exposure down... >> >> >> which effectively kills the SMTP retry strategy concept [1] and hence the >> store-and-forward character of Internet mail, as we know it since the late >> 70's. Please note that SMTP itself has per command timeouts [2] which make >> short t= limits in the order of sub-minutes or some minutes unrealistic for >> some parts of the Internet and for delivery to some organizations which now >> and then have outages of more than a few minutes (no monitoring, no staff >> etc.). Also, note that large mailing lists may take some time to expand the >> address list and deliver the mail to all recipients... So when an >> expiration time is chosen it has to match the real world of mail delivery, >> which is far better than 20 years ago, but still isn't perfect... >> > > To your first point: SMTP itself isn't being altered by these proposals in > any way that I can see. We're not changing the parts of SMTP you > referenced. For one thing, if a DMARC rejection is undertaken by a > receiver, that action is final; there's no retry going to happen. For > another, we're not influencing which host is being selected or what the > retry interval might be, or how long a queued message should be held before > ultimately being returned as undeliverable. If DMARC recommended 4yz SMTP > replies when failures happen, that might be different, but that's not the > case here. All of this can be thought of as happening in a layer above > SMTP, not as part of it. > > To your second point: Those timeouts recommended by SMTP should at least > be referenced by any advice a conditional signatures draft might provide in > terms of selecting an expiration time. Such a section would also be wise > to talk about header field selection and the like. More generally, any > advice we can provide about what to consider when selecting the > construction of the conditional signature would be wise to include. > 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). -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
