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

Reply via email to