----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, December 17, 2004 8:43 PM
Subject: RE: [spf-discuss] Paul G. Pierson
The lesson to draw from all this is that if you want to be effective in
propagating a standard you need to write test suites.
An SPF test suite would be very nice. It would also effecitvely mean that
control of the test suite was control over the spec.
Good point.
I'm sure, atleast for us, most serious developers will have their own test
suite for any product, utility or component in their system.
We have a SPF test suite which include about a 12-15 different scenarios,
maybe more, that include testing outside SPF itself but general programming
testing, i.e, making sure stack overflows do not occur EVEN before the SPF
limit of 20 recursions has occurred.
Anyway, I am willing to share what I deem are test scenarios that SPF
implementations should consider.
The IETF has done a lot of work on mailing lists, most of it entirely
wasted
because there was no advocacy, no follow through. There is also the
pervasive problem that if the IETF fiction is followed and nobody
represents
any view but his own then the specs were written by 30 bitheads to be used
by like bitheads.
Well, being that I come from the outside, I'm not corrupted with IETF
ideals, I see the problem more related to lack of delegation of work
between all sparse working groups.
What we need is "uncorrupted minds," people with vision to see the total
picture (old, new, ideal and practical) that can help "put it all together."
For example, where is the SMTP working group to help prepare developers
clean up the x821 specs getting it ready for stronger transaction management
protocols? Same with the 822 working group? What about CANSPAM and its
mandates for True Sender validation and Topic Identification? The federal
rule is written in stone people!
At some point, someone is going to have to "put it all together" defining
the new "hosting requirements."
With that said, back in July/2004, never having writing a draft, I sought
some guidance from some vets in how to optimize the presentation of such a
draft defining the new hosting requirement based on MARID.
I was basically told it was off-topic so forget about it.
Off-topic or not, I knew it was silly not to have such an effort that begins
to bring all the parties and ideas together, not only to consolidate the
ideas and new hosting requirements, but to better identify and squeeze out
the bad ideas as well, which was part of the main goals as well.
I still believe this needs to be done, especially if SPF is to become a
standard. Future Developers need to see this in the new x821 documents as
one of many new transaction management protocols.
Here is my abstract I showed to a few key people and was told it was off
topic.
MARID SMTP Server Design & Extensions:
A Functional Specification For
MARID and CANSPAM Compliant SMTP Servers and Clients
*draft outline*
Updated: July 03, 2004
Abstract
This memo defines extensions to the Simple Mail Transfer Protocol
(SMTP) protocol which allows a SMTP server and client to become
technically and legally compliant with MARID and CANSPAM.
MARID compliancy supports a new set of IETF proposed standards to
authorize the responsible sender of an e-mail message.
CANSPAM compliancy supports a new US Federal Law which offers a
functional model and mandate to reduce unsolicited e-mail by adding
accountability to the responsible sender of an e-mail message and to
provide message topic identification. Although CANSPAM is a US
Federal Law, the model presented by CANSPAM is considered to be
universal in its intent and overall goals. It is expected to be
followed world wide as a general model. This world wide adoption or
recognization of similar laws has already begun in other countries.
[1]
It is the intent of document to consolidate and merge all the CANSPAM
and MARID considerations required by an SMTP server and client to
provide a clear and working functional specification targeting
primarily SMTP developers, but in addition offer insight to Operators
and System Administrators.
This was deemed off topic - GO FIGURE!
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office