On Sat, 2004-07-10 at 11:45, Seth Goodman wrote:
actually, if public reputation services never appear, the
only overrides the algorithm will support are locally
hardcoded whitelists --- and the analogy with ssh is
appropriate. note the AND requirement for a positive
result:
As long as in the absence of a reputation system or a manual whitelist
entry, a malicious domain owner's SPF record cannot cause an override of
an SPF fail for the PTR domain, I am satisfied. The segment of the
draft you quoted indicates that is the case.
Cool. (And now I can delete my embarrassingly overly-verbose response.)
Unfortunately, I still have a couple wrenches to throw into the works.
(I still think we can all end up satisfied with things though.)
The first wrench is about RHS blocklists, and the second requires a
change in the unified spec.
On RHS blocklists:
------------------
I consider RHS blocklists to be reputation services. (Even if they
don't yet do everything we expect in future reputation services.)
A RHS blocklist says: "This domain is malicious/spammy/..."
So let's say I decide to use a set of RHS blocklists, and I trust that
they will quickly list "bad" domains, for my definition of "bad".
So from my point of view, viewing the world through two-valued-logic
glasses:
if domain_name in my_block_lists:
domain_name.reputation="bad"
else:
domain_name.reputation="not_bad"
That is, I would personally consider the *absence* of RHS-blocklist
entries for the potentially-malicious domain owner to be a good enough
positive reputation for me. I would guess that most people/isp's would
use that their default option as well.
As long as you trust that any malicious domain owner will be quickly
listed in your chosen RHS-blocklists, then the actual source IP used to
send their emails doesn't matter.
Whether they bought their own netblock and sent from there, or whether
they have "+all" spf records and have sent via dialup zombie
machines--well, that shouldn't make a difference as to whether they get
listed.
Two very nice things about using a law-of-excluded-middle binary
reputation point of view:
1. It has the ability to scale well:
A. As more people use such a system, more people will
be available to catch newer malicious domains.
B. Instead of you doing whois checks for new domains,
an RHS blocklist could do it for you, automatically
giving negative answers for "new" but unproven domains.
Once any RHS blocklist does this, you can immediately
start using their list with no work on your end.
2. If you start with such a two-valued-logic system, it's still
not really much work to later extend things to a three-valued-logic:
Here's one way an RHS-blocklist could make a tiny step closer to
being an accreditation/reputation service:
Imagine that an RHS-blocklists could return the answers: bad,
not_bad, and new.
Then recipients could:
if domain.reputation=='bad':
reject_mail()
if domain.reputation=='not_bad':
accept_mail()
if domain.reputation=='new':
for recipient in recipients:
if recipient.is_okay_with_new_domains():
accept_mail_with_warning_headers()
else:
reject_mail_for_this_recipient()
(Can you tell that I've spent the last two weeks in
python code? As a side note, python and pygtk just rock.)
So recipients who don't want to bother with new, untrusted
domains won't need to, and those who are willing to will have
their messages accepted with warning notes in the headers--
and those recipients are likely to quickly send positive or
negative reputation info to the blocklist.
(As a side note, I imagine that at some point MUA's will
eventually do additional queries on those new-domain messages later,
to move them in and out of potential_spam folders automatically
if the domain's reputation moves clearly into the spam/not_spam
camp.)
None of this requires a huge new infrastructure for anything; it
doesn't require web-of-trust super-duper accreditation services,
but it allows for evolutionary steps towards that where there are
advantages to all (non-scamming) parties to inexorably move towards
full-blown reputation systems.
(One evolutionary step: Instead of the middle-value being "new",
make it a plain "unknown", with all domains with no info in the
system having "unknown" reputations. Another step from there would
be for the RHS system to return an answer from "0" to "100", with
the "unknown" settable by the end user but by default being between
10 and 90.)
There are lots of reachable oases on the way from here-to-there.
There's a small issue though: The above points won't work within the
PTR scope tests we're discussing, due to a minor problem in the spec.
Problem with the unified spec:
------------------------------
I would change the spec by first putting a note into the PTR description
saying that no reputation tests should be within the PTR scope test. (!)
The reason: You can't test for a domain's reputation within the PTR
scope, because within the context of a PTR scope test you don't have any
domain to test(*). (ie, do you test the MAIL-FROM's domain, the PRA's
domain, or the HELO domain?)
So all a PTR test can do is require that all other tests result in a
PASS result.
That requires a change in the unified spf proposal. I would change the
logic of:
"A positive result from any identity overrides a negative result from
any other identity."
To something more along the lines of:
"To determine the unified SPF result, use an algorithm equivalent to
the following:
If an SPF/PTR test is made and results in FAIL:
Then the unified SPF test is FAIL unless all other scope tests
result in PASS.
Otherwise:
The unified SPF test result is the most negative of the results
of all spf scope test made."
(With some sort of wording such that a FAIL is considered "more
negative" than any permanent or transient error condition. There's
probably a much more elegant way of wording all this.)
This change is still compatible with sections 3.5.1-3.5.3, if one
changes the notion of important item of reputation of a HELO domain from
being an interpretation of whether the HELO host is a known spammer to
whether the HELO host allows forgeries.
Then everything works out nicely, IMHO. :-)
All the tests still work, and recipients can reject mail from malicious
domains by looking up their reputation in an accreditation service or
RHS blocklist, no matter whether they're sent from within a greylisted
netblock or not.
You *could* have the spec have a SPF/PTR-FAIL mean that all other SPF
scope tests made must also result in a positive reputation answer, but
as you can guess from my arguments in this mail and previous, I
personally think such requirements are unnecessary in practice.
(*) The spec lists "the PTR hostname of the SMTP client", but... IMHO
there's no point in doing any reputation tests on any of the PTR
domains.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com