The most vocal objections to SPF have come from power users who want to
be able to send mail from their laptop anywhere they go.
The LocalPart mechanism was introduced to mollify them. Besides, it
seems like a good idea in general. However, I am reconsidering this
mechanism for two reasons.
1) Power users are likely to already have their own domain.
If they want to set default=allow, or not set anything at all, they can.
Power users who do not have their own domains could in theory ask
their ISP to opt them out using the LocalPart mechanism. In
practice, I do not expect ISPs to accommodate such requests.
RFC2360 section 2.10 is very relevant:
2.10 Handling of Protocol Options
Specifications with many optional features increase the complexity of
the implementation and the chance of non-interoperable
implementations. The danger is that different implementations may
specify some combination of options that are unable to interoperate
with each other.
As the document moves along the standard track, implementation
experience shall determine the need for each option. Implementation
shall show whether the option should be a mandatory part of the
protocol or remain an option. If an option is not implemented as the
document advances, it must be removed from the protocol before it
reaches draft standard status.
Therefore, options shall only be present in a protocol to address a
real requirement. For example, options can support future
extensibility of the protocol, a particular market, e.g., the
financial industry, or a specific network environment, e.g., a
network constrained by limited bandwidth. They shall not be included
as a means to "buy-off" a minority opinion. Omission of the optional
item shall have no interoperability consequences for the
implementation that does so.
2) There are two ways to map the space of legal localparts into DNS.
Neither is trivial.
The first, which involves rewriting, is technically challenging: we
would have to borrow or reinvent RFC3492.
The second is to just stuff the bytes into DNS and lean on RFC2181.
See http://www.faqs.org/rfcs/rfc2181.html
This is what the current draft does. However, another crowd of power
users, which perhaps counts some overlap with the first, is strongly
attached to the idea that the DNS should never have anything but
[a-z0-9.-] in it. This objection has some merit, because old DNS
servers may not support other characters; but that does not stand as
more than an implementation consideration. I have not seen a solid
rationale to support this tradition; I beseech those with open minds
to put aside the fondness of long custom and carefully reexamine the
issue. Strong attachment to old ideas is the reason the Pentagon has
twice as many bathrooms as it needs.
For these reasons, we may wish to consider eliminating the LocalPart
directive from the SPF draft.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡