http://qs321.pair.com?node_id=1032930


in reply to Can't get Net::SMTP to work

Try the Perl debugger, run your code with $perl -d ... and try to see what's up, step by step.

As the error is coming up almost immediately, it shouldn't be too hard to follow the upstream calls into Net::Command or IO::Socket::INET in order to find out what the actual problem would be.

Apparently you can't get a local socket - hard to say why.

Replies are listed 'Best First'.
Re^2: Can't get Net::SMTP to work
by kcantrel (Initiate) on May 10, 2013 at 23:28 UTC
    Okay, so I stepped through the code, and apparently, as expected, it is failing at the:
    if (!connect($sock, $addr)) {

    statement from connect() subroutine in the IO::Socket.pm file. Well, if anything, after that call, which is a low level call that I can't step into, all the sudden $! is set to the "No connection could be made because the target machine actively refused it" error and the logic causes it to return with an error.

    I mentioned before that I have turned off the Windows firewall, but this is a company issued laptop that has McAfee installed on it. It should only be doing virus scanning, but I can't help but think it is somehow causing the problem. What doesn't make sense though, is that I can 'telnet' to port 25 without a problem. So, unless there is some kind of rule that allows telnet to get to that port and not Perl, I don't understand how that can be the case.

    I also have Cisco AnyConnect installed, and it implies it does firewalls, but I think only when the VPN is running, and I don't have it working when doing these tests.

    Anyway, if anyone has any other ideas, I'd love to hear them.

    Thanks!
      In the IO::Socket.pm that I can look into, the code is like

      sub connect { @_ == 2 or croak 'usage: $sock->connect(NAME)'; my $sock = shift; my $addr = shift; my $timeout = ${*$sock}{'io_socket_timeout'}; my $err; my $blocking; $blocking = $sock->blocking(0) if $timeout; if (!connect($sock, $addr)) {
      so the call to connect should still be traceable a bit by single-stepping...Might help to know if the issue is before or after getting a local socket to use. Not that I think that would help too much, but it still might get you a bit closer to a solution.

      Any chance to try the code on another machine ? Are you running this with the same privileges as when you do successfully telnet ? Maybe you can check if it behaves the same way when you run it as Administrator?