-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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".
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.
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.
Just think of what happens when SPF has reached widespread use and people
start switching over to rejecting on "None". Then what?
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.
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?".
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCgBZvwL7PKlBZWjsRAnjgAJ4iXxgwfoC9NcQyK1C/Sb7M6acL8QCfdk2Z
Aad02TBsuoLAKyhaBYxJRuc=
=hfGS
-----END PGP SIGNATURE-----