Stuart D. Gathman wrote:
On Mon, 12 Sep 2005, Theo Schlossnagle wrote:
If you join the board of you local home-owners association and they "add
you" to the alias. Any relatively small, relatively static group can
easily be placed into an aliases style forwarding where the members of
said group indeed want the email and yet did not formally request for
the alias to be set up.
If you want the homeowner mailings (and are willing to accept whatever
other garbage the association might inadvertantly send your way), you list the
forwarder (overlooking the rudeness). Otherwise you don't - and it gets
rejected.
If the association notices the rejections, they can ask
you about it, and you can either explain that you don't want to be
on the mailing list (this kind of aliasing amounts to a mailing list), or
you can point them at a mailman installation. They will be so wowed
at what a *real* mailing list can do - and so easy and user friendly, that
they
will immediately drop the aliasing and start using mailman. Incidently,
real mailing lists like mailman don't have SPF problems.
Really. I've done that - it really works like I described. People only use
aliases for mailing lists because they don't know of any alternatives. It
doesn't work well for the purpose.
I'm awareof mailman, I use it. The problem is that the small alias
expansion setups are wide spread. And It would costs untold resources
to try to teach people a different way of doing it. Basically, these
setups have worked for ages and you're proposing to break them.
Breaking them isn't a problem if it can be rectified solely by admins on
the endpoints, without cooperation of the forwarding admins (they don't
care) and without cooperation with the users sending or receiving as
that would be prohibitively expensive. It's my professional opinion
that this would be too expensive. We can see by the SPF community
proposing a SPF BCP guide that says admins need to work with users to
establish this information and see fast adoption occurs in the global
2000 and large/regional and local ISP markets.
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/
-------
Sender Policy Framework: http://spf.pobox.com/
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com