-----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 Greg
Connor
Sent: December 16, 2003 4:34 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Maybe simple question
--"Vivien M." <vivienm(_at_)dyndns(_dot_)org> wrote:
So we both agree that SPF has as a key "side effect" that
it empowers
domain owners, at the expense of everyone else, whether
they be good
(eg: customers, employees, etc) or bad (spammers). We just
disagree on
whether this is desirable.
This line of reasoning assumes that the "domain owner" is
different from
the "domain users". I don't think I agree with this.
Usually I think of
the "domain owner" as the entire organization, including any
authorized
users.
That's true for smaller organizations...
However, your point seems to be that the "organization" may have
disagreements within itself, like between the DNS team and
the IT team (or
possibly the anti-abuse-support team). That can certainly
happen. The
organization and its leaders/managers/responsible people need
to work out a
consistent story among themselves.
Look at the following situation: you have an educational institution that
provides dialup (from back in the days, like 95-96), POP3, etc to its end
users who operate from home (students, or faculty who prefer to work at
home, etc). As the end users who used dialup moved their home machines onto
broadband from the incumbent telco/cable co, these end users changed their
SMTP servers from the institution's (which wouldn't let them relay,
obviously) to the broadband ISP's. In the meantime, the educational
institution's IT dept, being unwilling to support massive amounts of POP3
clients, deployed a web mail system and has been pushing that way of doing
things to new students/staff. The POP3 server infrastructure remains
maintainted and supported, but information about it is somewhat hidden in
the IT dept's web site.
Now, let's say this IT department wants to deploy SPF. They deploy SPF to
allow their machines to send, which means that their dialup users are fine,
the on-campus users are fine, and the webmail users. The people with their
"left-over" POP3 clients get screwed, unless SMTP AUTH or similar gets
deployed. Now, since some work-at-home staff still uses dialup, the large
majority of students with POP3 setups graduated (and most new students use
webmail), why should the IT department invest largeish amounts of money in
an SMTP AUTH (or VPN, or whatever) for the small amount of people left out
by this? It's EASIER and CHEAPER to tell them "Just use
http://mail.blah.edu/ instead" - and THAT is what I have a problem with.
Since important decision makers deal with their email at work primarily (and
their "good" email clients won't get broken), they'll view this simply as a
money issue - why spend $XX for an SMTP AUTH relay when for $YY, we can tell
the 5% of people affected to use the existing webmail system. The affected
people will talk to front line IT, and be told "http://mail.blah.edu/ is all
we support now." by a student paid 10 bucks/hour.
This isn't an issue of organizational politics as such and conflicts between
the mail/DNS admins. It is an issue of SPF requiring ADDITIONAL expenditure
to support what was previously quasi-costless to support. In the example
above, someone off-campus POP3ing would not cost more (probably less, given
the cost of phone lines being higher than bandwidth to send the mail out of
the campus) as someone dialing into the organization. WITH SPF, it is
cheaper to restrict POP3 to on-campus users and screw everyone else over and
impose that perversion known as webmail on them.
Second example I gave earlier, and will restate now: you have a family with
a 5 email account plan from joeisp.net. Let's say Mary Doe goes off to
college, and wants to keep using her marydoe(_at_)joeisp(_dot_)net address that
her
friends from home know. The family is still paying for that account -
currently, most ISPs (there are the occasional exceptions) would let her
POP3 that mail from the campus network, but won't let her send to it. So she
sets the SMTP server to the college's server, and can send her mail to her
friends. With SPF, she can't do that - so she has to use whatever joeisp.net
wants to provide to off-net users. If joeisp.net is smart, that would be an
additional cost service - webmail, SMTP AUTH, whatever... So suddenly, to
use her joeisp.net account from college, Mary (or her parents, who are
joeisp.net's customer) must pay joeisp.net extra money.
These are two examples where the powers that be (the IT department in the
first case, and joeisp.net in the second) have NO interest in making
available inexpensive SMTP AUTH to their end user. In both cases, the end
user is paying their current ISP (the broadband ISP in the first case, the
campus in the second) for SMTP service, and is "paying" the POP3 provider
for that account. In both cases, the affected enduser is too small a fish
(do you really think the Doe family would cancel their home Internet service
and go through the hassle of telling everyone they know about their new
email addresses simply so Mary could still read _her_ email? Which,
ironically, she couldn't do with a new ISP - if she's going to tell her
friends a new email address, just tell them the campus one and save the
family the trouble of doing the same) for the SPF implementor to care about
these "side effects" of the SPF implementation.
These are grey areas: things that the server admins right now allow, but
have little interest in supporting officially, especially without extra
money. SPF gives them the ability to restrict uses of their domain to black
and white, and if your use is grey, either you pay up (with a commercial ISP
- with an IT dept, you're probably SOL) to have that use whitened, or it
becomes black and you're screwed.
Most of the discussion on this list has ignored grey areas, and assumed
things like a) the ability of the little person in a big organization to be
heard by IT, and b) the ability of affected end-users to change
SPF-implementing providers without significant effort (eg: changing email
addresses) to a provider with a more flexible SPF+other-things
implementation that meets this person's needs. My point is simply that those
assumptions ought to be questioned to see if they really reflect the way
things work.
Vivien
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com