On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> 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. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc