On 13 Jan 2004 Vivien M. <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com> wrote:
-----Original Message-----
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.
Correct.
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 owner is not the IT department. The owner is the corporation and the
management of this organization. The IT department must keep management
fully informed of the impact on the operations of any decisions that the
support organization takes. Many time the optimal IT solution is not
even a good solution for the rest of the organization.
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.
Right and this is where the rubber meets the road. There are a LOT of
road warriors out there doing company business that can be adversely
affected by a decision made by the IS group. An informed management
decision to do something based on all the facts is a lot different than
simply the IS support department making a decision.
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.
But once you make a decision like that you can very easily lose all of
his business. His only link to @isp.net is this email address he is
paying for, at least he's paying for something. Once you say he can't do
this anymore then then he'll bite the bullet and get the domain name and
forget about even paying for the use of the email address.
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.
Not always possible. Granted their is a lot of flexibility here but inn
many areas you are locked into a single, or and least very few, local
providers.
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.
But based on the discussion here and in many other forums on how people
believe this is a anti-spam tool you can readily see how many are
intending to use SFP.
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?
Not at all since I'm actually "forging" in the sense of SPF on almost
every message I send. That is, I am not sending via the SMTP server that
probably would be specified as the sending server for that domain in the
DNS. The MAIL FROM: domain address, probably does not match the From:
domain address and the SMTP server may be from a third domain. Not sure
that even this message does.
This does not mean that any of these messages are truly forged, it's
simply that I'm working as someone else for some reason at a different
site.
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_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
Thomas R. Stephenson, CPL Phone: (408) 742-3308
Lockheed Martin Technical Operations
MILSTAR Logistics Engineering O/M5-41 B/158
P.O. Box 61687 Sunnyvale, CA 94088-1687
Member Pegasus Mail Support Team
Thought for the day:
Press ALT-H for a special message from your SysOp!
-------
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;±¤Ö¤Íµø?¡