-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Elliott wrote:
Julian Mehnle wrote:
I think you got it wrong. "None" means "this domain does not have an
SPF record". "PermError" (previously called "unknown") means
"unknown/ undefined".
I disagree here. "None" means
A) "dig host.domain.tld txt" yeilded no SPF record to check
B) check_host("best guess/local policy") was processed with no match
C) check_host("spf.trusted-forwarder.org") was processed with no match
Google proved my point yesterday. They, for forty minutes, screwed up
their DNS so that www.gmail.com and www.google.com were pointed to
CNAMES that did not exist. Therefore, a lookup returned NXDOMAIN. If
that was their mail servers isstead of their web servers, your answer is
to PermError the mail and block it.
Did they really prove your point? For one thing, the SPF spec doesn't (or
won't for long) recommend to reject on "PermError". On the other hand, a
great many MTAs already _do_ reject on non-existent envelope sender
domains.
If you consider gmail.com to be that important so as to grant them the
right to occasional serious misconfigurations and to still have their mail
accepted, you should probably whitelist their domain(s) instead of making
SPF return a result code that downplays their configuration problem.
IOW, would you want to gracefully overlook a similar "configuration"
problem (NXDOMAIN) for the domain "nutritious.medz4you.biz", too?
If gmail.com MX records were affected instead of their www record, the
following would have happened.
answer = _SPF_init("myname.domain.com", "64.233.170.193", "",
"v=spf1 include:spf.trusted-forwarder.org",
"v=spf1 a/24 mx/24 ptr", 1, 1);
SPF_smtp_helo(answer, "rproxy.gmail.com");
SPF_smtp_from(answer, "user(_at_)gmail(_dot_)com");
answer->RES = SPF_policy_main(answer);
You say answer->RES = SPF_UNKNOWN and throw a PermError, I say SPF_NONE.
Since my sendmail acess.db has "Connect:64.233.170 OK", my default
action would be to have accepted the mail. The Connect: was put there
to bypass greylisting which I also do. Any unresolvable_domain
that is not whitelisted by a connect: in the access.db would receive
an "ERROR:5.1.8:501 hostname must resolve".
Any PermError by the SPF check thwarts the access.db lookup.
Isn't that a design error of Sendmail? You should be able to apply a
whitelist _before_ the SPF check is performed.
If the accesss.db lookup is used to skip the SPF check, mail coming
from 64.233.170.* with a sender of receipts(_at_)amazon(_dot_)com is allowed
to
blindly pass. That is exactly the type of email that I want SPF to
check and flag with a FAIL, because it is coming out of the wrong
organization.
My way, the system administrator has fine control by IP/domain as
to what the result is. Your method says deny 100% of the time.
But only with regard to the broken (inflexible) Sendmail filter
implementation. What you are saying is: "I need to behave SPF in a
certain way because Sendmail is too inflexible for anything else."
Here is one to try.
answer = _SPF_init("myname.domain.com", "66.35.250.206", "",
"v=spf1 include:spf.trusted-forwarder.org",
"v=spf1 a/24 mx/24 ptr", 1, 1);
SPF_smtp_helo(answer, "lists.sourceforge.net");
SPF_smtp_from(answer, "snort-users(_at_)lists(_dot_)sourceforge(_dot_)net");
answer->RES = SPF_policy_main(answer);
When the lists.sourceforge.net returns a NXDOMAIN because of some
admin's temporary screwup in DNS. Google and Panix are just two
examples of systems that disappeared from DNS when they shouldn't.
Hint: Trusted-forwarder.org will match, even if lists.sourceforge.net
returns NXDOMAIN.
So what are you trying to say here? That SPF should be able to distinguish
temporary/involuntary screwups from long-time/voluntary ones, and ignore
the former? Or that SPF should ignore as many screwups of any type as
convenient, at the expense of ignoring long-time ones?
It is up to the MTA to decide whether or not to accept the mail from
a domain that does not exist.
Exactly, and it should be up to the MTA not to perform SPF checks on
messages that don't have an existing sender domain. They can still
accept such messages if they want, but they shouldn't perform SPF
checks on them.
The sourceforge example above shows how the SPF check can result in PASS
even if the domain is NXDOMAIN.
Only in your specific configuration. This is all receiver policy, and you
shouldn't argue to change SPF in one way or another just because some
MTAs' configuration interfaces are inflexible (or maybe just set up in a
bad way).
Just think of what happens when SPF has reached widespread use and
people start switching over to rejecting on "None". Then what?
An SPF record in DNS is optional. MX is optional. How may systems
refuse mail because of the use of an implicit MX record? Rejecting on
None would be equivalent to rejecting all mail not ending in .com, .net,
or .org.
No, because using non-CNO TLDs will never, ever, be conceivable as a bad
configuration choice. The same does not apply to implicit MXes and
lacking SPF records -- today these may be acceptable, but in 5 or 10
years, this may have changed.
Besides that, I am saying that the "reject on NXDOMAIN" is to be made by
the MTA above the scope of the SPF library.
I absolutely concur.
So if you do perform a NXDOMAIN check outside of SPF, and choose to ignore
NXDOMAIN, what do you need to call SPF for, just in order to get a
"None" (which you could have predicted)?
The same admin would reject on "None" would also have the "reject on
NXDOMAIN" bit set in his MTA. Don't override the decision that would be
made if SPF was not in the process chain.
Now I think I see what your real aim is: You want to save the extra
NXDOMAIN check and still be able to call SPF with no "negative" effect.
If this is really your point, I think this is an opportunistic and
short-sighted argument. The domain query (resulting in NXDOMAIN) will be
performed in _any_ case, be it directly by the MTA, or by the SPF library.
So you're not saving any work by not performing the simple NXDOMAIN check
beforehand.
To the contrary: In relation, the SPF library will almost certainly have
to do significantly _more_ work before being able to return "None". Doing
the simple NXDOMAIN check beforehand and skipping the SPF check if the
domain doesn't exist will probably save you quite a few CPU cycles.
SPF(), in all its complexity, should only be called if it can be reasonably
expected to give you a _non-obvious_ result.
The option of what to do with a non-existant domain name is for the
MTA and not the SPF library. IMHO, SPF MUST return "NONE" because
it does not have enough information to answer the "only" question it
was asked.
But that's what "PermError" (formerly known as "unknown") is for.
PermError is for "syntax errors" such as %(ir), exceeding DNS lookups of
10, more than one TXT record containing "v=spf1", include of
non-existant SPF record, more than one redirect or exp, and other record
design errors. All those errors are fixed by "go back to your DNS server
and adjust the SPF record."
Generally, "PermError" is for signaling a situation that was not expected
by the domain owner and that needs manual intervention to resolve. IMO,
this includes the use of non-existent domains in the envelope sender.
"-foo.-bar" (or "[1.2.3.4]" for that matter) is just as invalid as
input data for SPF() like 0 is invalid as input data for log(), isn't
it? It makes no sense to ask "what is the SPF policy of -foo.-bar?".
If 4.3.2.1.wl.trusted-forwarder.org exists, then we have a PASS.
If the T-F whitelist is checked and if it matches, no SPF check should be
performed in the first place. The T-F website correctly says: "The
trusted-forwarder whitelist is NOT part of the SPF specification."
Again, consider what happens when SPF has reached critical mass and
people start switching over to rejecting on "None", which has long
been the vision of SPF. You don't want to subject messages with
invalid sender domains, but which you want to receive anyway, to SPF
checks then, do you?
Yes, If DNS is broken temporarily, and I have whitelisted by IP, I want
the mail to flow along the same path as if SPF did not exist.
That's why you're supposed to apply any whitelists _before_ you do an SPF
check.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCghK2wL7PKlBZWjsRAkAoAKC8rztgDsQru46JMoZ88urmCr56CQCfZiHO
nHoNp5XPXgI8QInC+dJoeIQ=
=ooLj
-----END PGP SIGNATURE-----