MM3 - Using fqdn in the exposed URLs
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?
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@.* 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
Richard Wackerbarth writes:
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.
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.
I think this is overblown. These email addresses are almost certainly easily available to spammers in other ways if they're going to be visible to the public in the web interfaces. (Consider List-Post, for example.) If we're going to be paranoid about this, we should also refuse to subscribe users with Microsoft browsers and MUAs on the grounds that they're far more likely to have their address books stolen. :-)
OTOH, a lot of people do worry about this. We should definitely consider getting those addresses out of the URLs to make it easier for the security-with-obscurity crowd to lock down their sites for any reason they choose.
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.
+1
It might be worth reviewing all the uses of URLs to see which ones can be dispensed with (ie, have such "slugs" substituted), and which ones are essential to functioning of Mailman (eg, List-Post, which may be suppressed at list-owner option, but if not, must contain the posting address).
On Jun 11, 2012, at 05:43 AM, Richard Wackerbarth wrote:
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.
I agree that the shorter-url argument is more compelling than the security-by-obscurity argument.
If the mapping need only happen in one direction, then something as simple as hashing the mlist fqdn and taking a substring would probably be good enough.
-Barry
Actually, the Django methodology would allow the website designer to choose any URL that she wishes. So, Postorius should be able to set a configuration parameter to any value that the designer chooses and "core" would just be echoing it.
Richard
On Jun 11, 2012, at 11:28 AM, Barry Warsaw wrote:
On Jun 11, 2012, at 05:43 AM, Richard Wackerbarth wrote:
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.
I agree that the shorter-url argument is more compelling than the security-by-obscurity argument.
If the mapping need only happen in one direction, then something as simple as hashing the mlist fqdn and taking a substring would probably be good enough.
-Barry
Hi,
We could change this part of the URLs to something like: <domain><delimiter><listname>. This way we can compose the full fqdn_listname from the URL but it's not as obvious as the list's email address (it's also still readable).
Adding to Richard's slug idea: We could provide a "slug"-field in the list settings (and create list) form. The default slug is the format described in 1) - but an admin can change it to any custom (and shorter) slug they like (as long as it's unique).
I suggest that we save the slug/fqdn_listname mapping in a local db table (it's only a ui specific setting, so the core doesn't need to know about it).
Cheers Florian
Am 12.06.12 05:06, schrieb Stephen J. Turnbull:
Barry Warsaw writes:
hashing the mlist fqdn and taking a substring would probably be good enough.
Ewwwwwwwwww!
-1
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/f%40state-of-mind....
Security Policy: http://wiki.list.org/x/QIA9
On Jun 12, 2012, at 5:16 AM, Florian Fuchs wrote:
We could change this part of the URLs to something like: <domain><delimiter><listname>. This way we can compose the full fqdn_listname from the URL but it's not as obvious as the list's email address (it's also still readable).
Adding to Richard's slug idea: We could provide a "slug"-field in the list settings (and create list) form. The default slug is the format described in 1) - but an admin can change it to any custom (and shorter) slug they like (as long as it's unique).
+1
I suggest that we save the slug/fqdn_listname mapping in a local db table (it's only a ui specific setting, so the core doesn't need to know about it).
Core will need to be provided a dictionary of items related to the configuration of the list infrastructure. The URL for subscriber account maintenance is one of those items. However, the contents of that field, or any of the others, and how they are derived, is outside the scope of "core". To core, these are just configuration constants.
Cheers Florian
On Jun 12, 2012, at 08:01 AM, Richard Wackerbarth wrote:
Core will need to be provided a dictionary of items related to the configuration of the list infrastructure. The URL for subscriber account maintenance is one of those items. However, the contents of that field, or any of the others, and how they are derived, is outside the scope of "core". To core, these are just configuration constants.
It does, and it's not difficult to add new variables, except for the nightmare (currently ongoing) of migrating the SQLite schema.
-Barry
Perhaps you should consider a different strategy that does not couple so tightly the SQL schema with the parameters.
Rather that having an object which tries to keep everything directly on the object, place many of those values in a dictionary and do (key, value) lookups on the dictionary rather expecting the key to be a property of the object itself.
That way, additional values can be associated with the object without changing the underlying database schema.
Richard
On Jun 12, 2012, at 9:58 AM, Barry Warsaw wrote:
On Jun 12, 2012, at 08:01 AM, Richard Wackerbarth wrote:
Core will need to be provided a dictionary of items related to the configuration of the list infrastructure. The URL for subscriber account maintenance is one of those items. However, the contents of that field, or any of the others, and how they are derived, is outside the scope of "core". To core, these are just configuration constants.
It does, and it's not difficult to add new variables, except for the nightmare (currently ongoing) of migrating the SQLite schema.
On Jun 12, 2012, at 10:19 AM, Richard Wackerbarth wrote:
Perhaps you should consider a different strategy that does not couple so tightly the SQL schema with the parameters.
Rather that having an object which tries to keep everything directly on the object, place many of those values in a dictionary and do (key, value) lookups on the dictionary rather expecting the key to be a property of the object itself.
That way, additional values can be associated with the object without changing the underlying database schema.
It's a good idea, and I've thought about that. The Pendings database is essentially that. Of course, switching to it is itself a schema migration. ;)
Maybe I should just renege on my beta1 promise ;).
-Barry
participants (6)
-
Barry Warsaw -
Florian Fuchs -
Richard Wackerbarth -
Richard Wackerbarth
-
Stephen J. Turnbull -
Toshio Kuratomi