Gossamer Forum
Home : Products : Gossamer Mail : Development, Plugins and Globals :

Pop_server plugin on Windows 2003 box

Quote Reply
Pop_server plugin on Windows 2003 box
Is there documentation available for the pop_server paid plugin? I've paid for and installed the plugin and would love to get it running on my Windows server. unfortunately there isn't any documentation for the plugin that I can find.

My system has multiple network cards and IP addresses. Which IP will the pop_server plugin bind to? I need to open the port on the firewall.

Last edited by:

DrewBlack: Jul 3, 2006, 2:50 PM
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
I found the help page. I think I can get gpopd.pl configured to run as a service.

But I'd like to know if there's a way to configure it to bind to a specific IP address?
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
Looking at the code, it looks like it binds to all ip addresses and there's currently no option to bind to a specific one. However, it shouldn't be too difficult to change. For now, you should be able to change Pop_Server.pm (admin/Plugins/GMail/Pop_Server.pm), around line 298 (in connect()), change:
Code:
bind(Server, sockaddr_in($self->{port}, INADDR_ANY)) || return $self->error("could not bind to port $self->{port}, perhaps something is already using that port: $!", "WARN");
to
Code:
bind(Server, sockaddr_in($self->{port}, inet_aton('the ip address to bind to'))) || return $self->error("could not bind to port $self->{port}, perhaps something is already using that port: $!", "WARN");

I'll have to add this as an option for a future release.

Adrian
Quote Reply
Re: [brewt] Pop_server plugin on Windows 2003 box In reply to
Thanks. This should do the trick.

I have a pop3 service running already bound to a different IP address on the system and this should enable me to make sure that the gpopd daemon only binds to the hostname that the gossamer mail service is running on.
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
It's been a while since I've looked into using this POP3 server module. I never was able to get it running successfully on my Win2003 box.

I can tell that the daemon is starting from both the netstat command and the access.log file. It accepts the connection from my POP3 client (Thunderbird) but then eventually times out. I know there's nothing else on the server trying to control port 8110. I have also tried to use the default 'bind to all IP addresses' as well as the 'bind to specific IP address' modifiaction noted above.

batch/tools/gpopd.pl 116608: server started on port 8110 on Mon Nov 30 11:33:27 2009
batch/tools/gpopd.pl 116608: connection from [my_ip_address] at port 56823 on Mon Nov 30 11:35:24 2009
batch/tools/gpopd.pl 116608: Starting process handle IP [my_ip_address] on Mon Nov 30 11:35:24 2009
batch/tools/gpopd.pl 116608: begat 116252 on Mon Nov 30 11:35:24 2009

That's the last line in the log file for any connection I try to establish.

If I try to telnet to port 8110 I get no response from the POP3 process.

Any hints on how to get this thing to work?

Thanks.
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
Here's a little more debugging info:

When I start the daemon from the command line I get a message that indicates the server was started with [PID] on [port]. That all looks fine and dandy. But as soon as I try to connect with a POP3 client an error is spit out to the command prompt (STDOUT?). The error reads: Unknown Option: inetd-service.

I don't see a inetd-service perl module in my version of activestate perl.
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
Here's a little more info.

If I invoke the POP3 server from the command line using the -s or --service options it appears to work using the STDIO support. Unfortunately this is my screen and keyboard. I'm able to login just fine and check messages, etc. from a command prompt. Now I need to figure out how to route TCP traffic on port 8110 to the script.
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
Do you have a firewall running on there? Have you tried connecting via localhost?

Adrian
Quote Reply
Re: [brewt] Pop_server plugin on Windows 2003 box In reply to
I have done the telnet testing both through the firewall and on the local server. The log file snippet I posted above is showing that it is picking up a connection attempt and logging it. The POP3 client software is outside the firewall.

I have the pop_server plugin configured to use port 8110. I assume it only needs one port. That port is open through the firewall but it never responds. It's almost like the stdin and stdout aren't being redirected properly.

If I run:

perl [path_to_script]\batch\tools\gpopd.pl --service

from the windows command prompt I'm able to use the pop_server plugin from the command prompt. I can login, (USER, PASS) and fetch mail manually.

FWIW, when I start the pop_server service from the web interface it appears to hang forever but if I click the status link the PID file appears to have updated and the service thinks it's operational.
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
The server status message /mail/admin/admin.cgi?do=plugin&plugin=Pop_Server&func=status is:

Your POP Server is currently running with Process ID 108436 on port 8110. You can stop the POP server by clicking on the stop link. Remember that when you stop it, anyone who was getting their email will be cut off.

The server is at 64.151.83.185.



Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
I should have also mentioned that I have used Outlook Express as a POP3 client on the server that's hosting the gossamer mail script. (No firewall in between the two.) The POP3 connection times out in Outlook Express.

Here's a little more from the log file:

\admin\admin.cgi 121284: Server spawned with pid 124176 on Mon Nov 30 17:44:20 2009
\batch/tools/gpopd.pl 124176: server started on port 8110 on Mon Nov 30 17:44:20 2009
\batch/tools/gpopd.pl 124176: connection from 14032-23166 [127.0.0.1] at port 2969 on Mon Nov 30 17:44:24 2009
\batch/tools/gpopd.pl 124176: Starting process handle IP 127.0.0.1 on Mon Nov 30 17:44:24 2009
\batch/tools/gpopd.pl 124176: begat 122316 on Mon Nov 30 17:44:24 2009
\batch/tools/gpopd.pl 124176: connection from 14032-23166 [64.151.98.20] at port 2970 on Mon Nov 30 17:44:34 2009
\batch/tools/gpopd.pl 124176: Starting process handle IP 64.151.98.20 on Mon Nov 30 17:44:34 2009
\batch/tools/gpopd.pl 124176: begat 112540 on Mon Nov 30 17:44:34 2009
\batch/tools/gpopd.pl 124176: connection from 14032-23166 [64.151.98.20] at port 3172 on Mon Nov 30 17:49:59 2009
\batch/tools/gpopd.pl 124176: Starting process handle IP 64.151.98.20 on Mon Nov 30 17:49:59 2009
\batch/tools/gpopd.pl 124176: begat 124636 on Mon Nov 30 17:49:59 2009
\batch/tools/gpopd.pl 124176: connection from 14032-23166 [127.0.0.1] at port 3215 on Mon Nov 30 17:51:51 2009
\batch/tools/gpopd.pl 124176: Starting process handle IP 127.0.0.1 on Mon Nov 30 17:51:51 2009
\batch/tools/gpopd.pl 124176: begat 118964 on Mon Nov 30 17:51:51 2009
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
Here's a little more testing results using the Windows netstat command. 64.151.83.185 and 64.151.98.20 are both IP addresses on the same server hosting the gossamer mail application. 69.21.29.243 is an IP address outside the firewall. You can see that I am able to establish a connection through the firewall. For some reason the pop_server plugin doesn't respond over TCP when a connection is established. I am able to see that it works from a command prompt as I noted above. I think something is wrong in the way it's trying to connect to the standard I/O on Windows. Keep in mind that this system doesn't have inetd functionality. It's running under IIS6 with ActiveState Perl. It is not running under an Apache server on Windows.

Proto Local Address Foreign Address State
TCP 0.0.0.0:8110 0.0.0.0:0 LISTENING
TCP 64.151.83.185:8110 69.21.29.243:63412 ESTABLISHED
TCP 64.151.98.20:8110 64.151.98.20:3527 TIME_WAIT

Last edited by:

DrewBlack: Nov 30, 2009, 3:10 PM
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
I'm making some progress. I was able to get the pop_server plugin to start responding to client commands after making the following change. (I also switched from port 8110 used above to 1110 so I could test with Google's Gmail pop3 client.)

Line 442 in pop_server.pm changed from:
my @cmd = ($CFG->{location}->{path}->{perl}, "$CFG->{location}->{path}->{batch}/tools/gpopd.pl --inetd-service --nodaemon");
to
my @cmd = ($CFG->{location}->{path}->{perl}, "$CFG->{location}->{path}->{batch}/tools/gpopd.pl --port=1110 --service start");


It's better but still not working properly though. I added some debug logging code at a few different spots in pop_server.pm. It seems like the problem is with the
print '.', $EOL;
statements. These appear many times in the code and indicate that a multiline response is complete. For some reason clients like Outlook Express and Thunderbird are hanging/experiencing timeouts on multiline output commands. Outlook Express is having a problem with RETR and Thunderbird is having trouble with LIST. That print statement appears very basic. I don't know why it would be the culprit.
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
I'd really like to get this figured out. We're shutting down our webmail application on our site and I'd like to be able to offer our users a convenient way to get the contents of their mailboxes moved to the provider of their choice.
Quote Reply
Re: [DrewBlack] Pop_server plugin on Windows 2003 box In reply to
hmm, not sure if this will help, but at the top of Pop_Server.pm, try changing $EOL = "\015\012"; to $EOL = "\012";

Adrian
Quote Reply
Re: [brewt] Pop_server plugin on Windows 2003 box In reply to
It works now. I'm able to fetch mail from multiple POP3 clients inside and outside of the firewall.

Interesting. Kinda surpirsed no one ever ran into this problem previously.