Re: What Meng said

Meng,

Please may I ask a brutally simple question.

I think it is generally agreed that where MAIL-FROM == PRA any decision is based
on the PRA.

My question below applies only to those messages in which the domain of the
MAIL-FROM is different from the domain of the PRA.

Where, in the collection of drafts issued on Friday, does Sender-ID refer to the
rejection of a message as a result of evaluating the record associated with its
MAIL-FROM domain?


Chris Haynes




At Friday, August 13, 2004 7:56 AM "Meng Weng Wong" said


> 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.