On Wed, 3 Nov 2004, Michael Thomas wrote:
Dave Crocker writes:
> > Speaking of deployability, can you please explain how the hopwise
> > solution that you are advocating doesn't run afoul of the PRA IPR?
> > I don't understand how the responsible party search that you're
> > advocating is in any way different than the MARID PRA and that
> > known roadblock to deployment.
>
> hopwise?
>
> The mechanism works between the rfc2822 originator and the rfc2821
> rcpt-to.
> That is not usually called 'hopwise'. That is usually called
> end-to-end.
End-End is from original Sender to Recepient so if I'm a sender and my
email goes to mail list and then to you, then end-end is from me to you.
But PRA is from one hop to another and not end-end as Michael Thomas
properly noted. We do not want repeat of PRA with cryptographic system
that can also only work from one hop to another (in that case somethingas
simple as SPF and CSV that authenticates by IP would work better).
A mailing list is a hop. It is not a final desitination.
I agree. To me a "hop" is one email session transmission from my server to
mail list or from mail list to end recepient, etc.
> As for its relationship to any claimed IPR, feel free to cite specific
> language of specific claims that you think this impacts. Beyond
> trying to respond to such specifics, I would prefer to conduct an
> engineering discussion, rather than a legal one.
What wasn't clear about what I wrote? Would what you're
advocating require something that is, or looks greatly like
the patent-pending PRA algorithm? If not, what is that
algorithm? IIM searches From, Sender which is decidedly not
the PRA algorithm.
I have reservations about people calling any algorithm that relies on
Resent-Sender, Resent-From, Sender, From to be PRA. The thing about it
is that if resending (by end user action as new email as specified in
RFC2822) really did occur then that last sender may well choose to use
Resent-Sender and Resent-From fields to indicate where the email is
coming from and so when deciding who the real sender of email message was
we have to account for it and not just for Sender and From headers.
So while Microsoft was correct about which headers are to be used in
deciding original sender of the email, what they did is try to monopolize
this algorithm (which was quite clear from RFC2822) and decided to reuse
the Resent- headers in different way that was not originally intended.
In original RFC2822 sense Resent-* headers are added by the sender when
initiating new transmission so it can only be viewed as "origin" in the
end-end model but Microsoft wanted to reuse it and have these headers
added for email email forwarding/redirection hop so they become only
indication of previous hop and that is what PRA is really about.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net