ned+ietf-822(_at_)mrochek(_dot_)com wrote:
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!
One of these experiments is strictly limited to SMTP, we can ignore
it here. I think it's a bit unfair to say that the other experiment
is incompatible with 2822, when 2822 gives no reason why there's an
offending MUST NOT about Resent-* in automatic processing.
I'm too lazy to dig through MARID jabber logs now, but IIRC the PRA
concept was discussed in presence of the 822 and 2822 editors among
others. It makes me wonder how important this MUST NOT is, and how
it's justified, I think there's nothing similar in 822.
In fact I think 2822upd should fix this issue.
Then you need to make a very compelling argument for the change
For the MUST NOT I'd like to know a compelling reason why it's there,
otherwise 2119 might suffice to remove unnecessary MUSTard.
some evaporate leaving only a very bad smell behind.
In the case of the PRA I'm curious if a part of its bad smell was
caused by an unnecessary / unclear / dubious / ... MUST NOT in 2822.
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 cleanup effort.
I'm not actively watching this experiment. But because it's as you
mentioned incompatible with the SMTP "experiment" it might be still
more than nothing when I note that I've so far not heard of practical
problems with its violation of the 2822 MUST NOT.
=== side note ===
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.
At some point "we" (SPF supporters) had to give up. We proposed PS,
that was rejected, we proposed IETF Last Call, that was rejected, we
appealed to the IESG, that didn't have the desired effect of removing
four letters resulting in the incompatibility, and we appealed to the
IAB, again no success wrt the four letters. And after that the last
theoretical option was refusing to publish the RFC because another
memo abused it, unsurprisingly there was no consensus to go that far.
Besides "do not publish" is a bad idea (admittedly I considered it).
=== back to 2822 ===
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.
I use MIME when I forward mails or news, not Resent-*, but even if
I'd use Resent-* I don't see why there could be multiple "authors"
in the case of resent mail. Is that a committee reading a mail
written by somebody else, collectively deciding to forward this
mail to a third party, with the names of all committee members in
the Resent-From, and the notorious Resent-Sender: secy@ ? Really, I
don't get it, who needs or uses this syntactical option ? Why can't
we deprecate it in 2822bis ?
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.
I'm not sure I get what you're saying, do you have a simple example ?
If SIEVE processing uses Resent-*, doesn't it have a similar issue
with the MUST NOT in 2822 ?
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.
Yes, I failed to convince John that this could be fixed in a 4409bis.
And he failed to convince me that it could be published as separate
RFC if I think it's important. My willingness to clean up the mess
caused by SenderID didn't go that far. I could be persuaded to try
it, after all it's less than one 69*62 page (without boilerplates).
Why 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 here.
Well, the SenderID RFCs aren't the only "victim" of this stuff, it's
also an obstacle for things like 4409 8.1, or (maybe) for DKIM SSP,
situations where folks try to do something interesting with mail
headers while ignoring SMTP envelopes (in the case of DKIM a design
decision).
Frank