Re: PRA algorithm and use of non-standard header fields

On Jul 19, 2004, at 4:05 PM, Roy Badami wrote:
> I don't see the PRA algorithm as some heuristic to try and construct
> some new kind of identity from the headers; the PRA is a natural
> concept that falls out of the headers defined by 822.  If you want to
> know who (according to the headers) sent you a message, would you do
> anything substantially different from what the PRA algorithm
> specifies?
Well, when Caller-ID was first presented to me, it was presented as a 
heuristic.  And later evolutions of the algorithm seemed to get even 
more based on heuristics.  I was told that the X-Envelope, etc... 
things were added as they bettered some score on a test of "typical 
mail".
However, I agree with you that the current form attempts to encapsulate 
some notion of "who sent you this mail", as claimed by the headers.  
Alas, any such definition comes up against two problems: 1) RFC 2822 
doesn't talk in those terms, so we must infer, and 2) Current wide 
spread usage may or may not conform.
For example, RFC 2822 says "Resent fields are used to identify a 
message as having been reintroduced into the transport system by a 
user." -- and yet none of the mailing lists I use, which seem to be 
doing precisely this, add such headers.  Nor do any of my mailers when 
I choose "Forward".  So, practice and RFC are in conflict.  When, in 
practice, are these fields added?  Almost none of the mail I scanned 
had them.  On the other hand, wide spread use of a PRA check will 
probably cause wider use of the headers, in situations which may or may 
not be warranted.
On the other hand, RFC 2822 says "Resent fields are strictly 
informational.  They MUST NOT be used in the normal processing of 
replies or other such automatic actions on messages."  So, while it 
might represent who re-injected the mail, the user is to treat the mail 
as coming from the Sender:/From: addresses.  Hence, perhaps that is the 
identity that should be checked.  I have seen it requested that MUAs 
should change to show the PRA address to users as the sender of the 
e-mail, but that would seem to be in direct opposition to RFC 2822's 
intent of these headers.  Though I'm sure this is open to 
interpretation.
I point this out not because I have a strong feeling one way or the 
other, but because I think it should be clear that we are going to have 
to interpret 2822 and make some choices, and this will result in 
changes in practice.  Hence, I think it is reasonable to investigate, 
via both technical arguments and statistics, how well these ideas work.
> If we're going to use a header identity rather than the envelope
> identity, then the PRA is the only obvious identity to use; I've
> believed that since before Caller ID was proposed, and I have yet to
> see anyone make a convincing argument for any other header identity.
See above for perhaps why just Sender:/From: could be argued for.

> An IP-based authentication scheme obviously needs to look at who
> actually sent the message, not on whose behalf it was sent (that
> implies using Sender in preference to From).
Well, to the end user this may not be so clear.  Because of the 
fractured nature of the mail identities (who gets bounces, who 
injected, who will get replies, who the user will see as the sender, 
etc...), there are several options for what you might want to check.  
The IP address isn't necessarily tied only to the concept of who 
injected it.  This is because the IP that injected the mail is in 
control of (can forge) any of those other identities.  So an IP-base 
authentication scheme is essentially asking a domain "Is this IP 
authorized to inject mail with your domain name in the following 
identity?".  I can see how a reasonable argument could be made for any 
of those identities.  As an end user I might even want them all 
checked, and flagged when I try to base actions upon them.
> If we're going to spend time on the PRA, I think we should be
> analysing it semantically, not statistically.
If the semantics of mail identity were clear cut, and common practice 
generally compliant, I'd agree.  Alas, neither of these are true.  I 
think both semantics and statistics (testing with real world data) will 
have to come into play.
> (This complaint is in no way directed at Mark or any other specific
> contributors to this thread, but to the WG as a whole.)
No offense taken, and hopefully none given.

I also don't want others to take this as a position against PRA.  PRA 
is a fine identity to check.   As we come closer to some consensus on 
PRA, and as we fine tune it, I want express how I view this check as a 
guide to how we might refine it.
        - Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
markl(_at_)glyphic(_dot_)com