[Mailman-Users] Public/private archives problem.
Hi, I hope someone can help me with this: I am a web space reseller on a shared server. One of the features we get is mailman, which we offer to our clients. One thing I have noticed about it is that if a mailing list has a has a private archive, the address is http://clientdomain.com/mailman/private/listname, which is fine, but if the archive is public, then the address is http://myhostingprovidersservername.com/pipermail/listname - which is not fine :( This means that my clients can see the domain name of the underlying provider I am buying space off, and potentially they might jump ship. Is this something that can be fixed by me/the hosting provider, and if so, how? Many thanks, Tony -- Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Public/private archives problem.
I recently submitted a bug report on that: https://sourceforge.net/tracker/?func=detail&aid=784888&group_id=103&atid=100103 No response yet. Rob Quoting [EMAIL PROTECTED]: > Hi, > > I hope someone can help me with this: > I am a web space reseller on a shared server. > One of the features we get is mailman, which we offer to our clients. > > One thing I have noticed about it is that if a mailing list has a has a > private archive, the address is > http://clientdomain.com/mailman/private/listname, which is fine, but if > the archive is public, then the address is > http://myhostingprovidersservername.com/pipermail/listname - which is > not fine :( > > This means that my clients can see the domain name of the underlying > provider I am buying space off, and potentially they might jump ship. > > Is this something that can be fixed by me/the hosting provider, and if > so, how? > > Many thanks, > > > Tony > > > > -- > Mailman-Users mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/mailman-users > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > > This message was sent to: [EMAIL PROTECTED] > Unsubscribe or change your options at > http://mail.python.org/mailman/options/mailman-users/bronto%40csd-bes.net > -- Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
FW: [Mailman-Users] Public/private archives problem.
Forgot to copy to list - the reply defaulting to the sender caught me out :) -Original Message- From: Tony Butler [mailto:[EMAIL PROTECTED] On Behalf Of Tony Sent: 11 August 2003 22:53 To: 'Richard Barrett' Subject: RE: [Mailman-Users] Public/private archives problem. Hi Richard, > > Is there a reason the two are different? > > If I am honest, it is not immediately obvious to me why the > difference > in computing the hostname used in private and public archive > URLs. But > with a properly configured vanilla Mailman installation, the results > should be same in either case. LOL, thanks for your honesty. I see what you're saying about vanilla MM, but sadly I have to use the bananna flavoured version :/ > But you could check the 'Host name this list prefers for > email' option > on the General Options page of one of your problem lists (3rd > from last > option with MM 2.1.2). Does this look to be correct? I would > expect it to. Yes, this is correct. > > As you say, it could be how CPanel have integrated mm, or > it could be a > > configuration issue with how they set it up. > > There is fresh news. There is good news and there is bad news. > > The good news is that you are not alone. I have just fooled [..] > The bad news is that this looks like a built in 'feature' of the > current CPanel implementation. Deep joy :( Still, thanks for checking it out - it means I can at least eliminate my hosting provider from my enquiries > My guess is that the CPanel's own scripts are used by CPanel > in place > of the standard Mailman scripts to create new lists and that these > scripts set the list web_page_url and host_name attributes > directly but > without adding any matching add_virtualhost() calls to mm_cfg.py to > expand the VIRTUAL_HOSTS dictionary. Okey doke, so if I say to the Cpanel people that they "need to add matching add_virtualhost() calls to mm_cfg.py to expand the VIRTUAL_HOSTS dictionary." Then they should understand what that means, since they've been doing their own scripts? > This would not be a major surprise as the VIRTUAL_HOSTS dictionary > stuff now in Mailman is a MM 2.1.x introduction and CPanel basic > implementation predates it with MM 2.0.x. K. 2.1.2 was only recently added to Cpanel AFAIK > If I can find time I will look at the issue a bit harder but > right now I cannot see any easy solution for you. Basically it looks to > me like a rough edge on the CPanel implementation rather than a bug in Mailman. Thanks. An "easy" solution would be for private and public to do the same thing, but I'd still have to convince the Cpanel guys to implement and my hosting provider to upgrade :( You have been a great help already by getting me this far. Much appreciated. > You could try posting a query to one of support forums on > www.cpanel.com to see if one of their support people can > confirm/deny my hypothesis and hopefully offer a solution. Funnily enough, I'd just registered on their forums before I read your email. > Let me know how you get on. Will do. Kind regards, Tony -- Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Public/private archives problem.
The problem is resolved, with great help from Richard. For the sake of posterity, let the mailing list archives show: * Be sure you have proper virtual host mapping (add_virtualhost()) in mm_cfg.py; * Be sure that the list setting for "Host name this list prefers for email" is in fact your mail exchange address, not a base URL for browsing (which was my problem); * Run fix_url.py Thanks Rob Quoting Rob Brandt <[EMAIL PROTECTED]>: > Richard; > > Thanks for your help in this. I am going to email you a link to my > "testlist", > which you can log into as an administrator and see for yourself what the > problem is. My server does not run CPanel, so I don't think that's an issue > here. My server is sitting here next to my desk, so I have full control if > you > need any information. > > Best Regards > > Rob > > > Quoting Richard Barrett <[EMAIL PROTECTED]>: > > > Tony > > > > The questions I am asking are to elicit information that will > > distinguish between and identify whether there is a problem with (a) > > Mailman or (b) misconfiguration of Mailman or (c) third party > > modifications made to Mailman or (d) other aspects of the host system > > configuration such as the Apache server. > > > > You are complaining about links but I can interpret that in several > > ways: > > > > 1. whether the URL of concern is accepted and served by the Apache > > server when you think/prefer it should or should not be. > > > > 2. whether the URL of concern is found embedded in the HTML text of a > > web page generated by Mailman as either a static page or by a Mailman > > CGI script. > > > > 3. whether the URL of concern is found embedded in the HTML text of a > > web page generated by something other than Mailman as either a static > > page or as one delivered by a CGI script. > > > > I must have been having a stupid day as I was not entirely clear from > > either the referenced bug report or your initial post about which of > > these interpretations I should adopt. > > > > Now see further comments below. > > > > Richard > > > > On Monday, August 11, 2003, at 01:14 pm, Tony wrote: > > > > > Hi Richard, > > > > > > Quoting Richard Barrett <[EMAIL PROTECTED]>: > > >> Rob's bug report, as with yours, lack precision in specifying exactly > > >> which Mailman generated pages have links on them which contain (in the > > >> HTML text), absolute URLs referring to the wrong hostname. See my > > >> comments below on the broadfer questions that need to be answered in > > >> order to attack the perceived problem. > > > > > > Sorry, I thought it was clear enough. I will elaborate. > > > > > >> I do not work with it myself, but I believe that the CPanel virtual > > >> hosting support software, which your hosting provider may be using, > > >> does perform some trickery to help avoid conflicts between list names > > >> on different virtual hosts. If your hosting provider is using that and > > >> something related to it is misconfigured then this may be contributing > > >> to the problem. > > > > > > Correct. The list directory gets names _ to avoid > > > conflicts > > > with any other similarly named lists. CPanel is what is being used in > > > this > > > case. > > > > > > This means that any other virtual host on the server can access the > > > mail > > > archives by providing the correct path name to the list. > > > > > >> When you say "if the archive is public, then the address is > > >> http://myhostingprovidersservername.com/pipermail/listname"; what > > >> precisely do you mean? > > > > > > What I mean is that the link to the archives, and only this link, from > > > what I > > > can see, shows the hosting provider's server name and not the virtual > > > domain > > > for the client. > > > > > > Example: > > > I have a list called "test" on clientdomain1. > > > > > > The path to the list and all the admin pages etc is > > > http://clientdomain1/mailman//test_clientdomain1/ > > > > > > This list could also be accessed by another virtual domain on the same > > > server > > > as: > > > http://clientdomain2/mailman//test_clientdomain1/ > > > > > > When the archives are set to public, the archive address is: > > > http://clientdomain1/mailman/private/test_clientdomain1/ > > > > Did you mean the statement immediately above or are you just reflecting > > on the fact that a public list is still available through its private > > list URL? > > > > > > > > When the list archives are set to public, then the archive address is: > > > http://hostingproviderservername/pipermail/test_clientdomain1/ > > > > > > I would expect this to read: > > > http://clientdomain1/pipermail/test_clientdomain1/ > > > or similar. > > > > > > This appears the same on both the main page for the list and in the > > > admin > > > interface. > > > > > > > Just to confirm; do you mean the web pages returned by the URLs > > http://clientdomain1/mailman/listinfo/test_clientdomain1 and > > http://clientdomain1/mailman/admin/test_clientdomain1? > > > > I am no
RE: [Mailman-Users] Public/private archives problem.
Good for you Rob! Sadly, as you will see in the posts from Richard and I, that does not appear to be the problem in my case. I will report to Cpanel and see what they say > -Original Message- > From: Rob Brandt [mailto:[EMAIL PROTECTED] > Sent: 11 August 2003 13:43 > To: [EMAIL PROTECTED] > Subject: Re: [Mailman-Users] Public/private archives problem. > > > The problem is resolved, with great help from Richard. For > the sake of posterity, let the mailing list archives show: > > * Be sure you have proper virtual host mapping > (add_virtualhost()) in mm_cfg.py; > * Be sure that the list setting for "Host name this list > prefers for email" is in fact your mail exchange address, not > a base URL for browsing (which was my problem); > * Run fix_url.py > > Thanks > > Rob > > > > Quoting Rob Brandt <[EMAIL PROTECTED]>: > > > Richard; > > > > Thanks for your help in this. I am going to email you a link to my > > "testlist", which you can log into as an administrator and see for > > yourself what the problem is. My server does not run CPanel, so I > > don't think that's an issue here. My server is sitting > here next to > > my desk, so I have full control if you > > need any information. > > > > Best Regards > > > > Rob > > > > > > Quoting Richard Barrett <[EMAIL PROTECTED]>: > > > > > Tony > > > > > > The questions I am asking are to elicit information that will > > > distinguish between and identify whether there is a > problem with (a) > > > Mailman or (b) misconfiguration of Mailman or (c) third party > > > modifications made to Mailman or (d) other aspects of the host > > > system configuration such as the Apache server. > > > > > > You are complaining about links but I can interpret that > in several > > > ways: > > > > > > 1. whether the URL of concern is accepted and served by > the Apache > > > server when you think/prefer it should or should not be. > > > > > > 2. whether the URL of concern is found embedded in the > HTML text of > > > a web page generated by Mailman as either a static page or by a > > > Mailman CGI script. > > > > > > 3. whether the URL of concern is found embedded in the > HTML text of > > > a web page generated by something other than Mailman as either a > > > static page or as one delivered by a CGI script. > > > > > > I must have been having a stupid day as I was not entirely clear > > > from either the referenced bug report or your initial post about > > > which of these interpretations I should adopt. > > > > > > Now see further comments below. > > > > > > Richard > > > > > > On Monday, August 11, 2003, at 01:14 pm, Tony wrote: > > > > > > > Hi Richard, > > > > > > > > Quoting Richard Barrett <[EMAIL PROTECTED]>: > > > >> Rob's bug report, as with yours, lack precision in specifying > > > >> exactly which Mailman generated pages have links on them which > > > >> contain (in the HTML text), absolute URLs referring to > the wrong > > > >> hostname. See my comments below on the broadfer questions that > > > >> need to be answered in order to attack the perceived problem. > > > > > > > > Sorry, I thought it was clear enough. I will elaborate. > > > > > > > >> I do not work with it myself, but I believe that the CPanel > > > >> virtual hosting support software, which your hosting > provider may > > > >> be using, does perform some trickery to help avoid conflicts > > > >> between list names on different virtual hosts. If your hosting > > > >> provider is using that and something related to it is > > > >> misconfigured then this may be contributing to the problem. > > > > > > > > Correct. The list directory gets names _ to > > > > avoid conflicts with any other similarly named lists. > CPanel is > > > > what is being used in this > > > > case. > > > > > > > > This means that any other virtual host on the server can access > > > > the mail archives by providing the correct path name to > the list. > > > > > > > >> When you say "if the archive is public, then the address is > > > >> > http://myhostingpro
Re: [Mailman-Users] Public/private archives problem.
Tony
The questions I am asking are to elicit information that will
distinguish between and identify whether there is a problem with (a)
Mailman or (b) misconfiguration of Mailman or (c) third party
modifications made to Mailman or (d) other aspects of the host system
configuration such as the Apache server.
You are complaining about links but I can interpret that in several
ways:
1. whether the URL of concern is accepted and served by the Apache
server when you think/prefer it should or should not be.
2. whether the URL of concern is found embedded in the HTML text of a
web page generated by Mailman as either a static page or by a Mailman
CGI script.
3. whether the URL of concern is found embedded in the HTML text of a
web page generated by something other than Mailman as either a static
page or as one delivered by a CGI script.
I must have been having a stupid day as I was not entirely clear from
either the referenced bug report or your initial post about which of
these interpretations I should adopt.
Now see further comments below.
Richard
On Monday, August 11, 2003, at 01:14 pm, Tony wrote:
Hi Richard,
Quoting Richard Barrett <[EMAIL PROTECTED]>:
Rob's bug report, as with yours, lack precision in specifying exactly
which Mailman generated pages have links on them which contain (in the
HTML text), absolute URLs referring to the wrong hostname. See my
comments below on the broadfer questions that need to be answered in
order to attack the perceived problem.
Sorry, I thought it was clear enough. I will elaborate.
I do not work with it myself, but I believe that the CPanel virtual
hosting support software, which your hosting provider may be using,
does perform some trickery to help avoid conflicts between list names
on different virtual hosts. If your hosting provider is using that and
something related to it is misconfigured then this may be contributing
to the problem.
Correct. The list directory gets names _ to avoid
conflicts
with any other similarly named lists. CPanel is what is being used in
this
case.
This means that any other virtual host on the server can access the
mail
archives by providing the correct path name to the list.
When you say "if the archive is public, then the address is
http://myhostingprovidersservername.com/pipermail/listname"; what
precisely do you mean?
What I mean is that the link to the archives, and only this link, from
what I
can see, shows the hosting provider's server name and not the virtual
domain
for the client.
Example:
I have a list called "test" on clientdomain1.
The path to the list and all the admin pages etc is
http://clientdomain1/mailman//test_clientdomain1/
This list could also be accessed by another virtual domain on the same
server
as:
http://clientdomain2/mailman//test_clientdomain1/
When the archives are set to public, the archive address is:
http://clientdomain1/mailman/private/test_clientdomain1/
Did you mean the statement immediately above or are you just reflecting
on the fact that a public list is still available through its private
list URL?
When the list archives are set to public, then the archive address is:
http://hostingproviderservername/pipermail/test_clientdomain1/
I would expect this to read:
http://clientdomain1/pipermail/test_clientdomain1/
or similar.
This appears the same on both the main page for the list and in the
admin
interface.
Just to confirm; do you mean the web pages returned by the URLs
http://clientdomain1/mailman/listinfo/test_clientdomain1 and
http://clientdomain1/mailman/admin/test_clientdomain1?
I am now talking about plain vanilla, unmodified, MM 2.1.2 code. The
GetBaseArchiveURL() function used to generate the links to both public
and private list archives. Its operation is subtly different in two
cases although both depend upon the values in the VIRTUAL_HOSTS
dictionary which is conventionally constructed by calls to the
add_virtualhosts() function in the MM configuration file mm_cfg.py.
In the case of a public archive, the function does a lookup for the
list's host_name attribute (visible/editable on the General Options
page of the list) in an inversion of the VIRTUAL_HOSTS dictionary. The
actual statement that forms the URL is:
url = mm_cfg.PUBLIC_ARCHIVE_URL % {
'listname': self.internal_name(),
'hostname': inv.get(self.host_name, mm_cfg.DEFAULT_URL_HOST),
}
This works reliably on vanilla MM installation with a correctly set up
VIRTUAL_HOSTS dictionary, so long as each URL_FQDN key in the
dictionary is associated with a unique EMAIL_FQDN value.
If the list's host_name is not found then the DEFAULT_URL_HOST value,
which is likely to be that of your myhostingprovidersservername.com,
will be used.
I have no idea as to how CPanel integrates with Mailman or how the
mm_cfg.py Mailman configuration file is maintained as new domains are
hosted by a server on the system you are depending on.
My best guess is that something that sh
Re: [Mailman-Users] Public/private archives problem.
Hi Richard, Quoting Richard Barrett <[EMAIL PROTECTED]>: > Rob's bug report, as with yours, lack precision in specifying exactly > which Mailman generated pages have links on them which contain (in the > HTML text), absolute URLs referring to the wrong hostname. See my > comments below on the broadfer questions that need to be answered in > order to attack the perceived problem. Sorry, I thought it was clear enough. I will elaborate. > I do not work with it myself, but I believe that the CPanel virtual > hosting support software, which your hosting provider may be using, > does perform some trickery to help avoid conflicts between list names > on different virtual hosts. If your hosting provider is using that and > something related to it is misconfigured then this may be contributing > to the problem. Correct. The list directory gets names _ to avoid conflicts with any other similarly named lists. CPanel is what is being used in this case. This means that any other virtual host on the server can access the mail archives by providing the correct path name to the list. > When you say "if the archive is public, then the address is > http://myhostingprovidersservername.com/pipermail/listname"; what > precisely do you mean? What I mean is that the link to the archives, and only this link, from what I can see, shows the hosting provider's server name and not the virtual domain for the client. Example: I have a list called "test" on clientdomain1. The path to the list and all the admin pages etc is http://clientdomain1/mailman//test_clientdomain1/ This list could also be accessed by another virtual domain on the same server as: http://clientdomain2/mailman//test_clientdomain1/ When the archives are set to public, the archive address is: http://clientdomain1/mailman/private/test_clientdomain1/ When the list archives are set to public, then the archive address is: http://hostingproviderservername/pipermail/test_clientdomain1/ I would expect this to read: http://clientdomain1/pipermail/test_clientdomain1/ or similar. This appears the same on both the main page for the list and in the admin interface. > Or are there links on other pages on the server that have the > 'defective' domain in their URLs? No. > To get much further with diagnosing the problem will need a bit more > input from you. I hope I have provided enough info for you - if not, please tell me what else you need to know. many thanks, Tony -- Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ This message was sent to: [EMAIL PROTECTED] Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Public/private archives problem.
On Monday, August 11, 2003, at 10:31 am, Tony wrote:
Hi Tokio,
I checked out Rob's bug report and he says that he tried fix_url, but
it only
worked for private archives, not for the public ones :(
Rob's bug report, as with yours, lack precision in specifying exactly
which Mailman generated pages have links on them which contain (in the
HTML text), absolute URLs referring to the wrong hostname. See my
comments below on the broadfer questions that need to be answered in
order to attack the perceived problem.
Thanks for the suggestion though.
Tony
Quoting Tokio Kikuchi <[EMAIL PROTECTED]>:
Hi,
You should state your urlhost/emailhost pairs in mm_cfg.py like;
add_virtualhost('www.virtual.dom', 'mail.virtual.dom')
then use fix_url.py.
Rob Brandt wrote:
I recently submitted a bug report on that:
https://sourceforge.net/tracker/?
func=detail&aid=784888&group_id=103&atid=100103
No response yet.
Rob
Quoting [EMAIL PROTECTED]:
Hi,
I hope someone can help me with this:
I am a web space reseller on a shared server.
One of the features we get is mailman, which we offer to our
clients.
One thing I have noticed about it is that if a mailing list has a
has a
private archive, the address is
http://clientdomain.com/mailman/private/listname, which is fine,
but if
the archive is public, then the address is
http://myhostingprovidersservername.com/pipermail/listname - which
is
not fine :(
The cause of this is likely to be in the configuration of the Apache
server servicing the virtual hosts concerned rather than it being a
Mailman problem per se.
I'm assuming that named virtual hosting is being used by the Apache
server concerned so that clientdomain.com and
myhostingprovidersservername.com resolve to the same IP number.
Unless the Apache server has some special provisions made in its
configuration/operation the pipermail archives, which are served as
regular web pages by Apache without the intervention of Mailman
specific CGI programs, will be equally visible through any of the
hostnames that resolve to the same IP that
myhostingprovidersservername.com resolves to. If this is the case then
any of the public lists is potentially visible through any of the named
virtual hosts supported by Apache on the same IP number.
I do not work with it myself, but I believe that the CPanel virtual
hosting support software, which your hosting provider may be using,
does perform some trickery to help avoid conflicts between list names
on different virtual hosts. If your hosting provider is using that and
something related to it is misconfigured then this may be contributing
to the problem.
When you say "if the archive is public, then the address is
http://myhostingprovidersservername.com/pipermail/listname"; what
precisely do you mean?
Do the links to list archives for a given virtual host on the
/mailman/listinfo and /mailman/admin and other /mailman/ CGI
generated pages for that host have URL's that refer to the
myhostingprovidersservername.com rather than clientdomain.com host?
Or are there links on other pages on the server that have the
'defective' domain in their URLs?
If you look at the source of MM's pipermail archive pages you will find
that for the most part the generated links on those pages are server
relative, the main exception being (with MM2.1.2) to extracted
attachment files. So once started on a link specifying the 'wrong'
hostname, links on pages then reached also appear to be 'wrong'.
To get much further with diagnosing the problem will need a bit more
input from you.
This means that my clients can see the domain name of the underlying
provider I am buying space off, and potentially they might jump
ship.
Is this something that can be fixed by me/the hosting provider, and
if
so, how?
Many thanks,
Tony
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: [EMAIL PROTECTED]
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/tony-mm%
40arielbusiness.com
--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: [EMAIL PROTECTED]
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/
r.barrett%40openinfo.co.uk
--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mai
Re: [Mailman-Users] Public/private archives problem.
Forgot to copy list on this: Begin forwarded message: From: Richard Barrett <[EMAIL PROTECTED]> Date: Mon Aug 11, 2003 6:09:10 pm Europe/London To: Tony <[EMAIL PROTECTED]> Subject: Re: [Mailman-Users] Public/private archives problem. Tony On Monday, August 11, 2003, at 04:50 pm, Tony wrote: Hi Richard, Quoting Richard Barrett <[EMAIL PROTECTED]>: I must have been having a stupid day as I was not entirely clear from either the referenced bug report or your initial post about which of these interpretations I should adopt. Nah, I'm sure it's down to the way I wrote it :/ We all have off days. Example: I have a list called "test" on clientdomain1. The path to the list and all the admin pages etc is http://clientdomain1/mailman//test_clientdomain1/ This list could also be accessed by another virtual domain on the same server as: http://clientdomain2/mailman//test_clientdomain1/ When the archives are set to public, the archive address is: http://clientdomain1/mailman/private/test_clientdomain1/ Did you mean the statement immediately above or are you just reflecting on the fact that a public list is still available through its private list URL? No, I was being stupid. The above statement should have read: When the archives are set to public, the archive address is: http://hostingproviderservername/pipermail/test_clientdomain1/ This appears the same on both the main page for the list and in the admin interface. Just to confirm; do you mean the web pages returned by the URLs http://clientdomain1/mailman/listinfo/test_clientdomain1 and http://clientdomain1/mailman/admin/test_clientdomain1? Yes, these are the pages that report the archive location to br the hostingproviderservername address. I am now talking about plain vanilla, unmodified, MM 2.1.2 code. The GetBaseArchiveURL() function used to generate the links to both public and private list archives. Its operation is subtly different in two cases although both depend upon the values in the VIRTUAL_HOSTS dictionary which is conventionally constructed by calls to the add_virtualhosts() function in the MM configuration file mm_cfg.py. [] What is happening in the case of a private archive that the 'correct' host name is being returned? When generating a reference to a private archive the GetBaseArchiveURL() function uses a different list attribute called web_page_url. The standard MM 2.1.2 web creation scripts, both web and command line, set web_page_url and host_name in a compatible way. So too does the the fix_url script referred to by earlier posts on this subject. Is there a reason the two are different? If I am honest, it is not immediately obvious to me why the difference in computing the hostname used in private and public archive URLs. But with a properly configured vanilla Mailman installation, the results should be same in either case. What would happen if they were both the same? Unfortunately, I am not in a position to check out what is being done on the server, since I am merely a client and have bugger all access to the server :( But you could check the 'Host name this list prefers for email' option on the General Options page of one of your problem lists (3rd from last option with MM 2.1.2). Does this look to be correct? I would expect it to. As you say, it could be how CPanel have integrated mm, or it could be a configuration issue with how they set it up. There is fresh news. There is good news and there is bad news. The good news is that you are not alone. I have just fooled around with a demo CPanel facility of a web hosting supplier. Lo and behold the the links to the list archives - the /pipermail URLs - switch from the virtual host name to the base server host name; see: http://free-try-before-buy.com/mailman/listinfo/delist_free-try- before-buy.com and follow the list archive link. Lo and behold you get to: http://server.6np.net/pipermail/delist_free-try-before-buy.com/ although the 'desired' URL works OK: http://free-try-before-buy.com/pipermail/delist_free-try-before- buy.com/ The bad news is that this looks like a built in 'feature' of the current CPanel implementation. My guess is that the CPanel's own scripts are used by CPanel in place of the standard Mailman scripts to create new lists and that these scripts set the list web_page_url and host_name attributes directly but without adding any matching add_virtualhost() calls to mm_cfg.py to expand the VIRTUAL_HOSTS dictionary. This would not be a major surprise as the VIRTUAL_HOSTS dictionary stuff now in Mailman is a MM 2.1.x introduction and CPanel basic implementation predates it with MM 2.0.x. If I can find time I will look at the issue a bit harder but right now I cannot see any easy solution for you. Basically it looks to me like a rough edge on the CPanel implementation rather than a bug in > M
Re: [Mailman-Users] Public/private archives problem.
Richard; Thanks for your help in this. I am going to email you a link to my "testlist", which you can log into as an administrator and see for yourself what the problem is. My server does not run CPanel, so I don't think that's an issue here. My server is sitting here next to my desk, so I have full control if you need any information. Best Regards Rob Quoting Richard Barrett <[EMAIL PROTECTED]>: > Tony > > The questions I am asking are to elicit information that will > distinguish between and identify whether there is a problem with (a) > Mailman or (b) misconfiguration of Mailman or (c) third party > modifications made to Mailman or (d) other aspects of the host system > configuration such as the Apache server. > > You are complaining about links but I can interpret that in several > ways: > > 1. whether the URL of concern is accepted and served by the Apache > server when you think/prefer it should or should not be. > > 2. whether the URL of concern is found embedded in the HTML text of a > web page generated by Mailman as either a static page or by a Mailman > CGI script. > > 3. whether the URL of concern is found embedded in the HTML text of a > web page generated by something other than Mailman as either a static > page or as one delivered by a CGI script. > > I must have been having a stupid day as I was not entirely clear from > either the referenced bug report or your initial post about which of > these interpretations I should adopt. > > Now see further comments below. > > Richard > > On Monday, August 11, 2003, at 01:14 pm, Tony wrote: > > > Hi Richard, > > > > Quoting Richard Barrett <[EMAIL PROTECTED]>: > >> Rob's bug report, as with yours, lack precision in specifying exactly > >> which Mailman generated pages have links on them which contain (in the > >> HTML text), absolute URLs referring to the wrong hostname. See my > >> comments below on the broadfer questions that need to be answered in > >> order to attack the perceived problem. > > > > Sorry, I thought it was clear enough. I will elaborate. > > > >> I do not work with it myself, but I believe that the CPanel virtual > >> hosting support software, which your hosting provider may be using, > >> does perform some trickery to help avoid conflicts between list names > >> on different virtual hosts. If your hosting provider is using that and > >> something related to it is misconfigured then this may be contributing > >> to the problem. > > > > Correct. The list directory gets names _ to avoid > > conflicts > > with any other similarly named lists. CPanel is what is being used in > > this > > case. > > > > This means that any other virtual host on the server can access the > > mail > > archives by providing the correct path name to the list. > > > >> When you say "if the archive is public, then the address is > >> http://myhostingprovidersservername.com/pipermail/listname"; what > >> precisely do you mean? > > > > What I mean is that the link to the archives, and only this link, from > > what I > > can see, shows the hosting provider's server name and not the virtual > > domain > > for the client. > > > > Example: > > I have a list called "test" on clientdomain1. > > > > The path to the list and all the admin pages etc is > > http://clientdomain1/mailman//test_clientdomain1/ > > > > This list could also be accessed by another virtual domain on the same > > server > > as: > > http://clientdomain2/mailman//test_clientdomain1/ > > > > When the archives are set to public, the archive address is: > > http://clientdomain1/mailman/private/test_clientdomain1/ > > Did you mean the statement immediately above or are you just reflecting > on the fact that a public list is still available through its private > list URL? > > > > > When the list archives are set to public, then the archive address is: > > http://hostingproviderservername/pipermail/test_clientdomain1/ > > > > I would expect this to read: > > http://clientdomain1/pipermail/test_clientdomain1/ > > or similar. > > > > This appears the same on both the main page for the list and in the > > admin > > interface. > > > > Just to confirm; do you mean the web pages returned by the URLs > http://clientdomain1/mailman/listinfo/test_clientdomain1 and > http://clientdomain1/mailman/admin/test_clientdomain1? > > I am now talking about plain vanilla, unmodified, MM 2.1.2 code. The > GetBaseArchiveURL() function used to generate the links to both public > and private list archives. Its operation is subtly different in two > cases although both depend upon the values in the VIRTUAL_HOSTS > dictionary which is conventionally constructed by calls to the > add_virtualhosts() function in the MM configuration file mm_cfg.py. > > In the case of a public archive, the function does a lookup for the > list's host_name attribute (visible/editable on the General Options > page of the list) in an inversion of the VIRTUAL_HOSTS dictionary. The > actual statement that forms the URL is: > >url = mm_cfg
Re: [Mailman-Users] Public/private archives problem.
Hi,
You should state your urlhost/emailhost pairs in mm_cfg.py like;
add_virtualhost('www.virtual.dom', 'mail.virtual.dom')
then use fix_url.py.
Rob Brandt wrote:
I recently submitted a bug report on that:
https://sourceforge.net/tracker/?func=detail&aid=784888&group_id=103&atid=100103
No response yet.
Rob
Quoting [EMAIL PROTECTED]:
Hi,
I hope someone can help me with this:
I am a web space reseller on a shared server.
One of the features we get is mailman, which we offer to our clients.
One thing I have noticed about it is that if a mailing list has a has a
private archive, the address is
http://clientdomain.com/mailman/private/listname, which is fine, but if
the archive is public, then the address is
http://myhostingprovidersservername.com/pipermail/listname - which is
not fine :(
This means that my clients can see the domain name of the underlying
provider I am buying space off, and potentially they might jump ship.
Is this something that can be fixed by me/the hosting provider, and if
so, how?
Many thanks,
Tony
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: [EMAIL PROTECTED]
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Re: [Mailman-Users] Public/private archives problem.
Hi Tokio,
I checked out Rob's bug report and he says that he tried fix_url, but it only
worked for private archives, not for the public ones :(
Thanks for the suggestion though.
Tony
Quoting Tokio Kikuchi <[EMAIL PROTECTED]>:
> Hi,
>
> You should state your urlhost/emailhost pairs in mm_cfg.py like;
>
> add_virtualhost('www.virtual.dom', 'mail.virtual.dom')
>
> then use fix_url.py.
>
>
> Rob Brandt wrote:
>
> > I recently submitted a bug report on that:
> >
> https://sourceforge.net/tracker/?
func=detail&aid=784888&group_id=103&atid=100103
> >
> > No response yet.
> >
> > Rob
> >
> >
> >
> > Quoting [EMAIL PROTECTED]:
> >
> >
> >>Hi,
> >>
> >>I hope someone can help me with this:
> >>I am a web space reseller on a shared server.
> >>One of the features we get is mailman, which we offer to our clients.
> >>
> >>One thing I have noticed about it is that if a mailing list has a has a
> >>private archive, the address is
> >>http://clientdomain.com/mailman/private/listname, which is fine, but if
> >>the archive is public, then the address is
> >>http://myhostingprovidersservername.com/pipermail/listname - which is
> >>not fine :(
> >>
> >>This means that my clients can see the domain name of the underlying
> >>provider I am buying space off, and potentially they might jump ship.
> >>
> >>Is this something that can be fixed by me/the hosting provider, and if
> >>so, how?
> >>
> >>Many thanks,
> >>
> >>
> >>Tony
> >>
>
> --
> Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
> http://weather.is.kochi-u.ac.jp/
>
>
> --
> Mailman-Users mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
>
> This message was sent to: [EMAIL PROTECTED]
> Unsubscribe or change your options at
> http://mail.python.org/mailman/options/mailman-users/tony-mm%
40arielbusiness.com
>
--
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: [EMAIL PROTECTED]
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
