In
<1097806340(_dot_)21121(_dot_)63142(_dot_)camel(_at_)localhost(_dot_)localdomain>
Mark Shewmaker <mark(_at_)primefactor(_dot_)com> writes:
On Thu, 2004-10-14 at 21:54, Mark wrote:
This is the text:
If the domain does not exist (RCODE 3), check_host() exits
immediately with the result "Fail" and a reason of
"Domain Does Not Exist"
[...]
It is perfectly legit to use a domain name for which only an MX record
exists, for instance. An immediate result "Fail" because of "Domain Does Not
Exist" appears in error.
But a domain name for which only an MX record exists will not get an
RCODE 3 response in the first place, since there do exist some records
for that domain.
True.
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.
*sigh*
Apparently many of you *don't* remember all the problems that this
language caused last time.
First off, SPF is about preventing email forgery. It doesn't verify
the bounce-ability of the Return Path. This is simply wrong.
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.
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.
Ok, lastly, in my post earlier tonight, I said:
DON'T YOU REMEMBER ALL THE PROBLEMS WITH REJECTED EMAIL THAT IT
CAUSED?
Apparently you don't remember and don't see the problem.
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.
Those that don't remember the past are doomed to repeat it.
*sigh*
-wayne