I'll note that Microsoft is making incorrect statements regarding
its "SenderID" framework. In fact MARID IETF working group HAS NOT
"recommended to move forward with the framework as experimental",
such recomendation would have required consensus of the WG and in
fact majority of participants in the WG were completely against
Sender ID and PRA documents to become either experimental or
standard track RFC.
What did happen is that IETF Area Director "asked" individual
participants to submit their proposals to IETF for review by yet to be
formed IETF directorate that will then decide if they are worth moving
forward to become EXERIMENTAL RFC based on their value and based on if
they are or not in conflict with existing IETF standards.
http://www.pointnclickinc.com/articles09272004msftqanda.htm
--------------------------------------------------------------
Released by permission from Microsoft
Pointnclick, Inc Question:
In the last week, reports spread that the IETF MARID rejected SenderID,
then, on 9/21 MSFT stated that the IETF was in support SenderID. Then,
the IETF terminated MARID, the group reportedly lacking support for
SenderID authentication. Since the IETF's tepid support for SenderID was
cited by AOL as a problem for developing a unified standard, do you think
this opens the door to getting things back on track for a single standard
again?
Microsoft Answer:
To clarify, Sender ID has not been rejected by the IETF. In fact, before
it's closure, the IETF's MARID working group recommended to move forward
with the framework as experimental and have the industry begin to test the
proposal in real-world implementation.
MARID also recommended Sender ID include an alternative spoof checking
mechanism to the proposed PRA check to now also include a "MAIL FROM"
check. We believe MARID's proposal to allow multiple scopes in the
protocol is a reasonable approach to provide additional choice and
flexibility and we will be publishing a revised specification for the
industry later this week. We will continue our collaboration with
industry stakeholders to help move this important authentication protocol
forward.
AOL's decision to conduct only "MAIL FROM" checks as outlined in the
original SPF proposal reflects the kind of flexibility and room for choice
provided by the IETF?s recommendation to broaden Sender ID framework.
What's encouraging about AOL's announcement is that they will join us in
publishing both records and we continue to recommend that all mail senders
do the same.
Sender ID remains a very promising framework. We have been deeply engaged
with others in the industry to make changes to the spec that are
consistent with the recommendations made by the MARID working group
co-chairs early this month.
Moving forward, we also continue to believe complementary technologies
such as signing solutions and computational proofs will be important to
address other technical aspects of spam that these IP-based authentication
mechanisms do not address.