G'Day All,
> I've a similar situation, more virtual domains on a single box, someone
> with different IP address, using -l <myname> with no problem.
> Did you use the following enable-option?
> --enable-ip-alias-domains=y|n enable virtual domain lookup via reverse ip
> address lookup for virtual domains. "
Yes i did. And so when i use the -l <machine name>, this actually
will stop the reverse lookup as my users only put in their username.
However another suggestion which was the -H -R has made a huge difference.
Thanks All for your help.
Regards
Nathan
> I did not use it (i.e. = "n"). My users always put the complete name
> (user@domain) as pop user, so I don't see the need for this flag.
> Probably, if your are using this enable-option, or you need to turn back to
> "-l 0", or disable it (--enable-ip-alias-domains=n), or set up a different
> tcpserver for each address.
>
> Hope this helps.
>
> Tonino
>
> At 11/05/2001 11/05/2001 +1000, Nathan Chan wrote:
> >G'Day Guys,
> >
> >I've tried to add the -l hostname parameter, but ran into a problem.
> >As soon as i add that in, it starts failing authorisation for my virtual
> >domains. eg. my box domain works fine, but the virtual domains
> >(which each have their own individual ip and hence require a reverse
> >lookup to determine what their domain is) no longer works.
> >
> >Any further ideas ?
> >
> >Thanks
> >Nathan
> >
> >PS. When i did add the -l for the box domain, it was lightning fast
> >!! ;)
> >
> >
> > > Usually, when there is a changeable parameter, like -l hostname, it means
> > > that you may use it accordingly to your needs and to the rules (man
> > > tcpserver and tcpserver source give the rules to me). I can't be forced to
> > > use the common choice because Dan wrote this way.
> > >
> > > So, in my opinion, for debugging purposes, for knowing which tcpserver is
> > > answering, for thousands of other reasons, you may use it as you want, as
> > > long as you know what you're doing (otherwise use the common choice).
> > >
> > > At 10/05/2001 10/05/2001 -0400, Ed Henderson wrote:
> > > > From Dan Bernstein's site for tcpserver
> > > > (http://cr.yp.to/ucspi-tcp/tcpserver.html ):
> > > >
> > > >-l localname: Do not look up the local host name in DNS; use localname
> > for
> > > >the environment variable $TCPLOCALHOST. A common choice for localname
> > is 0.
> > > >
> > > >
> > > > >
> > > > > 'man tcpserver' says:
> > > > >
> > > > > -llocalname
> > > > > Do not look up the local host name; use localname
> > > > > for TCPLOCALHOST.
> > > > >
> > > > > This means that, simply, instead of making a DNS lookup for
> > > > > setting the
> > > > > TCPLOCALHOST variable with the name of the localhost,
> > > > > tcpserver trust what
> > > > > you're declaring with -l (so '0' or whatever you put is the
> > > > > same for him)
> > > > > and saves time.
> > > > >
> > > > > I prefer to declare the exact name instead of '0'.
> > > > >
> > > > > Tonino
> > > > >
> > > > >
> > > > > At 10/05/2001 10/05/2001 -0400, Ed Henderson wrote:
> > > > > >The correct form for "-l" parameter is "-l 0" not an actual
> > > > > hostname. I
> > > > > >added the following to both my pop3 and smtpd tcpservers: -l 0 -R -H
> > > > > >These switches are the ones most commonly recommended in the FAQ and
> > > > > >significantly sped up pop3 for me.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Tonix [mailto:[EMAIL PROTECTED]]
> > > > > > > Sent: Thursday, May 10, 2001 4:08 AM
> > > > > > > To: [EMAIL PROTECTED]
> > > > > > > Cc: [EMAIL PROTECTED]
> > > > > > > Subject: Re: Virtual Domains
> > > > > > >
> > > > > > >
> > > > > > > Hi Nathan,
> > > > > > >
> > > > > > > I had the same problem. I have a similar situation, and my
> > > > > > > system handles
> > > > > > > DNS by himself.
> > > > > > >
> > > > > > > Although I may swear about the functionality and setup of my
> > > > > > > DNS, I had to
> > > > > > > force the
> > > > > > >
> > > > > > > -l <name.of.my.system>
> > > > > > >
> > > > > > > parameter in the tcpserver line. Having this, tcpserver assume
> > > > > > > <name.of.my.system> to be the name of the answering computer
> > > > > > > and avoid to
> > > > > > > make an extra call to DNS (that's the call that slowered all
> > > > > > > for me, don't
> > > > > > > ask me why).
> > > > > > >
> > > > > > > Hope this help.
> > > > > > >
> > > > > > > Tonino
> > > > > > >
> > > > > > >
> > > > > > > At 10/05/2001 10/05/2001 +1000, you wrote:
> > > > > > > >G'Day All,
> > > > > > > >
> > > > > > > >I have a question about the speed of my qmail server.
> > > > > > > >
> > > > > > > >I look after 2 mail servers, 1 for the company and i
> > > > > help an isp run
> > > > > > > >the other. The company one has 1.03 qmail plain stock standard
> > > > > > > >and when you pop in and smtp in it reacts almost instantly. Works
> > > > > > > >fine.
> > > > > > > >
> > > > > > > >However we are not finding the same thing on the isp mail server.
> > > > > > > >There are about 20 virtual domains and poping in and smtp in is
> > > > > > > >starting to get slower and slower and even sometime time out.
> > > > > > > >Versions are :
> > > > > > > >qmail 1.03
> > > > > > > >vpopmail 3.4.11-1.released
> > > > > > > >qmailadmin 0.26e
> > > > > > > >
> > > > > > > >Each domain has their own ip which reverse resolves to their own
> > > > > > > >mail.domain.com
> > > > > > > >
> > > > > > > >We house all dns entries for their domains and reverses.
> > > > > > > >
> > > > > > > >What we get is that sometimes a customer of the virtual domain
> > > > > > > >will get a timeout while trying to check his email via pop3. We
> > > > > > > >have increased the timeouts on some of the pc's but really was
> > > > > > > >wondering is it because we are scaling more and more virtual
> > > > > > > >domains ? What should i be looking for ? Is it perhaps a known
> > > > > > > >bug and its fixed in a newer version ? PC is running at load
> > > > > > > >average of 0.00 and 98.6% idle. Its a P3 800 or something with
> > > > > > > >256Mb of memory....
> > > > > > > >
> > > > > > > >Thanks in Advance
> > > > > > > >Nathan
> > > > > > >
> > > > >
> > >
> > >
>
>
