[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [2822upd] Resent-* MUSTard
> Hi, the following paragraphs in 2822upd-01 are incompatible with
> RFC 4406:
> RFC 4406 uses Resent-* in "automatic actions on messages", both for
> redistribution (mailing lists) and redirection (alias forwarding to 3rd
> parties). RFC 4407 uses Resent-* not only for "strictly informational"
> purposes, it evaluates Resent-* to determine the "PRA" (its "purported
> responsible address"). RFC 4405 uses this "PRA" in an SMTP extension.
> This incompatibility was approved in an appeal.
What was approved was the publication of *experimental* documents which state
that they are incompatible with exsiting standards in the area. (See the IESG
notes in RFC 4406 and 4408.) It is in no way incumbent on this effort to change
2822bis to be compatible with either of these experiments, especially since the
two experiments are incompatible with each other!
> For various technical
> reasons I think that the "PRA" is an excessively poor emulation of the
> Return-Path, and that it's stupid to introduce an entity like the "PRA"
> at this point in time shortly after RFC 3834 closed the last loophole
> where mailbots still sent auto-responses to other addresses: Almost
> all auto-responses are now based on the Return-Path, NDRs, DSNs, MDNs,
> it makes no sense to introduce a new "PRA" sometimes resulting in the
> Sender-address which should never be used for auto-responses.
> BUT. But while I hate the "PRA" it is not for the formal reason that
> it is incompatible with 2822. In fact I think 2822upd should fix this
Then you need to make a very compelling argument for the change that doesn't
depend in any way on the fact these experiments were published. Experiments,
formal or otherwise, come and go. A select few result in significant change,
many pass by largely unnoticed, and some evaporate leaving only a very bad
It would be nothing short of utter folly to base the development of standards
on the publication of intentionally incompatible experimental documents. It
might arguably make sense to alter tnings based on the *outcome* of an
experiment, but probably not as part of what's supposed to be a simple document
On a side note, the main reason I opposed the publication of these experiments
is because they did not even consider the issue of how to assess their own
results. Had this issue been considered I don't see how the inherent semantic
conflists between the two could have been allowed to stand.
> For starters anything wishing to go to "draft standard" will
> have to show in its "implementation and interoperability report" why
> there is a weird construct like the Resent-Sender at all:
> Who needs a Resent-Sender ?
Resent-sender exists for the same reason Sender: does. I see nothing that would
prevent a resending operation from involving multiple authoring parties with
one distinghished reponsible party.
> Who implements it ?
We have done so for years. In fact our usage of resent- fields in general
(although not resent-sender specifically) has actually increased of late
because of the desire of several sites to be able to track and audit user-level
message redirection in things like sieve filters. This is definitely not
something you want to do with nested MIME structure.
> Why is the complete
> Resent-nightmare not supported in RFC 4409 8.1 "may add sender" ?
I actually see this as more of a a bug in RFC 4409 than anything else.
> is there more than one Resent-* block incompatible with RFC 821, and
> resulting in yet another incompatibility with RFC 4407 ? Why can't we
> deprecate this rubbish in favour of the much clearer MIME forwarding ?
I would have been willing to entertain doing that as part of the DRUMS effort,
but removing a fairly significant facility as part of this late-stage cleanup
exercise strikes me as quite a bit more than we're really supposed to be doing
but regardless of my own take on the resent- issue, any case for this sort of
change needs to be made on its own merit. It cannot be based on name-calling
and incompatilbity with experimental documents which were known at the time
they were approved to be at odds with both existing email infrastructure and