While looking for something else, I stumbled across the following post
of my from Oct 10, 2003:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200310/0127.html
In it, I complain about the use of authenticate instead of authorize,
I ask for the HELO domain to be verified all the time, I ask a
question about the scope= modifier, which at that time had a
header-from option, I worry about i18n issues of the exp= modifier,
and a few other things that have come up in the last month or so.
Heh.
Some things never change. ;-)
From: wayne <wayne(_at_)midwestcs(_dot_)com>
Subject: Re: [spf-discuss] new draft RFC under construction
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Date: Fri, 10 Oct 2003 22:49:27 -0500
Reply-To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
In <20031010220236(_dot_)GZ2345(_at_)dumbo(_dot_)pobox(_dot_)com> Meng Weng
Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> writes:
1. Introduction
SMTP allows any client host to assert any sender email address.
Over time this vulnerability has been exploited to the extent that
it should be considered a significant security flaw. The Sender
Permitted From protocol introduces a voluntary convention which
helps to plug this hole.
I suspect that there will be many vocal people who will yell that
"this isn't a bug, it's a feature!"
I would suggest something like:
SMTP allows any client host to assert any sender email address.
Over time this lack of control of over how ones domain name is
used is now considered a significant security flaw by certain
domain owners. The Sender Permitted From protocol introduces a
voluntary convention which helps to give domain owners more
control over the use of their domain name.
This authentication is weaker than cryptographic systems
but stronger than the current SMTP model.
SPF does not authenticate anything, it authorizes the use of the
domain name by a given IP address. The IP address is authenenticated
via the sufficiently-random sequence numbers in the TCP packets. GPG
authenticates people, but does not provide any authorization. These
are two different concepts.
2. Designating SMTP Clients
Participating domains publish SPF records to indicate that only
certain hosts are permitted to send mail using that domain in the
envelope sender. In the case of a null envelope sender, the domain
from the HELO/EHLO command is tested instead.
Couldn't/shouldn't the HELO/EHLO domain be verified all the time?
"v=spf1" indicates compliance with version 1 of the SPF protocol.
I would recomend a version number being in the form of <major>.<minor>
rather than a text string.
Scope := "scope=" ( ( "" | "envelope" ) | "header-from" | "errors-to" )
)
By default, envelope scope is assumed.
What does a scope of "" do?
Explanation := "exp=" ( literal string of maximum length 128 characters )
this string MAY be used by SPF clients in an SMTP rejection
message.
it should contain text explaining the policy decision or a
URL to such text.
I'm not so sure about this exp thing. It opens up a huge can of worms
with respect to different languages and such. Is the limit 128
"characters", or 128 "bytes"? (UTF-32 is 4 bytes per character, IIRC.)
default-esd := ""
expanded by the SPF client to the sender-domain.
I don't understand this either....
ipv4-cidr-spec := standard IP number "/" cidr-range, eg. "127.0.0.1/8"
ipv6-cidr-spec := uh, the same thing, but for IPv6. I really have no idea
about this.
If we (tinw) are going to allow IPv6 specs (I think we should), then it will
probably be a lot less confusing if we (tinw) don't use the colon for
anything. IPv6 addresses, after all, make heavy use of the colon to
shorten up the numbers.
2.4.x LocalPart
the LocalPart specification is EXPERIMENTAL and may be defined
in future RFCs.
If it isn't defined in the current RFC, I think this option should be
dropped.
-wayne