-----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 Paul
Ficinski
Sent: Saturday, May 21, 2005 9:12 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Authentication vs. Authorization
On Sat 2005-05-21 10:00:12, Bill Taroli wrote:
Julian Mehnle wrote:
[...]
SPF, from a strictly technical standpoint, is a method for
authorizing
(implicitly) authentic IP addresses to use a certain domain name as
the
identity. This, in itself, is not equivalent to the authentication
of a
domain. In order to gain real value from SPF with regard to
reputation
systems, we need to somehow bridge the gap from the authorization of
IP
addresses to the authentication of domain names.
The only practical and useful way to do this is to require the
domain
owner
to take responsibility for the cases where authorized IP addresses
send
unauthentic (i.e. forged) mail, i.e. requiring them to declare full
trust
in their outgoing MTAs.
[...]
But isn't an administrator, by virtue of including an MTA (by
whichever
criteria they use) in their domain's SPF RR, explicitly taking an
action
that communicates trust in that MTA? To put it another way, unless I
fully trusted that a given MTA would (or could) not be used to
impersonate my domain (or another apparently on my behalf) to conduct
inappropriate activities then why would I take the dangerous step of
including it in my list of trusted senders? I wouldn't, of course.
It seems quite natural and logical, then, that I must take
responsibility for the MTA's I allow in my SPF record (which makes
include a tricky proposition, IMHO, particularly across domains). I
stake some of my own reputation in the event that one of them abuses
that trust, or wasn't actually worthy of it.
Only on a pass. Sure one will lose reputation if one's domain is
spoofed, but not any more then one would lose now. If a server that
one's record passes starts spamming then one reputation should take a
much larger hit.
It should be made clear in wizards that senders should only take
responsibility for the systems that they actually do trust not to forge
their mail. Systems they cannot trust to that extent should return
neutral. Common examples such as ISP smarthosts without SMTP auth
should be mentioned.
Zair
But don't forget that SMTP Auth doesn't particularly solve this problem
either. Most, if not all, large commercial providers (ISPs, web hosts, etc)
that use SMTP Auth, use it to authorize access to the MTA. They do not
typically use it to authorize the use of specific mail identities.
The auth methodology doesn't matter so much (I could get much the same
result with POP before SMTP), but that the method is configured not only to
limit MTA access, but also to limit mail identities to those authorized for
that user).
Scott K