On Mon, 25 Oct 2004 08:16:42 -0700 (PDT), william(at)elan.net
<william(_at_)elan(_dot_)net> wrote:
On Mon, 25 Oct 2004, Michael Hammer wrote:
If this is the direction that we go then I would propose that the
order that scopes are tested should be the order in which they are
published in a record. A recipient MTA may choose to ignore a
particular scope but the order should not be changed.
That works great in this example:
EHLO example.com
MAIL FROM <user(_at_)example(_dot_)com>
With dns being:
example.com. SPF "v=spf1 sc=h,m mx ip4:192.168.0.0/16 -all"
Then when you see it you know the publisher wants ehlo checked first and
then mail from.
Now lets say that we have
EHLO bingo.example.com
MAIL FROM <user(_at_)example(_dot_)com>
With DNS being:
bingo.example.com. SPF "v=spf1 sc=h a -all"
example.com. SPF "v=spf1 sc=m mx ip4:192.168.0.0/16 -all"
So how do you decide if you need to check EHLO first or MAIL FROM ?
I would check EHLO first because that is the first thing I get in the
interaction with the client MTA. When I go back and check the record
for bingo.example.com I see what it specifies. If the EHLO check fails
I'm probably not going to go on to check anything else. If it passes I
now have MAIL FROM to evaluate and I check the record for example.com.
While many have said that the default (and most important if not only
check) should be MAILFROM (rfc2822), I can't think of a case where I
would have the MAILFROM information before I have the EHLO
information. This includes the case where the connecting MTA simply
provides an IP address instead of a FQDN. I have to admit that I
haven't played around to see which MTAs if any would accept a <> EHLO
(or something similar). I would hope not many/any.
I can't think of a valid reason that someone would specify evaluating
h after other scopes. It doesn't make sense. In that sense I don't see
an override being required for the example you gave.
I guess I'm thinking like a System Administrator (operations) rather
than a programmer. There's a certain natural progression in what is
available to evaluate so I expect a certain progression. When I said
that the recipient MTA could ignore a scope I was (and still am)
thinking that there is a natural (logical) order that people would
(should?) publish them. The fact that a particular scope doesn't get
evaluated (oh oh, the hotbutton PRA scope for example) is a different
issue from the order in which they are published.
I think overrides introduce an order of complexity that will only be
relevent/beneficial to a small fraction of domains in the possible
universe of domains. For this reason I would avoid going down that
path. Do we design for the rule or to the exception?
I'm also not comfortable with trying to evaluate on the basis of
combinations of scopes.
As usual, just my 2 cents.
Mike