On Thu, 2004-10-14 at 22:24, wayne wrote:
In
<1097806340(_dot_)21121(_dot_)63142(_dot_)camel(_at_)localhost(_dot_)localdomain>
Mark Shewmaker <mark(_at_)primefactor(_dot_)com> writes:
Since the whole point of SPF is to verify the bounce-ability of Return
Paths, and since by definition a Return Path pointing to a domain that
does not exist in any way cannot *ever* accept a bounce, I don't see the
objection to check_host() returning a "Fail" in that case.
Apparently many of you *don't* remember all the problems that this
language caused last time.
No I don't. I'm sorry to cause you grief.
I do remember it occurring, and I think I was even on your side of
things, considering it a type of layering violation, (good test, wrong
place), but..I seem to recall it being something I was wanting corrected
beforehand with the same urgency as a spelling correction, not something
I considered to negatively affect folks so much in practice.
(I didn't remember the issue about use-helo-on-null-mailfrom.)
First off, SPF is about preventing email forgery. It doesn't verify
the bounce-ability of the Return Path. This is simply wrong.
Okay, then let me rephrase to "SPF is about verifying the extent you
have been given an unforged bounce address that you can actually use."
This argument is sort of one based on definitions, and we really should
feel free to make subtle definition changes that make sense in context.
Secondly, verifying the Return Path to see if it the domain exists is
a perfectly valid thing to do *AS A DIFFERENT CHECK*. SPF shouldn't
be doing things like checking for MX records, or being on a DNSBL, or
whether the domain exists or not.
Checking DNSBL's requires check_host() to do additional checks. The
existence of domains is of necessity checked within check_host, so even
though it's somewhat of a layering violation to return Fail there
instead of in an outside non-spf test, I still consider it a useful
optimization that doesn't seem too objectionable.
Thirdly, our moral authority to decide whether whether an IP address
is authorized to send email using a domain *rests* on the basis of the
domain owner telling us so. If there is no SPF record, we have no
moral basis to say that the SPF result is "fail". None. Period.
That argument can go both ways, and it's more of a question of
definition really.
If a domain exists, and the domain owner hasn't entered an SPF record,
then I can see why "none" is appropriate.
But if would-be-domain owner hasn't entered *any* records of any type
for a (nonexistent by definition) domain, I don't see the moral problem
with defining that as equivalent to an
explicitly-incorporated-in-the-spec "best guess" record of "v=spf1
-all".
I don't want to have to make verisign-sitefinder-type wildcarded "v=spf1
-all" records for all my nonexistent domains, as suddenly that makes
them exist, and breaks anyone's similar test for domain existence.
IMHO it should be okay for you to conclude that the fact that I have no
records of any type for some random subdomain of my domain means that
all mail claiming to come from that domain should be considered forged.
The problem is very simple.
In SPF-classic, if no return path is given (MAIL FROM:<>), we use
postmaster@<helo.domain> instead.
Null MAIL FROM's are common on bounces and such. They are often
legitimate email.
Many legitimate MTAs give bogus HELO domains.
These bogus HELO domains often return NXDOMAIN.
Ergo, using the above rule causes problems with rejecting valid email.
This point I understand, and I can partially agree with it.
However MTAs that do this, while possibly "legitimate" in some sense,
are also definitely "misconfigured", though I have to admit that
rejecting bounces with HELO-nxdomain problems possibly violates the "be
generous in what you receive" principle, though I'm not sure how
applicable that is here. (It probably should be considered so.)
I also have to admit a personal here of "HELO names should be valid; if
only messages sent with invalid HELO names could be universally
rejected, then the world would be a better place and everyone would live
happily ever after" that could cause me to not be so concerned about
this sort of problem as I perhaps should be.
In any event, you do have ways to continue to object to this bug:
1. Submit comments to this draft.
2. Submit changes near expiration, when the draft will probably
have a few other bugs to correct.
3. Convince the spf library writers that this is a bug, and that
they should return "none" in this case. (Possibly only in
the null-mailfrom case.) My understanding is that it's a pretty
common thing for even full RFCs to have well-known bugs that are
commonly worked around.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com