[Mailman-Developers] MM3 - Using fqdn in the exposed URLs

[Toshio Kuratomi]

On Mon, Jun 11, 2012 at 05:43:33AM -0500, Richard Wackerbarth wrote:
> Are we making a design mistake?
> 
> The current design of the Postorius and Hyperkitty web interfaces to the mailing list and its archives uses the fully qualified list submission email address as a component of the URLs presented to the public.
> 
> Is this really a good idea?  Just think of the exposure that search engines, etc. will give to these email addresses. I fear that doing this will create an even greater invitation to those who harvest email addresses for the purpose of spamming and other nefarious reasons.
> 
> Additionally, in the most common usage case, it makes the URL significantly longer than it needs to be. In most cases, the website address determines the email domain of the associated lists. Only a few websites are serving mailing lists from multiple email domains. Those sites would need to have some mechanism to unambiguiously identify the list being referenced. But for most sites, the common name of the list is sufficient.
> 
> One of the design principles of Django is that the website designer can present his content by way of URLs of his choosing.
> 
> Presenting the actual email address of a list may "leak" information that the user wishes to obscure.
> 
> I think that we should rethink this decision and follow a "slug" approach to the identification of the mailing lists in URLs. Those who choose to do so can use the fqdn as their slug. But others would be able to readily change the mapping without having to rewrite significant parts of the interface code.
> 
> Comments?
>
I don't think I buy into the obscuring of information argument because the
mailing list already requires you to know the fqdn to send email to the
list but I definitely do see the convenience factor of having shorter slugs
for sites without lists for multiple domains.

A slug would be possible but probably should be defined at the mailman3 core
level similar to how the stable URL hash for emails is defined there.
Otherwise the list administrator has to enter it in multiple places and it
can be different between one app and another.  If I recall correctly, I was
asked by mailman3 for an unadorned version of the list name as well as the
fqdn when I set up a list.  So that could be used if the administrator knows
that there's no danger of collisions.

But how does the administrator know that?  I think that it's probably the
person who sets up postorius and the archiver rather than the person that
sets up mailman3 core that knows this (after all, in a distant future, we
could have webui's and archivers that can aggregate multiple mailman3
servers transparently for large sites with multiple departments).  So
perhaps we should have the front ends, not core, attempt to resolve non-fqdn
listaddresses.  If I'm given mailman-developers in my url, I do a search for
^mailman-developers at .* and if it comes up with one entry I redirect to the
fqdn (since I don't think that obscuring is necessary here, a redirect seems
appropriate).  If I come up with multiple entries, I ask the user to choose
from the list of possibilities.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20120611/1cb351d9/attachment.pgp>