----- Original Message ----- > From: "Murray S. Kucherawy" <[email protected]> > To: "<[email protected]>" <[email protected]> > Cc: "Steven M Jones" <[email protected]>, [email protected] > Sent: Wednesday, May 20, 2015 12:56:31 AM > Subject: Re: [dmarc-ietf] Looking for degrees of freedom with > Intermediaries - Effort and Policy
> 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. > No, I understand and that's not what I said. > > For one thing, if a DMARC rejection is undertaken by a receiver, > > that > > action is final; there's no retry going to happen. > Correct. But DMARC rejection is only the final part of the chain (at least, when we talk about the transfer of messages from one ADMD boundary, via an intermediary ADMD or directly, to a receiver ADMD). If you write out all the actions that are required to get a mail from A to B, then you'll get an impressive list of situations where something can go wrong and which in turn can delay the delivery of the message to the receiving ADMD. > > 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. > Correct, but we must take into account that there are retry intervals being used by MTA's along the line between author domain and receiver domain. > > 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). I'm afraid you missed my point (or better said: obviously I didn't make myself clear :-)). What I want to say is: we have an existing Internet mail infrastructure where delivery times can range from seconds to many hours. With 'delivery time' I mean the time between the author domain DKIM signs the message and the time that the verifier domain checks the DKIM signature (not just between author domain and intermediary domain nor just between intermediary domain and verifier domain). Maybe we should call this 'message transfer time', not delivery time. If we try to solve the 'Mediator problem' by assuming that we can set very short expiration times on the signatures (to prevent replay) we seem to forget that this may lead to the rejection of a non-negligible amount of legitimate mail due to the nature of the Internet mail ecosystem as it is today. /rolf
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
