Re: [spf-help] Re: SPF and SenderID
2005-07-20 23:50:10
--Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
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.
I'm not sure what having "your own IP address" has to do with either
authentication or authorization. Are you working under the misapprehension
that you need a separate IP address per domain name in order to turn on
SMTP AUTH and enforce proper use of identities?
A casual reader of the above might make the mistake of assuming that SPF
requires a static IP in order to work. It is strongly implied. If you
actually believe this, I can take the time to explain how SMTP AUTH and SPF
Pass results are related.
If you don't understand what I meant when I said "the site uses SMTP AUTH
and doesn't allow spoofing of other domains" then please ask for
clarification. If you DO understand what I meant, please stop spreading
misleading information.
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
The SPF spec describes "pass" as "the action is authorized". It doesn't
describe authentication or compliance, as far as I know. I believe SPF is
a great tool for what it does, but it doesn't do everything. I think this
is OK... any tool claiming to do all of the above should be viewed with
skepticism... To me it seems a lot more likely that the problem space
will be covered by multiple tools.
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.
I'm sorry, I think my initial explanation was not detailed enough. I was
assuming that since you spend a fair amount of time pointing out SPF's
faults, that you were familiar enough with the mechanisms in question to
understand my statement.
Here is some background necessary in order to understand the significance
of "pass" vs. "unknown" in the context of reputation.
"+" indicates that the mechanism results in a "pass". "+" is also the
default, so if you have a mechanism with no prefix, the "+" is understood.
+include:isp.net and include:isp.net are the same. If the mechanism
matches the situation, the result is "Pass". The receiver can proceed with
confidence in the identity (mfrom or helo). The action is considered
authorized, and the domain owner should be held accountable for the action
of the MTA.
"?" indicates that the mechanism results in a "neutral" result. The action
is neither explicitly authorized nor explicitly denied. The receiver
should proceed with whatever the default action is for domains not
protected by SPF.
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.
Right, again I apologize for not explaining what I meant well enough. I
believe your first paragraph above is consistent with the "Pass" result and
the "+" modifier (or no modifier), and your second paragraph applies well
to the "neutral" result and the "?" modifier.
The difference between these two modes is as you say. "Pass" is the only
result I would really describe as "success". It implies that the domain
owner wants the privileges conferred by a Pass, and is willing to defend
the messages coming from that MTA with his reputation. They are one and
the same as far as SPF is concerned... it is meaningless to authorize a
message if you're not willing to stake your reputation.
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.
I don't really draw a distinction between equipment I own or control, and
stuff done on my behalf by a vendor. The important distinction is not who
owns the equipment, but whether I trust the vendor/partner/employee/robot
in charge of doing it, and whether I trust them enough to stake my own
reputation.
A lot of ISPs are now requiring the use of SMTP AUTH within their networks,
but my experience has been that they don't block messages claiming to be
from various domains. Hopefully if enough users ask for this, they will
start matching up domains that I own and control with my name and password
for SMTP AUTH, and disallowing others from using domains they don't own. I
don't think it's a tough problem to solve, but currently they have no real
incentive to solve it. I think wider use of ip-based authorization will
put more pressure on them.
In the meantime, some domain owners may choose to give them a PASS anyway,
in effect staking their reputation on a service that may be mostly
spam-free and forgery-free right now, but may develop such problems in the
future, and they will deal with that if and when it happens.
> 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. : )
You stated a couple of times (though I snipped them for space conservation)
that you see CSV and DKIM as a valid path to authorization, authentication,
and reputation. Why do you feel that CSV+DKIM fulfills this goal, but
SPF-HELO+DKIM would not?
I readily admit that I don't understand CSV well enough to spend a lot of
time bashing it on various lists. Therefore, please don't assume I'm
bashing on CSV here. If the point of CSV is to provide confidence in the
HELO name, how is that functionally different from SPF used to check HELO?
- A domain owner publishes a record in DNS
- A receiver has a name and wishes to check it against the IP that
offered the name
- The receiver gets the DNS record and checks to see if the IP is
authorized
- If the IP is authorized, the receiver can proceed with confidence in
the HELO identity
It's my understanding that the above requirements can apply to either CSV
or SPF-HELO. I can guess that you probably don't agree with this, but I
still cannot fathom the reasons. Since SPF has been a frequent target for
folks to take pot-shots at such as "authorization without authentication is
not good enough", it's rather important to me to try and understand the
essence of this issue.
Thanks for taking the time to write.
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [spf-help] Re: SPF and SenderID, Greg Connor
- Re: [spf-help] Re: SPF and SenderID, Douglas Otis
- Re: [spf-help] Re: SPF and SenderID, Greg Connor
- Re: [spf-help] Re: SPF and SenderID, Douglas Otis
- Re: [spf-help] Re: SPF and SenderID,
Greg Connor <=
- Re: [spf-help] Re: SPF and SenderID, Kjetil Torgrim Homme
- CSV, DKIM, SPF, reputation (was: SPF and SenderID), Frank Ellermann
- Re: [spf-help] Re: SPF and SenderID, Alan DeKok
- Re: [spf-help] Re: SPF and SenderID, Arnt Gulbrandsen
- Re: [spf-help] Re: SPF and SenderID, Alan DeKok
- Re: SPF and SenderID, Frank Ellermann
- Re: [spf-help] Re: SPF and SenderID, John Leslie
- Re: [spf-help] Re: SPF and SenderID, gconnor
- Re: [spf-help] Re: SPF and SenderID, Kjetil Torgrim Homme
- Re: [spf-help] Re: SPF and SenderID, John Leslie
|
|
|