On Wed, 2005-07-20 at 12:55 -0700, Greg Connor wrote:
I don't know of a good way to objectively tell whether something is
experimental.
This is the category assigned by the IETF.
I'm not sure exactly what is meant by "a means to indicate the exclusive
use of a domain is or is not being assured by the server".
While there have been several providers to offer domain owners their own
IP address for reputation protection, such providers will likely need to
acquire a server per 8 such domain owners, to justify the IP address
use.
While perhaps as much as 20% of the domain owners could acquire their
own IP address, this method of constraining outbound SMTP authorization
is expensive. What is not apparent is whether a server ensures that
shared domain use is not abused. At the meeting in the technical
section, an example had something similar to 'include:isp.net'. If
servers at isp.net handle large numbers of domains, and do not constrain
both the PRA and the bounce-address, then such an 'include' could become
reputation suicide.
The spec is pretty clear on what constitutes a "pass" vs. "unknown".
As there are many functions possible within the SPF script, it is
difficult to know what basic function is being attempted. Without
knowing this, what does 'pass' really mean? I would recommend creating
a structure that describes returning results in three categories based
upon the actual function completed:
- authorization
- authentication
- compliance
I have been suggesting to people for quite some time that they should
use the "+" mode if they control the MTA, or if they trust the MTA
operators enough to take responsibility for the MTA's actions.
You are advocating an undocumented convention that could not be
differentiated from existing use, but okay. If the mailbox-domain is
not constrained as indicated by the absence of '+', then results should
fall within the 'authorization' category. If the domain is constrained,
perhaps by specialized software, or exclusive use of an IP address, then
results could fall within the 'authentication' category.
Without knowing whether the domain is constrained, which normally it is
not, then holding the domain accountable for abuse would be unfair. A
'failure' result within the 'authorization' category could be used to
repudiate the source of the message only. However, a 'success' result
could not be used as a basis for reputation accrual. Alas, it is not
human nature to follow this practice. A recipient will still want to do
_something_ about abuse, even when it is only being 'authorized' by a
domain owner. As a result, these domain owners may become unfairly
blocked.
The domain owner should not have been held accountable, as they are
unable to protect themselves. Nor will the SPF system allow everyone to
protect themselves, which suggests it is okay to create a type of second
class email domain. This is where the phrase "let them eat cake" comes
to mind.
For some domain owners, this could mean "the site uses SMTP AUTH and
doesn't allow spoofing of other domains".
Yes that is possible, but this system keeps the domain owner in the
dark, and the administrator that MUST provide the security, anonymous
and in control of all evidence. Again human nature seems to suggest
that there will be many domain owners unfairly treated.
For others, they may be content with "the site doesn't currently have
an ongoing forgery problem". This is a tradeoff the domain owner must
decide for himself. If they don't wish to take responsibility for the
MTA, they should use "?" instead of "+" to add it. We want to
encourage everyone to move to the "+" column eventually, but there is
still quite a bit of value in narrowing the "?" space from ?all to ?
certain-MTAs -all. Every little bit helps.
I would say there is another option that should be considered. Not
publishing SPF records. Many recipients are rejecting '~' and '?' which
creates an immediate problem for the sender with forwarding issues that
depend upon this exploited feature. I doubt there are many service
providers willing to offer domain owners indemnification, should their
domain become abused, and the domain's reputation is subsequently
damaged.
I think we have been over the difference between "+" and "?" in the spec
before, so I'm puzzled as to why this is still often (very often) brought
up as a "fault". Do you really see it as a fault, or is it just a
convenient place to attack SPF because people often get confused about it?
Do you understand the difference between Pass and Neutral results?
I am attempting to clarify what is needed for the next step, while you
are focused on the mechanics that look past the basics. Step back and
think about the basic functions: authorization, authentication and
policy compliance. As I said, it appears the '~' and '?' are already
too heavily exploited to be of much use as shades of failure.
(Last I checked CSV doesn't have a neutral or unknown mode. If I remember
right, the only way to signify "unknown" under CSV is not to publish. Of
course, you didn't say whether you are comparing SPF to CSV, or just
railing on SPF without a constructive counter-proposal.)
I see DKIM and CSV as fair as safe paths to enabling name-based
reputation. Consider what is needed to perform the basic functions.
My comments come from a perspective different from most providers. A
perspective found dealing with angry senders; where error messages often
point to the wrong reputation service; for the sender, it does not
matter who created the reputation accrual error, they want someone to
call for restitution.
There is no spam or phishing solution without the use of email
reputation. The accrual of reputation demands authentication and not
just authorization, if to be fair. Saying that authorization is good
enough sounds too much to me like "let them eat cake" when knowing those
that care will have their own servers. Getting this right requires an
understanding that neither authorization nor authentication alone is a
solution.
I think I would agree with that. But if there's any lesson I take away
from MARID, it's that the best is often the enemy of the good. Waiting to
solve one problem until we have enough tools to solve a larger number of
problems doesn't seem to be the best way forward.
I still see CSV and DKIM as a way forward. I would have expect CSV to
come first however. CSV protects the network resources, and DKIM
protects the domain owners. There are different incentives for each
method, but in the end, they both can safely support a name-based
reputation system without unfairly causing harm.
The next step in this process is reputation, however this step can only
be safely made when there is an ability to authenticate the entity being
held accountable. Just calling it authentication is not productive,
when it is based upon an assumption that the server is not shared. I
find this a bad assumption and one that will create endless support
issues when exploited by the millions of zombies known to exist.
I understand what you mean here, and I do believe you are sincere, but I
don't agree with your characterization nor your conclusion. I should
probably go back and read the spec and see if the language explaining pass
vs. neutral is clear enough. If you have suggestions on how to make this
clearer so people aren't confused in the way you suspect they currently
are, I'm sure Wayne would welcome the feedback.
If you look at the language for pass, you will find the word 'authorize'
accompanied by language that suggest this is good enough to hold the
entity accountable and to accrue a reputation. As I have said many
times, authorization is not good enough. HELO authentication carries to
much baggage to be really useful at defending resources, which is the
role it should play. I have never been shy at offering feedback. : )
-Doug