On Sun, Jan 21, 2007 at 09:41:24PM -0500, Stuart D. Gathman wrote:
So I guess you are saying we should put off certifying anything until
we have some way of checking the entire application. I suppose we
could require source code and have some approved programmer make
a professional judgement. But the nice thing about certifying just
the SPF library is that the process is largely automated and objective -
even if the scope is limited.
No. If a message should pass, but doesn't, the implementor will
have to show why the message was rejected.
90% chance this is due to not being fully compliant. This will
be clear from their response. Maybe they need some tutoring,
but that's OK.
9% will reject for other reasons but still claim this to be
due to SPF. Clearly this is an implementation error. Chances
are the implementor will mumble "oops" and try again later.
The remaining 1% may result in changing the test slightly,
perhaps even for that particular implementation or circumstance.
Only these cases need more than just a small effort. At least
this 1% does not claim rejecting due to SPF (or else they belong
one paragraph above).
Please don't argue numbers here, unless you feel they are way off.
Here is an idea - maybe we can't practically test ahead of time for
mislabelling non-SPF results as SPF. But we *can* state in the rules that any
product caught doing so will immediately have its certification withdrawn,
and have some onerous process to get recertified.
You want to give everyone a free seal of approval, and revoke it
after we have shown that they didn't do a good job? Seriously?
By the way, a similar easy test where a mail should be rejected is
also easy to accomplish. Just swap "mail from" and "from". This
will (also) catch those implementations that only look at the body.
[I use RFC821 and RFC822 to avoid talking about envelope]
Point is: there is a significant difference in RFC821 and RFC822
addresses, and SPF was designed explicitly and with much effort
to only look at RFC821. Any implementation looking at RFC822
addresses in combination with SPFv1 records not only has a gross
misconception about the protocol but is also ignoring all those
years of development and testing; I even say it is insulting.
Not understanding layer separation is bad enough, but people that
don't care are worse.
Alex
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735