--Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
I was not describing unauthorized usage. I was describing spontaneous
usage.
SPF essentially eliminates spontaneous scenarios, by virtue of requiring
pre-registration.
This is perhaps the essence of what I think Dave is trying to say.
My opinion (which is probably not unique) is that SPF and other IP-based
solutions are indeed a tradeoff. By using it you agree to give up
"spontaneous" usage, in exchange for higher levels of trust when using your
"planned" methods.
My opinion also is that the domain owner must make this decision on behalf
of all the users of the domain. If the domain owner says it is not an
appropriate usage, then it isn't. Folks who disagree with him can get
their own domain. Freedom of the press belongs to those who own presses.
I think I have had similar conversations before with Dave, so I'm pretty
sure Dave doesn't misunderstand the concept. My guess is that he just
disagrees with the philosophy of having to pick a sending plan ahead of
time and stick to it. Nothing wrong with that type of choice.
We should all be careful not to use terms that might be misinterpreted as
having a "negative" connotation. Terms like unauthorized, fake, spoof,
forged imply that the intent was malicious and that the user is trying to
be intentionally misleading or trying to use resources that aren't his.
Let's not go down that path. We can just label any usage as "unsupported
by the domain owner" and leave it at that.
Which makes the term "false positive" an interesting one. If you use SPF
as a test to see if the MTA's use of the name is "consistent with the
domain owner's published policies" then it is probably as accurate as the
implementation. If you assume that SPF is a perfect indicator of whether a
domain is being used "inappropriately" or "fraudulently" or any other
value-judgement, that is probably a flawed assumption.
It's a lot like saying that you cannot drop a postal letter into just any
ol' mailbox, because you would need to pre-register it with the
letter-carrier who will drop it in the delivery mail slot.
I submit that by converting the essential information to a metaphor
enhances its clarity, but doesn't do much for its accuracy. For example,
the postal service doesn't have 90% of its incoming letters sent postage
due with fake or missing return addresses.
We're sitting in a meeting. My friend is not a geek; they do not
administer domain names.
I need to send a message urgently. It's really important. I ask to send
a message from their pc, and set the rfc2822.From field to be my actual
email address.
Now, how is this scenario unreasonable and/or how can spf work
"correctly" in this real-world situation.
(By the way, the use of the term "correctly" also implies a value
judgement. If you want people to stop describing "spontaneous" usage as
"forged" or "unauthorized", then perhaps you could also avoid describing
the known limitations and tradeoffs of SPF as "incorrect"... Each side of
the value judgement game is equally inaccurate and unhelpful.)
The roaming problem is a well-known one with many different solutions, a
number of which could probably be used here.
A technical solution would be to reconfigure your friend's mail program to
send to your (company or isp) smtp-auth server and supply your smtp-auth
name and password. While this sounds like it might be inaccessible to
people, it's definitely something that non-technical people can be taught
to do - most ISP's have web pages posted telling customers how to configure
their own computers, so making the same change on someone else's computer
is not really magic -- just make sure your "friend" is OK with you changing
his settings and is capable of changing them back when you dash off to your
next meeting.
A less technical, more accessible solution would be to request web access
(OWA, squirrel mail, whatever) from your company or ISP.
The least technical of all would be to start your letter off with "HI I'M
AT SOMEONE ELSE'S COMPUTER PLEASE REPLY TO ME AT GCONNOR(_at_)GCONNOR(_dot_)DOM" I
have enough non-technical friends to tell you that this solution actually
works for many of them :)
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>