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.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com