"Unknown" is an error state.
In that case we need to introduce something new - because Unknown is also used
as the state "unknown", which is something completely different than an error
state. In case of an error, the system should bounce the e-mail or reject it
somehow, whereas a genuine unknown state should make the e-mail pass somehow,
because most e-mails today will have the unknown state.
It means that an error in the SPF information is preventing a correct
evaluation.
It does not mean "Pass". It also does not mean "Fail". It means "Apply the
same
rules to this message as you would to a None, but realize this is really an
Error."
No - it can also mean "this e-mail comes from a domain that does not publish
SPF records" or "The sending mailserver can send both forged and real e-mail
messages from that domain".
Sensible MTA should basically allow one of the following rules to be applied:
1. allow anything, add headers only (used before widespread adoption and
during testing)
2. reject "Fail" (used during tentative adoption)
3. reject "Fail" and "Softfail" (also used during tentative adoption)
4. reject anything that isn't "Pass" (used after widespread adoption)
You seem to assume that all SPF filtering is done during SMTP negotiation. This
is not the case. Our biggest mailserver, which carries 70000+ recipient e-mail
addresses, doesn't even reject based on invalid recipients.
So, before widespread adoption, your "Unknown" will basically allow you to
continue sending e-mail to most MTAs. After widespread adoption, an
"Unknown" SHOULD cause rejections.
You're saying that it's the implementation that decides what to do in the case
of an error... why? Why shouldn't it be the SPF record publisher, who decides
what to do in case of an error? Please explain...
You can't prevent theft identity of your domain
from occurring on MTAs where the admin decides that EVERYTHING will pass,
even "Fail"s.
So you are basically arguing that "if the recipient system is a moron, it's not
the sender's fault". I totally agree with this, but can't see the point of that
statement or its relation to the discussion, whether the sender should have the
ability to specify a value for the case of an error.
Lars.