Llooking at some of the Debian organization's basic documents as an
example, (see http://www.debian.org/social_contract ), I'm wondering if
we could do something similar.
Here is a very incomplete rough-draft of a set of similar documents,
made under the assumption that the council will soon convert into
some sort of "Messaging Authentication Standards Group".
Any comments or suggestions?
----------------------------------------------------------------------
Working documents for the Messaging Authentication Standards Group.
Our social contract:
====================
1. We will only endorse solutions that meet the MASG Protocol
Guidelines.
2.
3.
MASG Protocol Guidelines:
=========================
1. Protocols must not require the use of any licenses
which would have the effect of noticeably slowing deployment,
or have the effect of making implementation noticeably more
difficult.
Specifically, the protocol must not require the use of any
licenses which would mean that resulting implementations
would necessarily be incompatible with the Free Software
Foundation's Free Software Definition, Software in the
Public Interest's Debian Free Software Guidelines, the
Open Source Initiative's Open Source Definition, or
incompatible with either the latest version of the
Free Software Foundations's General Public License
or the Apache Software Foundation's Apache License.
2. It is generally inappropriate to require that a domain owner
opt out of an alternative interpretation of an authentication
record in to prevent an alternative interpretation from being used.
Protocols and their implementations must not do this by default.
3. Protocols must have been shown to be technically sound in theory.
4. Protocols must have proven themselves to be technically sound
in practice, through extensive real-world testing.
5. Protocols that can be used in more than one area should not
applied outside of their areas of effective use.
Position Statements:
====================
Classic SPF and forwarding:
---------------------------
Domain owners publishing SPF records tell the world under what
conditions they do and do not authorize the use of various Return-Path's
using their domain name.
SPF testing allows a receiver to refuse mail that is sent with a
Return-Path in a way not in accordance with the domain owner's policy.
One result of the above is that even messages originally sent
in accordance with the domain owner's policies might be rejected
if forwarded to a recipient who only pays attention to the policies
of the Return-Path's domain's owner.
However, there are solutions to this problem for all three parties:
1. The original sender: The original sending domain can
use a method such as SES or BATV to "sign" every outgoing
message, and include a corresponding "exists:" mechanism
in their domain's SPF record.
This will allow their messages to safely "punch through"
any classic forwarding system.
2. The forwarder: The forwarder can resend messages with a
valid Retun-Path, perhaps using SRS rewriting to do so.
3. The recipient: The recipient can white-list their known
forwarders.
We recommend that anyone who implements SPF testing on incoming
messages do the following:
1. Also implement SRS rewriting.
2. Allow users to individually white-list their known