ietf-mxcomp
[Top] [All Lists]

Re: What Meng said

2004-08-15 11:38:45

Forgive me for suggesting a clarification to one of your assertions.

Your assertion

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

implies that Sender-ID contains a distinct process for evaluating MAIL-FROM (as
in SPF).

I believe this not to be the case.

In an off-list communication Mark Lentczner pointed out that:

"The MAIL-FROM domain check is only a speculative optimization.  If it doesn't
match PRA, it isn't used."

As I understand it, if there is no SUBMITTER, the domain of a MAIL-FROM is used
as the domain from which the record is extracted, but the way in which this
record is then processed is as if this were the PRA-derived domain.

When the PRA later becomes available, its domain is compared with that derived
from the MAIL-FROM.

If they are different, the record and any provisional test results derived from
the MAIL-FROM are discarded, and the record for the domain identified by the PRA
is now collected and tested.

In other words that is no sense in which any record is ever "evaluated based on
MAIL-FROM"; the tests / algorithms applied will always be those associated with
the PRA.

The optimization derived from using MAIL-FROM is the opportunity to fetch and
start testing the record, in the hope that, when the PRA is eventually
determined, the correct record is found to have been used.

No definitive tests are concluded at 2821-time, the information derived from
MAIL-FROM can never result in a decision at 2821-time to reject the message, so
the SMTP DATA phase and PRA establishment will always take place.



If the domain of MAIL-FROM is different from that of the PRA, its record has no
functional impact whatsoever on the evaluation of the message - which is, I
trust, a fair re-phrasing of Mark's observation.



If SUBMITTER is used, it is possible to reject some messages at 2821-time (see
section 4.2 of draft submitter-03.txt) and thereby save the bandwidth / time of
the DATA phase - so I can see no benefit whatsoever in a client deliberately
omitting the SUBMITTER when the receiver is prepared to accept it.



Chris Haynes




"Margaret Olson" asked on Saturday, August 14, 2004 10:39 PM:


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.








<Prev in Thread] Current Thread [Next in Thread>