Re: What Meng said

Here's how I'm interpreting the practical implications of this, please 
tell me if I'm just misunderstanding you:
If I want my record  to be evaluated based on the PRA algorithm then I 
MUST use SUBMITTER
If I want my record to be evaluated based on MAIL FROM then I MUST NOT 
use SUBMITTER and my PRA MUST be the same as the MAIL FROM.
How does this work when the receiving side doesn't understand SUBMITTER?

Margaret.

On Aug 13, 2004, at 2:56 AM, Meng Weng Wong wrote:

> I agree with everything Mark says, so I must have
> communicated my position poorly :)
>
> If I could have one more chance to explain my thinking,
> let's cut to the chase:
>
> On Wed, Aug 11, 2004 at 02:38:38PM -0700, Mark Lentczner wrote:
> | else client supplies just Mail From {
> |     r2 = check MAIL FROM against its Sender-ID record (hoping it will
> | be same as PRA)
> |
> |     accept body of message
> |     extract PRA from headers
> |     if PRA == MAIL FROM { exit with r2 }
> |
> |     r3 = check PRA against its Sender-ID record
> |     exit with r3
> | }
>
> I agree that this is how Sender ID should work.
>
> My question is: can you reject if the r2 result is FAIL?
>
> I think you can.  Here's why.
>
> The forwarding scenario is, of course, our weak link.
>
> Under SPF Classic, noncompliant forwarders who didn't do SRS
> could expect to get their mail rejected.
>
> Under Sender ID, noncompliant forwarders who don't prepend a
> Resent-From header could expect to get their mail rejected.
>
> Under Sender ID, noncompliant forwarders who don't offer a
> SUBMITTER parameter could expect to get their mail rejected.
>
> In all cases, noncompliant forwarders get their mail
> rejected.
>
> Therefore, immediately rejecting after MAIL if (the
> SUBMITTER value is not provided and r2 is FAIL), is no worse
> than continuing to accept the message and extracting the
> PRA, because the PRA can be expected to fail anyway if it's
> forwarding.
>
> This means that we *can* safely assume,
> in the absence of SUBMITTER, that MAIL-FROM == PRA,
> whether or not we think the sender is omitting it because
> 1) they are not Sender-ID aware, or
> 2) they are aware and Mail-From == PRA.
>
> If we do this, then the essential requirements of the SPF
> Classic community are respected in Sender ID.
>
> I do not think this course of action harms the essential
> requirements of Caller ID so why not make both sides happy?
>
> Back to the algorithm:
>
> | else client supplies just Mail From {
> |     r2 = check MAIL FROM against its Sender-ID record (hoping it will
> | be same as PRA)
>
> so, if the r2 is FAIL, reject.  if the r2 is PASS, proceed.
>
> |     accept body of message
> |     extract PRA from headers
> |     if PRA == MAIL FROM { exit with r2 }
> |
> |     r3 = check PRA against its Sender-ID record
> |     exit with r3
> | }
>
> the important requirement for me is being able to, when
> SUBMITTER is absent, reject based on a MAIL FROM fail
> result, and being able to, when SUBMITTER is absent, accept
> based on a MAIL FROM pass result.
>
> If course if SUBMITTER is provided that overrides the
> return-path, but i really would like to be able to avoid
> going into the headers upon FAIL.
>
> If the result is a PASS then going into the headers is fine
> by me; we would then check that the PRA either matches the
> MAIL FROM or passes an SPF check directly.
>
> (non-SUBMITTER compliant VERP mailing lists with Sender:
> owner-listname are a good case where PRA != MAIL-FROM but
> spf_check(PRA) == PASS == spf_check(MAIL-FROM)).
>
> perhaps some data can tell whether such an algorithm would
> be more or less prone to error in the field.