RE: TECH-ERROR: SenderID sets recomendation for forwarders that are not compatible with RFC 2822

["william(at)elan.net" <william@xxxxxxxx>]

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?