I've just installed UBB on my site, and it seems to work OK, BUT SMTP is not working. I've typed in the IP of our SMTP server (which allows relays from that address) and I just get the error as shown below. I tested the SMTP server from the machine running UBB using telnet and it works fine.

Any ideas?

---
Could not connect to server.
The server does not respond appropriately.. it may not be an SMTP server.
Server Error: ""
Server Error: ""
Server Error: ""
Server Error: ""
Server Error: ""

Hi Nick -

What server setup are you using? It appears that ActiveState perl 5.6 is buggy on it's socket functions, especially when PerlIs.dll is used.

ActiveState Perl using perlis.dll :/

Is there a more recent version, or should I use something else?

You can either run an earlier version, or try setting the mapping to perl.exe %s %s rather than PerlIS.dll.

This has made no difference. I still get exactly the same problem when using perl.exe

Is there a way to diagnose more carefully what the problem might be? How can I tell if it is a fault with the perl installation?

Actually I'm using ActiveState Perl version 522e (based on perl 5.005). Did you say the most recent version (5.6) was *more* buggy? Is it worth upgrading?

Update:
I've just tried it on a completely different server using Perl 5.6 and it still doesn't work... Any other ideas?!


[This message has been edited by Nick Gilbert (edited 06-20-2000).]

I still can't get this to work.

I've run all the tests and that all works. I've submitted a support request and got no reply.

Has anyone got any ideas?!

I'm getting desperate now people are shouting at me to get it fixed. Does anyone know of an alternative product that is similar to UBB? Maybe I can get my money back...

Nick...

Nick -

Did you submit the request through the ticket system - http://www.ultimatebb.com/home/installprob.html ?

How long has it been since you've submitted the request? You may want to try resubmitting - maybe something went wrong as Infopop usually is rather fast on their follow-ups.

I submitted it two days ago via that form.

I've noticed something else:

I'm no perl hacker, but in the ubb_library2.pl file, in the SendEmail function, if I write out a couple of the variables for debugging, I don't get what I expect.

My server is set to 128.0.0.25 in the control panel. $EmailServer contains 128.0.0.25:25 but after the gethostbyname($EmailServer) line, $remote_ip appears to be empty.

Is it me not knowing how to print $remote_ip? Or is gethostbyname not working?

How can I hard code the IP to get round this?
I tried:

$remote_sock = pack('Sna4x8', AF_INET, 25, '128.0.0.25');

But that seemed to just take ages and then gave me the same error.

128.0.0.25 is definitely running an SMTP server on port 25 which is accessable and relayable from the webserver that hosts UBB.

Thanks,

Nick...

*** FIX ***

> You seem to have worked out the email
> problem on that board you sent me to.
> I just registered and recieved this
> via email.

Only because I modified the perl code:

In the ubb_library2.pl file there is a function called SendEmail(). Near the
top of this function there is a line which reads:

$remote_ip = gethostbyname($EmailServer);

The gethostbyname() function doesn't seem to work on our servers - it
returns null, or at least, something which doesn't print on the screen.

So, after looking for a way to hard code the IP, I replaced it with this:

$remote_ip = inet_aton($EmailServer);

Which seems to return a valid IP address (provding an IP address is entered
in the control panel - I don't know what happens if you add a domain name).

So I haven't so much fixed the original problem, as bodged a fix. I don't
know perl *at all* so I can't really work out what's really going on...

I'd still be happier if it was fixed properly...

Thanks,

Nick...

An interesting dilemna...

gethostbyname() is not a UBB function and it's strictly not even a Perl function but is built into your system.

gethostbyanme() functions well on tens of thousands of machines including Win2K, IIS5 and Perl 5.6 so I'm loath to jump in and modify distribution code.

I do notice on a search that there are numbers of gethostbyname() issues on Windows systems. Apparently gethostbyname() can be pointed to other modules rather than the expected winsock function. If this was done inadevertently or by a third party application, this could be the source of the problem.

It would be an interesting 'OR' function to also try inet_aton() where the standard gethostbyname() fails. I'd want to know first that this does not cause more problems than it fixes.

For example from the MAN pages: [QUOTE]inet_aton() converts the Internet host address cp from the
standard numbers-and-dots notation into binary data and
stores it in the structure that inp points to. inet_aton
returns nonzero if the address is valid, zero if not.[/QUOTE]suggests to me that it will not resolve a domain name but only an IP

Insights welcome.

------------------
Michael Farris
UBB Administrator and Customer Support

[QUOTE]
inet_aton HOSTNAME

Takes a string giving the name of a host, and translates that to the 4-byte string (structure). Takes arguments of both the 'rtfm.mit.edu' type and '18.181.0.24'. If the host name cannot be resolved, returns undef. For multi-homed hosts (hosts with more than one address), the first address found is returned.
[/QUOTE]This, from ActiveState help files on the 'Socket' library, implies inet_aton does take domain names. But having just tried it, it didn't work. So either the help pages are wrong, or my server isn't set up for DNS, or I've got totally confused about something

Having said that, since gethostbyname() doesn't work on my system anyway, the chances that inet_aton will work are equally limited; Maybe domain names *do* work on a system where gethostbyname() fails? I obviously can't test this, since I've never got it to work....

Nick...

[This message has been edited by Nick Gilbert (edited 06-27-2000).]

Thanks for checking further. This also could be an OS difference where *nix based inet_aton() is different from NT based calls. I also suspect that inet_aton() simply uses gethostbyname() when it's asked to resolve a domain.

Some of the search results talk about problems emerging when the SMTP and the web server share the same machine. Resolving its own hostname seems to be a problem in some instances. I can never replicate the SMTP problems a [very] few NT users have no matter what Perl or NT OS type. Perhaps it is that I always use an external mail server. It would be an interesting experiment for you to find an independent SMTP which allows relay and test with both the original and modified scripts.

------------------
Michael Farris
UBB Administrator and Customer Support

I had the same problem with e-mail on my server (I'm running IIS 4.0 with ActivePerl). No errors with mail delivery were reported by UBB (reported success in fact), but no mail was actually delivered.

I modified the code as per Nick's advice:
$remote_ip = inet_aton($EmailServer);
and subsequently the mail began to be delivered.

I am running the web server and the IIS server on the same machine so perhaps as Michael states this is part of the problem. I wonder also if gethostbyname() has a innate problem with resolving IP numbers. (My SMTP server is an IP number).


[This message has been edited by Spock (edited 01-10-2001).]