On Fri, Apr 18, 2008 at 04:33:29PM -0400, Barry Leiba wrote:
Ned Freed said the following:
Very good point. We have existing users that depend on cascading
notifications,
so the way I had planned to implement this is to count auto-submitted
fields
and compare against a settable threshhold. The default for the threshhold
will
be 1 but operators will be able to set it higher if they choose.
There's a problem with that. RFC 3834 says this, at the end of section 5.1:
The maximum number of Auto-Submitted fields that may appear in a
message header is 1.
Ouch. So, Auto-Submitted really isn't a good field to use for loop
control. If a way to limit the number of cascades is needed (ignoring
for the moment the objection to cascading at all), perhaps some other
trace field could be added. It might be tempting to add another parameter
to the Auto-Submitted field, but you can't count on those being retained
or maintained.
We could update that here, but there's no reason to think that there
isn't already code out there that strips extra Auto-Submitted headers,
and there's every reason to think that setting the threshold > 1 would
expose one to problems.
right
I think it's a Bad Idea to send notifications about Auto-Submitted
messages. Redirect can do it, and redirect ought to be sticking
Resent-* headers in. Those headers are already defined in a way that
lets one count them.
I still disagree about that, if only for the meta-examples I gave before
about cascading notifications. But that's not all. If, for example, my
monitoring service sends me a message that the heat in my office is
above a certain threshold, this might be Auto-Submitted, yet I would
want to be able to get a notification of it, using the appropriate
language element to do so. I imagine other examples could flow easily.
I think you have to be careful with prohibitions, and I believe that
this one would practically guarantee that non-conforming implementations
will arise.
mm