ietf-822
[Top] [All Lists]

Re: [2822upd] Resent-* MUSTard

2007-05-01 11:50:59


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.

Reread my statement. Nowhere did I say that SPF, or sender-id for that matter,
was incompatible with 2822. What I said was, rather, that due to the
experimental status of this proposals any incompatibility they present is not
our concern.

I'm not going to get into whether or not I actually regard SPF as an
incompatible mechanism with existing email standards because all it's going to
do is get us into an argument that's irrelevant to the matter at hand.

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.

Um, nonsense. It's easy to apply 2119 criteria to MUSTs or even SHOULDs since
they typically require some effort to implement. You look for multiple
interoperating implementations and if there aren't any out comes the feature.

MUST NOT and SHOULD NOT are another story. There are bound to be conforming
implementaqtions because it is almost always easier not to do something than to
do it and that leads to a form of compliance, vacuous though it may be. And all
examples of nonconfirming implementation do is show that a fair number of
people cannot write compliant code - what else is new?

The two ways to successfully challenge a MUST NOT or a SHOULD NOT would
be if you can show there were objections during the standardization
process that weren't given adequate consideration - the claim of consensus
for the feature is bogus, in other words. Or you can demonstrate that
the prohibition is for some reason a bad idea - such as if it creates
a serious security issue.

Regardless, the main point here is that it is not our job to provide a case to
support the inclusion of this facility, but rather it's your job to make a
convincing case that it should be removed.

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.

This was a comment about the results of Internet experiments in general, not a
comment on the likely or even possible outcomes of these experiments
specifically.

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.

It's just one example.

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@ ?

Why not? And I can think of many more examples, such as one coauthor
resending a review of their book.

The better example though is when the user has specified an alternate from as
part of their resending operation and the user agent wants to insert the user's
real email address.

Really, I
don't get it, who needs or uses this syntactical option ?  Why can't
we deprecate it in 2822bis ?

Because there are cases where it is useful and needed. Really, what I cannot
fathom is wanting to create an unnecessary and ugly asymmetry between original
field semantics in the sending and resending cases.

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 ?

That's sort of the point - the examples of this are anything but simple.
Email-based workflow applications exist that end up redirecting a single
message many times. Even if you believe it is OK to use MIME forwarding for
this (I don't - I think the semantics are wrong) you really should check and
see what happens when some user agents try and handle this sort of structure. 

If SIEVE processing uses Resent-*, doesn't it have a similar issue
with the MUST NOT in 2822 ?

Because there is no conflict. As Pete has pointed out, you appear not to
understand what the text is saying. Sieve redirect in particular causes
reintroduction of the message into the transport system and is NOT in any way
shape or form a reply, automatic or otherwise.

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).

I have already stated that I view the 4409 issue as a 4009 bug. As for DKIM
SSP, since it is not complete it is hard to say, but if there's a conflict the
right place to deal with it is with a separate activity after the problem has
been identified and fully characterized.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>