Re: [spf-help] Re: SPF and SenderID

--Douglas Otis <dotis <at> mail-abuse.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.org>