Re: consensus call on pra/mailfrom deployment and versioning/scope

[Douglas Otis <dotis@xxxxxxxxxxxxxx>]

On Wed, 2004-09-08 at 12:20, Yakov Shafranovich wrote:
> Douglas Otis wrote:
> > On Wed, 2004-09-08 at 11:19, Yakov Shafranovich wrote:
> >> Jim Fenton wrote:
> >>> At 11:45 AM 9/8/2004 -0400, Meng Weng Wong wrote:
> >>>
> >>>> Step 2: HELO bob.mta MAIL FROM:<alice> SUBMITTER=<bob> RCPT
> >>>> TO:<robert> DATA Resent-From: <bob>
> >>>>
> >>>> At step 2, the receiver can apply spf/HELO tests (or SPF Lite or
> >>>> CSV or even IP based whitelisting) to bob.mta, and approve the
> >>>> forwarder based on that.
> >>>>
> >>>> The receiver can also apply spf/SUBMITTER tests to <bob>, and
> >>>> approve the forwarder based on that.
> >>>
> >>> Wouldn't this require a PRA check to verify that SUBMITTER is
> >>> consistent with the message headers, and wouldn't that be encumbered?
> >>
> >> No, SUBMITTER would be compared against the Sender-ID records directly 
> >> without touching the headers.
> > 
> > This means there would be no record which identity was used to permit
> > the message.  What an ideal way to spoof. 
> 
> Let me rephrase that: SUBMITTER would be compared against the Sender-ID 
> records directly without *examining* the headers.
> 
> You can still record the result of that and the parameter in some header.

This undefined header will also be spoofed.  Are you suggesting removal
of this header, if present, and insertion of a "X-Assumed PRA" header
depending upon whether the check has been made and whether the PRA
selection was assumed valid?

This becomes irrelevant should the MTA/Mailbox domain relationships be
viewed as nominal assertions against MAIL FROM and From mailbox domains
and the MTA authentication is an independent operation.  Where PRA plays
a role is equally accommodated by the EHLO name anyway.

-Doug