spf-discuss
[Top] [All Lists]

RE: moving on from MARID

2004-09-29 06:12:45
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Mark 
Shewmaker
Sent: Wednesday, September 29, 2004 5:47 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] moving on from MARID


On Wed, 2004-09-29 at 01:53, Mark wrote:

I largely agree. I would just re-arrange the order:

-------------------------------------------------------------------
HELO: (name lookup/CSV) Reject, no matter the results of other tests.
PRA: (SenderID/SUBMITTER) Reject, no matter the results of other tests.
MAIL FROM: (SES/CBV/SPF) Reject, no matter the results of other tests.
Content:  (DomainKeys) Reject, no matter the results of other tests.
-------------------------------------------------------------------

HELO, in the "new" philosophy, if I recall correctly, should
come first, to
offer a quick early-out.

I can agree with that, merely noting the minor complication concerning
the various helo verification methods of:

  CSV
  SPF-with-null-sender
  domain-name<->ip match

I would guess that HELO tests should be done in the above order,
skipping the last one if that were the local policy.

(Minor gripe:  Why couldn't the world have standardized on doing
domain-name<->ip-match checks on HELO years ago?  Minor hope:  Can we
naturally move toward this direction with csv and spf?)

I could do without PRA, but I like the use of a
stand-alone SUBMITTER. And since SUBMITTER (when present) is to take the
place of MAIL FROM, I believe SUBMITTER test should preceed MAIL FROM.

Just to verify, are you suggesting that MAIL FROM tests should be
skipped if there's a SUBMITTER?

I don't think you're saying that, but if you were, I'd disagree.

This is my reasoning:

MAIL FROM tests test the bounce-ability of the return-path, whereas
PRA/SUBMITTER tests verify that the latest entity claiming to be
submitting the mail into the mail stream is authenticated by the sending
domain's SenderID record as having permission to claim to do so.

But just because the PRA's sending domain's SenderID record says that
the PRA is allowed to claim to be (re)sent from that machine, that
doesn't imply that the bounce address is..err, bounceable.

So I would hope that even if SUBMITTER passes, that MAIL FROM tests
wouldn't be skipped.

I wanted to explicitly mention that again as Unified SPF has us giving a
PASS result if *any* test results in a PASS, something I disagree with.
(Or perhaps I just misunderstand.)

Generally folks have wanted to do both tests to get rid of the SenderID
bounce back problem--but I want to make sure that Unified won't be
removing any requirements to do all tests that the recipient would
normally make.  (Other than in short-cut fail cases of course.)

If you are going to reject the message based on MAIL FROM failing, what is
the point of checking for SUBMITTER.  Is there ever a case where MAIL FROM
would pass, but SUBMITTER should fail?  Is someone is trying to forge a 2822
identity and they can get MAIL FROM to pass, wouldn't they just omit
SUBMITTER?

I thought the major point of SUBMITTER was to allow forwarders to use it and
avoid having to rewrite MAIL FROM?  In your approach wouldn't they still
have to change MAIL FROM to get the message accepted?

Scott Kitterman