On Sunday 12 November 2006 19:40, Alex van den Bogaerdt wrote:
On Sun, Nov 12, 2006 at 05:43:12PM +0000, K.J. Petrie (Instabook) wrote:
Summary:
Using "To:", "Cc:" and so on creates a loophole.
Using DNS is very inefficient.
Creating another protocol besides SRS may actually harm both.
Ok, let's row back a bit and take a look at the bigger picture. I think I can
see a way through. IMO, in a world where the standards are optional and
different standards may be adopted, a standard ought to contain mechanisms to
prevent undesirable effects at the point where it is applied. It should not
require adoption by third parties to avoid undesirable effects. My concern
about relying on SRS is that it gives the impression the problem has been
fixed when it hasn't, because one system administrator cannot know what
another will do. What I am looking for is a change to the standard which will
ensure that on a compliant system domain owners can see it as a solution
rather than a problem.
Maybe we don't need to specify a technical fix at all. Maybe all we need is
wording along the lines of:
"A compliant system SHOULD provide appropriate means for individual users to
perform reasonable configuration of SPF on their own accounts. When providing
such means, System Administrators MUST determine what is appropriate or
reasonable depending on the context in which the system operates. For
instance, on an MUA providing mailboxes to the public for incoming mail, it
might be appropriate to provide a control panel and reasonable to allow users
to have their own policies for implementing SPF results or even to turn off
SPF on their inbound mail account altogether. In a corporate context it might
be appropriate to have all such decisions implemented by the system
administrators in consultation with users, and reasonable for system
administrators to override users' wishes. System Administrators MUST NOT
permit user-configuration to an extent that would affect the benefits of SPF
for other users or systems."
It could be objected that this is just common sense, so why write it into the
standard? I think my answer is that it provides a reminder (to system admins)
and reassurance (to domain owners) that SPF should be used in a way that
conforms with common sense. It means systems adopting SPF can't claim
compliance unless they've at least considered the effects on users. It is
stating the obvious, but the obvious isn't always obvious to all until it's
been stated.
What do people think? Is this a workable approach?
K.J. Petrie.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735