ietf-mxcomp
[Top] [All Lists]

Re: Sender-ID and free software

2004-07-24 14:23:55


(Michel, I am not a member of this list, so would you please
forward my message if it does not go through?)

Microsoft's Sender-ID license is directly incompatible with free
software regardless of which free software license is used.  Free
software means users are free to run it, study and modify the source,
and to redistribute it with or without changes.  Free to do so means
there is no requirement to ask or tell anyone that you are doing so.

The Microsoft license for Sender-ID directly forbids release of
software with all these freedoms, so it is impossible for any program
to be free software under Microsoft's regime.

I've been expecting to see something like this ever since Gates
started talking about spam.  This license is an example of Microsoft's
strategy for killing off free software as an alternative to Windows.
Microsoft first patents something, then incorporates it into a format
or protocol, then tries to make it de rigueur while excluding those it
wishes to exclude.  In the absence of resistance, Microsoft has a good
chance of imposing whatever standards it likes.  Let us, therefore,
resist it here and now.

Richard,

In the case of the PRA proposal, proponents have difficultly explaining
why this concept is better.  PRA ensures there is NO relief with respect
to network overhead, even if messages are rejected.  PRA ignores the
primary motivation for which identity is being spoofed, being a means to
avoid accreditation filtering, the RFC 2821 MAIL FROM.  If accreditation
is allowed to become more effective with CSV, this oversight is
significant.  A rather weakly supported claim is this will end phising. 
Support for PRA checks overlooks the identity significant to the user, and
that many techniques still exist to allow phising, some without the need
to publish DNS records by the entity committing the fraud.

There is also a potential for network instability caused by early
termination of a series of DNS queries, that both allow accumulation of
outstanding UDP traffic and necessitate the resending of the messages.  A
serious flaw made far worse with PRA.  As PRA has been isolated, envision
rejection of both the Submitter and PRA draft.  Take the BATV draft of
Dave Crocker and add a mode using an address based technique to include
the SPF record sets.  This would allow Forwarding and List Servers for the
most part to continue working, without the use of Submitter.  (EzMLM may
be an exception for signatures, but would still work with the SPF mode.)

Submitter and PRA should be rejected as being highly disruptive. Combine
SPF with BATV. Submitter and PRA fail to provide the most basic goal of
the MARID charter.  That is to authenticate (and authorize) the MTA domain
(responsible for policy as implied with DNS), as compared to CSV that
ignores filtering objectives of messages, but accomplishes the basic goal
of the charter.

-Doug


<Prev in Thread] Current Thread [Next in Thread>