[ mailman-Bugs-835870 ] list create page needs full url

[SourceForge.net]

Bugs item #835870, was opened at 2003-11-04 12:16
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=835870&group_id=103

Category: Web/CGI
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Alberghini (uglor)
Assigned to: Nobody/Anonymous (nobody)
Summary: list create page needs full url

Initial Comment:
If you go to the list creation page without using the
full domain name of the server, then lists created via
the page will not use the full domain of the server for
internal URL's

For example, if someone in the domain example.com wants
to create a list on mailbox.example.com, they can just
type http://mailbox/mailman/create to be sent to the
list creation page.  If they create a list from that
URL, then all mailings sent out by that list (welcome
messages, list info, password reminders) will only use
the machine name, not the full machine and domain name.
 This results in broken links for anyone outside the
domain, like http://mailbox/mailman/listinfo/testlist.

----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-24 18:42

Message:
Logged In: YES 
user_id=12800

Here's a thought: if VIRTUAL_HOST_OVERVIEW is true, we can
refuse to create a list in a virtual domain we don't know
anything about.  If it's false, then I agree w/ ppsys, you
need to know what you're doing.

----------------------------------------------------------------------

Comment By: Richard Barrett (ppsys)
Date: 2003-11-05 14:17

Message:
Logged In: YES 
user_id=75166

Mailman determines the host on which to create a list from
the Host: header inserted by the origin browser into the
HTTP request and, if that is not present, it uses the
ServerName derived from the Apache server's httpd.conf.

The problem arises because the resolver on the machine
running the browser is adding what it determines is its
local domain to the hostname entered in the URL to form an
FQDN, which it then resolves the IP number of. However, that
FQDN is not finding its way back into the Host: header of
the request.

This has a number of consequence. Typically, it will break
Apache name-based virtual hosting because just a host's name
will not match the usual full FQDN ServerName in a
VirtualHost definition on the Apache server and typically
the default host will be the target of the request which may
well not be the intended host. 

It will also likely break the MM listinfo display of
listnames by virtual host if Apache name based virtual hosts
are being used.

Mailman's computation of the host on which it should create
the list breaks for exactly the same reason. I would argue
that this is right and proper.

Any other approach leaves the server side trying to second
guess what the resolver on the machine running the browser
did to form an FQDN which led to the connection to the
server's IP number. I suggest there is not a simple
algorithm that will reliably lead to this problem being
solved in the general case, which is why the Apache code
does not do it and why Mailman should not try to do it.

The answer is for people authorised to create lists to be
sufficiently aware as to not use just the hostname but the
FQDN in the URLs they use to create lists. One way to
enforce this is to use Apache name based virtual hosts so
that access to Mailman's CGI scripts is only available if
the requesting browser delivers a FQDN in the Host: request
header.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=835870&group_id=103