-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim Lyon's got a new proposal out on IETF-MARID. If I understand correctly,
the chair has proposed that we settle the XML debate once and for all by
allowing people to propose difficult yet possible future extensions. Once
they all get posted, then the anti-XML people will propose how SPF syntax
can be extended to include that.
What I see so far is that their proposals are all way beyond the scope of
what SPF is trying to address: authentication.
Jim Lyon's recent proposal tries to transfer reputation or accreditation
from one person to another. For instance, he thinks that if abc.com sends
mail through hotmail.com, the owners of abc.com may or may not want that
mail to have the same rep/accred as hotmail.com. This is nonsense because
you can't transfer accred or rep based on how the email got there. The only
question is: Did this mail really come from abc.com or did hotmail.com just
make it up?
We can't allow extensibility into SPF or SenderID. The problem set is small,
and must remain small. As long as we keep the problem scope small and
well-defined, we will be able to create implementations and languages that
are compact and easily understood and managed. The chance of having every
implementation functioning 100% exactly the same is much greater if the
number of "features" is very small. If someone sees a problem that is
similar to SPF but not in the realm of SPF, let's push back and say, "Come
up with your own solution, but leave us out of it."
We can win the XML argument if we stick with authentication, authentication,
authentication, and don't allow anything else. I can see their arguments
falling apart as we approach detailed specifics.
- --
Jonathan M. Gardner
Mass Mail Systems Developer, Amazon.com
jonagard(_at_)amazon(_dot_)com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFA03y+BFeYcclU5Q0RAhUWAJ9E90rFbAUlbD7zYGONCdyyLpJ0gACZASnf
XXZ2fdIeR7eDKq9E+P8myQc=
=fgtj
-----END PGP SIGNATURE-----