From the MARID charter:
In <938B9C24-858D-11D8-A7E0-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton
<andy(_at_)hxr(_dot_)us> writes:
[....] the first task of the
working group will be to establish which of these identities
should be associated with MTA authorization. Once this
decision has been reached, it will limit the scope of further
activity in this working group,
It is my understanding that this first task has been finished. The
co-chairs feel that there is a rough consensus that we should work on
the RFC2821 data first, then the RFC2822 data.
May 04 Interim Meeting. Focus on required semantics for
MTA authorization; syntax discussions
Ok, so now we are supposed to be discussing semantics and syntax.
The semantics and syntax range from the very minimalist approaches of
FSV and DMP, to the most complex of the lot: SPF.
While SPF isn't an exact superset of the LMAP and C-ID proposals, it
is pretty close.
Having been involved with the SPF project for a long time, I doubt
that it comes as any surprise that I think the SPF proposal is a
reasonable choice for both the semantics and the syntax.
I believe that the SPF syntax and semantics can be expanded to handle
the likely RFC2822 validation schemes that we will consider (hopefully
in short order). I believe that SPF has a very nice combination of
features that is both expressive enough to handle most important
situations efficiently. Anything less expressive than SPF would not
be able to handle these cases. In particular, the ability to "debug"
your SPF record and get a feel for your domain's real email usage via
mechanisms such "exists:CL.%{i}.FR.%{s}.HE.%{h}.spf.%{d}" is a
critical feature that is not found in any other proposal.
I have analyzed the SPF features that are being used in the real
world, and there are very few that could be eliminated without hurting
a significant number of domain owners. Some features, such as the
IPv6 support, may take a while to become widely used, but I think they
should remain.
I don't think the ad-hoc syntax of SPF is a serious hurtle to
adoption. Writing a parser for it is really not very hard.
I don't think the realatively large semantic set of SPF is a serious
hurtle either. There are probably close to a dozen implementations of
SPF out there in various languages and they almost all do a very good
job of matching results on the vast majority of SPF records. Far more
work needs to be done on the SPF test suite to make sure that SPF
implementations match results even on the corner cases, but a lot of
progress is being made in that direction.
I think the install base of domains that have already published SPF
records is important and if the MARID records can be backwards
compatible with SPF, we would gain a lot.
So, what do people think? Can we use SPF as a basis for MARID
records?
-wayne