-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Radu
Hociung
Sent: zaterdag 7 mei 2005 17:36
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: HELO versus MAILFROM results
Reputation at HELO
===================
Currently, the reputations of MTAs are tracked with RBL
databases based on their IP address. Is rejecting based on
SPF not equivalent to rejecting based on RBL? If not,
what's the difference?
RBL databases, such as you refer to, are 'centralized' block lists,
operated and maintained at the 'whim' of the individual(s) running the
RBL. Rejecting based on the result of checking SPF records, is an entirely
different thing altogether, as SPF records are as 'decentralized' as can
be: the policy is set per domain owner/maintainer. With SPF, it is as if
every domain owner has his own mini RBL running; except that I would not
really call it an RBL, as SPF records just list which relays are
authorized for a specific domain. And, unlike an RBL, the SPF IP lookup
does not yield a 'static' result; instead, the result depends on what
domain name is used in MAIL FROM or HELO. And thus, with SPF, an IP
address may pass one time, and fail the other.
What improvement does the HELO check offer over a simple RBL check?
I am surprised you have to ask, even. A domain name based reputation
database has great advantages. For one, because the maintainer of said
database no longer has to bother with ever-changing IP addresses. That is
the beauty of SPF: the domain owners themselves define the authorized IP
addresses; the reputation database just lists domain names; and the one
making the query does the SPF query for domain X against the connecting IP
address.
Is the above idea equivalent to the "larger scheme of things"
you had in mind?
The "larger scheme of things" I had in mind, for one, includes the return
of domain name block lists and/or domain name based reputation databases.
SPF 'funnels', as it were, the use of domain names through specified,
authorized relays. One you have 'locked in' the authenticity of the use of
an SPF-protected domain name, you can then, confidently, consult a
reputation service for that domain. To give an example, with SPF, I can
now confidently query:
aol.com.rating.cloudmark.com
In a free-for-all world, without SPF, doing so would be virtually
meaningless, as everybody can use/fake every domain name.
Actually the only thing that SPF can do is deny spammers use
of a domain name that has "good reputation".
"good reputation" is a relative term. AOL may be said to have a good
'global' reputation. My domain(s) have no global reputation. But it just
takes one major spam run to ruin a reputation. Relative to the domain
owner himself, his reputation is therefore always of 100% relevance.
There's no incentive for a spammer to use a domain name with "bad
reputation",
But he has to resort to that, to start with, because he SPF hinders him
from using the 'good' names.
when he could just publish an SPF record, and start from
"no reputation"
That is one of the aspects of the aforementioned 'funneling' effect I
spoke of: spammers will gradually be forced to use only their own domain
names. At which point they can be block-listed by domain name even. This
'bypass', as you call it, is an intended, and desired, effect of SPF.
But unless the reputation of the HELO name is used by spam filters, it
doesn't matter if the HELO name has a good reputation, a bad
reputation or even if it has no SPF record.
Yeah, lol; just like not making an RBL query will not give you RBL info,
not doing anything with the HELO name means you cannot do anything with
the absent result. :)
It boils down to knowing if a HELO name belongs to a forwarder or to a
spammer. How can you reliably assert this by using SPF, and
by not using an RBL?
Because SPF will tell you whether the connecting IP relay is authorized to
carry the used MAIL FROM and/or HELO name. As simple as that. The relaying
MTA sets the HELO name, not the spammer (unless the spammers runs the MTA,
of course). The HELO name, in that regard, always belongs to the
forwarder. So, "knowing if a HELO name belongs to a forwarder or to a
spammer" is therefore, a non-sequitur.
Say, I check "mx01-dom.earthlink.net" as HELO name, and it resolves
properly, then I would probably use 2 DNS queries to a reputation
service: one for "mx01-dom.earthlink.net" and one for "earthlink.net".
And if it really became the far-fetched case that spammers would create
an infinity of possible HELO strings, I would simply reverse the order,
and evaluate "earthlink.net" first. Problem solved (if there even was
one).
So eventually we'll be back to checking *only* the MAIL FROM.
Thank you for agreeing with me.
LOL. I never said such a thing. :) I just showed you why your 'infinity of
possible HELO strings' is finding trouble where there is none.
Perhaps the better question is: How will the spammers adapt if the
entire world used SPF?
By using either unprotected domain names, or by using their own domain
names. In both cases, the SPF-protected domain owners win.
Obviously, the requiremenet of having a mail server dedicated to each
domain name registered does not scale, as it would be equivalent to
aking that there be a post office dedicated for each household.
Exactly. :) And so, as each mail server identifies itself with the single,
'static' HELO name, do you now see the advantage of HELO checks?
You missed the point: the bracketed IP literal is not an
SPF-protectable domain name that needs looking up even.
I don't think I missed the point.
I claimed that in case IP notation is used, it is not 100%
safe to rely on an A query, because there's no A name to query.
How do you prove that "no name" == [IP notation]? What do you query?
How is this 100% safe?
Here is why you *did* miss the point: a bracketed IP literal is not
something on which an SPF query needs to be done even. Your question is
like: "How does SPF protect a domain name which is not a domain name?" It
doesn't. :)
Would the HELO SPF check not be bypassed if the spammer says "HELO
[12.34.56.67]" ?
No; see previous paragraph.
And would the MAIL-FROM SPF check not be also bypassed if
the spammer said "MAIL FROM <>" ?
No, because a check would be done against postmaster(_at_)HELO(_dot_)
An SPF check on postmaster(_at_)[12(_dot_)34(_dot_)56(_dot_)78] ? What would
that mean ?
Nothing. Since there is no domain used, either in MAIL FROM or HELO, there
is simply nothing to protect; hence, nothing lost or 'bypassed'. This is
SPF 101.
I said that forging the postmaster account by sending MAIL FROM <> is
marginally useful, because many spam filters will know that that route
is prone to spamming, so they will scrutinize it.
I think you misunderstand, here. The postmaster(_at_)HELO address, which the
SPF query is made against in case of MAIL FROM: <>, is not exposed to, or
inserted into, the SMTP dialogue: it is just a composed, internal value
used by the SPF client, for examination.
It is much more useful for a spammer to forge MAIL FROM
<blah(_at_)domain(_dot_)com>, especially if the spammer controls the
domain.com and publishes SPF for it,
In that case, he would not be 'faking' his own record, now would he? :)
Regards,
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx