-----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
Thomas
R. Stephenson
Sent: January 13, 2004 11:30 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: Re[5]: [spf-discuss] Lawsuits, angry business
users, and SPF stupidity.
On 13 Jan 2004 Vivien M. <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com> wrote:
<SNIP a LOT>
We've already had a discussion on this list about this issue, and I
think the conclusion that was reached at the time was that SPF
assumes:
Of the list members as they were at the time maybe, a general
conclusion
maybe not.
Well, this is only a conclusion about assumptions. Honestly, having been at
the centre of the last debate (and I hope I'm not exaggerating my role
here?), this debate is more about assumptions than about technology.
Depending on what you assume about the nature of the problem, the nature of
the ISP/end-user relationship, etc, SPF is either a great step forward or a
great way to enslave people to the domain owners' greedy priorities.
I was going to post a series of six other assumptions that describe a
totally different view of the situation as those six, and from which the
obvious conclusion is that SPF is horrible, but I didn't feel that was too
necessary... Perhaps I was wrong, so below each point, I'll try to present
the opposite assumption.
A) Domain owners ought to be allowed to determine how their
domain is used (for email purposes)
All agree here. Some users of a domain though may disagree with the
implementation. Generally though they would take this up
with the owner
of the domain.
And here, one assumes that taking it up with the owner of the domain and
their staff is feasible. One can make the opposite assumption: namely, that
many domain owners are big organizations where a little end user can't reach
the SPF implementators to take it up with them.
B) All "legitimate" uses of a domain are known to the domain
owner - there is no grey area where mail is sent through
other SMTP servers, but ought to be considered legitimate
by the domain owner.
Could be. That CEO that's in another country and wants to send via
another's equipment using his domain name may be something that would
keep a lot of people from rejecting mail based on the
standard. I can
see a lot of grey areas where even the owner of the domain
may want to
make an exception to what they have in the DNS. Note this is
the owner
of the domain we are talking about, not the system admin.
;-) The BOFH
have a lot of authority but when it starts to interfere with
operations
and sales they have to back off.
I assumed that the owner of the domain was an organization more than a
person, so if you're talking about XYZ Corp, the domain owner is XYZ Corp's
IT department, and they presumably follow instructions (where necessary)
from XYZ's management.
The thing is, in the pro-SPF world view, that CEO would ask his/her IT
department to implement an SMTP AUTH - and, since he/she is the CEO, it'd
probably get done :P If instead of the CEO, we're talking about a travelling
support rep, that's where this assumption may fall apart.
C) Domain owners would not use SPF to harm their
users/customers
Not always a good assumption when we are talking about owners
like AOL,
RR and SBC. They simply don't always understand the impact
of some of
their decisions.
Agreed... But, if we assume that domain owners would use SPF to harm (or rip
off) their customers, then the rationale for SPF having little impact on
non-forgers is weakened.
Take the following situation: Joe Idiot has operated his small business
using an email address @isp.net. He upgraded to broadband, but keeps the
account with isp.net so he gets his business email. With SPF, isp.net must
provide him with a relay (or allow the broadband ISP's in its SPF record) -
if isp.net management wants to get a new BMW, they can tell Joe that the
SMTP AUTH relay service is $25/month. Assuming a time machine is not
available so he can go back in time and buy a domain like he SHOULD have,
Joe has two choices: pay up, or face serious disruption to his business
email. I'd say paying for the SMTP AUTH service is the cheaper alternative.
D) Users caught in the middle of SPF would be able to seek
redress (eg: an SMTP AUTH relay) from the domain owner
What about a SMTP AUTH from another SMTP host?
That's useless, isn't it, with SPF? SPF is about empowering domain owners,
and in our last discussion, that, I think, was conceded. The debate is
whether giving domain owners such control is beneficial or too steep a price
to pay to reduce forgeries.
E) Anyone who needs their own email-sending policy different
from the domain owner's should be using their own domain
Correct, if allowed by the people providing the connection.
But domain owners set policy, not connectivity providers. If Joe from above
gets joeidiot.com, HE (or his hosting provider) controls the SPF records. If
his hosting provider tries to pull the same trick as isp.net above, Joe can
switch to another hosting provider and move joeidiot.com with him.
Competition prevents/reduces the type of extortion possible when using the
ISP's domain name.
This assumption falls apart when you have situations like Joe's, where they
don't have their own domain, and it's logistically "too late" to switch.
F) Most domain hosting (and by domain hosting, I mean DNS
hosting, web hosting shops, etc) providers will give
domain customers the ability to set their own SPF policy
(as opposed to having the hosting provider set up a
boilerplate SPF record requiring the use of the hosting
provider's relay or something)
Generally correct, some are less than tightly wrapped and may
or may not
provide the correct tools.
Agreed, again... Considering how few hosting providers give direct control
over DNS records, you can make the assumption that hosting providers will
set a uniform SPF policy for all domains they host. That uniform SPF policy
could require customers to use the hosting provider's SMTP Relay.
Again, it's all about assumptions. For all we know, hosting providers will
let you put in an SPF record saying the SMTP server in your home office is
allowed to send for your domain - and for all we know, they won't.
If you assume those three things, then SPF makes perfect
sense as an
antiforgery mechanism. If, however, you believe that that
some of the
latter four are inaccurate, then obviously you're going to
have a lot
more of a problem with SPF.
Anti-forgery correct.
This is again a discussion we had before, and that we had agreed on at the
time. SPF is NOT about stopping spam, SPF is about stopping unauthorized
uses of a domain in email. And I don't think that goal can be debated...
That said, read the archives: this horse has been beaten,
killed, and
buried at least a couple of times before.
But the horse is going to keep climbing back out since there
are a lot of
people that are going to be affected by how this is going to be
implemented. We are not talking about anti-forgery now, we
are talking
about anti-spam. There appears to be some assumption that
mail from a
"forged" source is spam.
That would be, IMHO, a foolish assumption. Most REAL forgeries are spam, I'm
sure, but there are plenty of non-spam "grey" "forgeries" (in the SPF
definition) that SPF would classify as forgeries. The real debate is whether
the collateral damage and expense to the harmless "grey forgers" is
justified to stop the "black" forgers. And that, I think, can be debated
endlessly...
I see tagging mail as a forgery with it's received from a source not
specified by the domain owner. I cannot see rejecting mail
based on this
standard alone.
Tagging, though, is a logistical nightmare. And if you get an email that
"may be a forgery", wouldn't you doubt its contents, even though the real
person may have sent it through a way that wasn't approved by the domain
owner?
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