Subject: RE: TECH-OMISSION:Submitter concept should be expanded to include Peristent User Accounts (PUA)

From: "Harry Katz" <[email-masked]>
Date: Tue, 7 Sep 2004 17:23:52 -0700

On Thursday, September 02, 2004 9:02 AM, Scott Kitterman wrote:

[snip]
> 3.  Explicitly add a third possible source for submitter, the 
> Persistent User Account (PUA).  This would allow providers of 
> shared MTA services to add as a submitter the local (to the 
> shared MTA) e-mail address of the user that submitted the 
> message to the MTA.  This was discussed on the list in July.  
> Here is the start of the thread:
> 
> http://www.imc.org/ietf-mxcomp/mail-archive/msg02633.html
> 
> This would seem to be a much simpler solution for shared MTA 
> providers to implement than trying to determine which domains 
> their customers are authorized to send from.  It also gives a 
> full address (no just a domain) that has agreed to be 
> responsible for the message.  Also, if Submitter failed a 
> check during 2821 checking, I believe the message could be 
> rejected before data.
> 
> This approach is hinted at in the examples (see the last 
> paragraph of Page 7), but use in this manner is never 
> described in the actual specification.
> The reason I was thinking this might be a DOC-BUG is that 
> examples shouldn't introduce new functionality.

My apologies for the delay in responding.  

In looking at this suggestion carefully, I'm inclined to leave the spec
"as is" but to strengthen the wording of Example 5.3 to more clearly
illustrate its use in this case.  My reasons are that today PRA clearly
tied to identities carried in the RFC 2822 message headers.  I think
it's important to keep it that way.  Among other things this permits
validation by the receiving server that the sender hasn't lied about the
SUBMITTER value.  

Also, since there are a variety of possible behaviors by ISPs in this
situation, I think it's important to allow them flexibility.  

Lastly, I think the method of Example 5.3 is a good way of addressing
the scenario you've raised without requiring changes to the normative
portion of the spec.