I'm reading Pete's answer right, then adding Resent-From is ok in some
forwarding cases but not in others and that in particular:
1. Its not ok with .forward forwarding (specifically mentioned). This
is very very common in the deployed base.
2. Its not ok with any forwarding where RFC2821 Mail From remains the same
as it was before forwarding (most of the forwarding systems deployed
on the net are like this)
3. Its not ok if message is changed (this would include Mail Lists).
If this is correct I see that most of the cases where marid-core recomends
adding Resent-From is incompabile with RFC2822. If that is so then SenderID
core algorithm has a fundamental technical error and current drafts should
not move forward and we should review our situation and look for alternative
technologies/algorithms that can meet our requirements.
On Fri, 17 Sep 2004, Pete Resnick wrote:
Sorry for my delay in responding. It's been one of those months.
(Maybe one of those quarters. *sigh*). I had a read through the DRUMS
archive (boy, was that unpleasant) and some personal mail on the
topic. Let me attempt to answer a few things. I don't know if this is
going to help:
1. Yes, the reason we called out "forwarding" as distinct from use of
the Resent-* fields was in part because 822 (and a good number of
people for many years) conflated "forwarding" with "redirecting" and
"resending" and a host of other labels. So we defined the two senses
of forwarding ((a) including a previous message in an entirely new
message and (b) relaying from the MTA level) and said that Resent-*
fields were not to be used in either case.
2. The use of .forward files is a horrible canonical example of
anything. The problem is that .forward files were historically
implemented using exactly the same MTA mechanism as alias files used
in relaying. In both of those cases, the original MAIL FROM was
preserved by the MTA and therefore was clearly not a case of
"delivered and then resent." I definitely had some discussion with
folks about whether or not Resent-* fields would be desirable in the
.forward case and we didn't come to a strong conclusion.
3. The fact of the matter is that historically .forward files did not
generate Resent-* and that's part of why we said not to put Resent-*
fields on forwarded messages. With all due deference to Jim, you do
*not* read IETF standards like a lawyer. IETF standards are, for most
intents and purposes, de facto standards: We are documenting what's
out there (or what we expect to be out there) so that everyone can do
it the same and interoperate well together, and we're trying to be as
precise as possible so that programmers can do what they need to do.
We're not trying to write laws that people should interpret as best
they can. We're trying to write down exactly what everyone is (and
should be) doing. Occasionally, we don't do as well as we'd like.
4. I don't think there is anything inconsistent with 2822 in
implementing an "automatic resend" function and putting Resent-*
fields on those messages. But in that case, I would expect the bounce
(MAIL FROM) address to be identical to the Resent-From/Resent-Sender
address and that the resender would be able to receive and act on
those bounces. Semantically, I see resending as making the *content*
of the message appear end-to-end from original sender to resent
recipient, but that has nothing to do with making the *transport* of
the message appear end-to-end between original sender and resent
recipient. MTA-level relaying makes the transport appear end-to-end
even though there is this "forwarding" step in the middle, and IMO
that shouldn't be using Resent-* fields.
My read is that the intent of SenderID is to eliminate all MTA-level
relaying and require it to be changed to automatic resending instead.
That may be OK, but understand that this is what you are doing.
Does that help?