I think I wasn't communicating clearly. I will try a more concise approach.
--"Vivien M." <vivienm(_at_)dyndns(_dot_)org> wrote:
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.
These users are getting screwed over by bad IT. NOT! by SPF. IT should
either "Do SPF Correctly" or "Not Do SPF". In my opinion.
SPF is not a flawed tool just because some people might end up using it
wrong.
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.
Then you have a problem with the IT department not caring about its users.
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.
I don't believe you have proved that "SPF requires additional expenditure
to support". They *could* tell pop3 users who choose not to use dialup or
webmail to screw off, and that would save money.
But seriously, if they allow pop3 from other networks, why do you think
they wouldn't allow smtp auth from other networks? There are free tools to
do it.
But again, IT will ultimately choose to use SPF or not, to provide smtp
auth or not, to allow other isp's to send on their behalf or not, or to
care about their users or not. In my opinion this is STILL not a flaw in
SPF. SPF is for those domains that *choose* to limit their senders, not
publishing is still a viable option.
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.
If you assume the (hypothetical and probably unlikely) case where an ISP
publishes SPF info and fails to provide smtp auth, then you are already
assuming the ISP doesn't care about the user. If you further assume that
they will charge *money* to use the Special smtp auth server, you are
stacking the deck in favor of "this ISP is crappy". (Also to note, it
looks like Mary got permission to use the campus relay without getting a
campus email address? That seems fishy.)
Anyway, none of this proves that SPF is bad. You probably don't believe
SPF is bad or you wouldn't be on the list right? :)
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.
I think most of the discussion on this list assumes that domains that
choose to publish SPF info are working in their own best interests and
those of the organization owning the domain. I don't think anyone is
"assuming" A or B. IT will either screw its users, pony up some additional
effort, or decline to participate in SPF. Same with ISP's.
I don't think anyone here (you included) is proposing that just because
some people "might" use SPF wrong that it should move forward. For
everyone who "might" use SPF wrong, there are probably 10+ more that
desparately need it and 100 more that will ignore SPF for the first few
years.
Let me try and turn this around and ask you some questions.
Do you think SPF if implemented as described will do more harm than good?
Do you think the needs of the powerless users being oppressed by a bad IT
or bad ISP should outweigh the needs of other domain owners that need tools
to use against spammers?
Do you have some constructive suggestions as to how SPF could be changed to
accomodate the situations you described here better?
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
-------
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_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡