In <12570184(_dot_)1086570421(_at_)[10(_dot_)12(_dot_)1(_dot_)26]> Greg Connor
<gconnor(_at_)nekodojo(_dot_)org> writes:
So, for this reason I believe that SPF's strongest asset is not its
spec, but its people. The community of people that has sprung up
around SPF is a great cross-section of the email industry. Each of us
has our own concerns, constituents, agendas, etc., but we are all
united in a common cause: stop email forgery. For this cause we have
donated our ideas, time, energy, enthusiasm, and other resources.
Unfortunately, this merger has caused deep divisions in the SPF
community. Meng had previously run things pretty much by rough
consensus. When the XML issue last came up, it was rejected, pretty
much the way it has been rejected this time.
Personally, I have at least as many problems with the "caller-id
algorithm" to select the domain to check. It is rapidly changing, and
untested. It will require changes to most MUAs to correctly display
the verified address before it will become useful. It doesn't stop
bounces until after the "flag day". From what I know, the C-ID
algorithm breaks around 20% of the mailing lists, where-as SPF breaks
none.
For those who don't know, the most recent list of headers that the
"caller-id algorithm" checks for are:
From:
Sender:
Resent-From:
Resent-Sender:
Delivered-to:
X-Envelope-To:
Envelope-To:
Note that most of these headers are non-standard. (That is, they
aren't in the RFCs) No MUA currently displays most of these headers
in any form.
The Sender: header, at least on Unix systems, is removed when found in
a message submitted by the MUA, and added when the MTA thinks it is
needed. I have found quite a few messages with bogus Sender: headers
that appear to have been automatically added by slightly misconfigured
MTAs.
The "caller-id algorithm" is a mess.
If there are minor
differences between two expressions of the same idea, I believe it is
much more powerful to pick one and go with it, together, than to stick
to an idea that we think is superior, but turns a potential ally into
a competitor.
Yeah, but I don't think the differences between C-ID and SPF are
minor.
For what it is worth, there *are* a large number of things that I
would change in SPF if I could wave a wand and make them happen
(e.g. include: is badly named). I'm not pushing for those things to
be changed because the differences are minor and you are right that it
is better to come together and support one system.
So. Those are my reasons for supporting the New SPF. I hope that the
SPF support community will pull together under the common banner,
which is still "Stop email forgery".
I waited over a week after first learning about the merged SPF/C-ID
before I made up my mind about the New SPF. I wanted to consider the
technical and political issues.
I have made up my mind: I am very much against the new SPF. The use
of XML is out of the question, and the "caller-id" algorithm for
selecting the domain to verify is to vague and untested.
So Greg, will you pull together with what is apparently the rest of
us?
-wayne