On Tue, May 10, 2005 at 04:03:27AM +0200 or thereabouts, Julian Mehnle wrote:
Michael Elliott wrote:
Throwing in my opinion. SPF is asked one question.
"Is this email address a forgery?"
Answers are:
+ PASS positively no. The address is valid.
- FAIL positively yes. It is a forgery as defined by the
domain owner.
~ SOFTFAIL maybe, but I, the domain holder, am telling you
to accept the mail anyways.
? NEUTRAL [I'm not positive either way, you are free to use some
other check]
none NONE No answer found.
TEMPERR I will check it again another time when resources are
available
PERMERR bad SPF record, domain owner needs to try again
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. My answer is to "I don't have a
definitive answer" and allow it to follow the default path that the MTA
would use.
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.
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.
SPF was not asked if the domain exists, if it has a good reputation,
or if it has a high spam/signal ratio. It was asked if the address was
a forgery. [...]
Exactly. So how can the answer be "this domain does not have an SPF
record", if the domain doesn't even exist (DNS RCODE 3)? You could argue
from a historical standpoint that SPF implementations have always returned
"None" (although I'm not sure that would be correct), but from a logical
standpoint, IMO "PermError" is the most fitting choice.
local policy and/or trusted-forwarder.org.
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.
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. The local policy and trusted forwarders
policies should be checked, as the can have an impact.
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.
There are systems that do it today, but it is not recommended.
Besides that, I am saying that the "reject on NXDOMAIN" is to be made by
the MTA above the scope of the SPF library. 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.
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."
NXDOMAIN is go back and fix a different record in DNS.
Julian Mehnle wrote:
But considering that, like you said, most receivers probably reject
messages with non-existent sender domains right away anyway, without
subjecting them to SPF checks, I think defining
SPF(non-existent-domain) == "PermError" is unproblematic and is
logically the right thing to do.
People just shouldn't expect SPF to work on invalid input data.
"most receivers" by definition means not all. There are some receivers
that will need to accept email from unresolvable domains. Forcing a
550 responce, means SPF cannot be run on those servers.
If you mean the "SHOULD reject the message with an SMTP reply code of 550"
in section 2.5.7., I think we are just about removing that recommendation
for reasons of consistency with the other results not making any
recommendations either.
There is no "invalid input data" here.
"-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.
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. SPF's job
is only to tell me if the owner of the domain has set a netmask of where
the mail is expected to be coming from to be something smaller than 0.0.0.0,
and if the email is coming from inside or outside that netmask.
Answers are yes, no, probably not but take it anyways, I don't know,
and I screwed up the definition.
It is the MTA's job to decide if the domain exists and whether to accept it.
It is grey listing's job to decide if I have talked to this address before,
It is domain key's job to decide if the mail came through a particular server.
It is clamvd's job to decide if this is a virus.
It is SpamAssassin's job to decide if the content is acceptable.
It is procmail's job to throw out mail from jerks I have plonked.
It is Outlook's job to sort the mail to the top if it is a friend.
I hope I made my arguement well enough in my ranting.
-Mike Elliott