Arrrrghhh! - is my English that bad? The question was not for you to answer Thomas.

It was a humble query to the developer, David, about how the semantics works, not the code, and if what you propose is true (haven't seen that E works that way - since I've only seen it use the pointers not the local dns cache) and the future plans/ideas of Mercury dns lookups, hopefully a clarification on lookups against the hosts file, reveverse lookups, lookups of SPF, etc - so that someone could work a daemon for those that would like to implement SPF.

In Mercury SMTP client (end-to-end version) there is a "nameserver 1:  xxx.xxx.xxx.xxx" field which shows up in the connection history box.

I've looked, but cannot find out where Mercury is pulling the server name from.  Is it possible to change it?

Thanks

It's pulling it from the OS and you can (and should) change it in the MercuryE setup.  You can enter multiple IP addresses and these will be used rather than the OS default.

I don't agree with the should statement of Thomas'. I only see one case, where you may want to deviate from the OS-default setting, and that's if you have distinguished your internal system (AD mostly) from the outside world - then for MercuryE, yes you have to separate the DNS handling from the OS.

Sorry Peter, I strongly disagree, the windows DNS system fails too often.  MercuryE should not be going to the Windows system to resolve the IP addresses on sending.  There are too many chances for failure and errors in delivery when the Windows DNS either fails or comes back with the wrong answer.  I've found that entering the IP addresses that are the primary DNS servers for the domain into the MercuryE setup cures a lot of the sending problems.

Now if you are using MercuryC for sending it's not a problem since Mercury/32 does not really depend all that much on making a connection to the windows DNS system.

The way I understood it is that Mercury only gets the list of nameservers from Windows. The lookups are then made the same way regardless of how the nameservers were defined.

/Rolf 

[quote user="Rolf Lindby"]

The way I understood it is that Mercury only gets the list of nameservers from Windows. The lookups are then made the same way regardless of how the nameservers were defined.

/Rolf 

[/quote]

In MercuryE you can enter the IP addresses to bypass the Windows DNS system.  Notwithstanding the caveats, MercuryE works quicker in all environments when the DNS hosts are specified.

From the help:

Name Servers   By default, MercuryE will ask Windows for the address of the name server it should use to resolve mail addresses. If you operate in a dialup environment, or if the machine where Mercury runs gets its configuration information via DHCP, then MercuryE may not be able to retrieve this information properly. In situations like this, you should enter the IP addresses of the name servers MercuryE should use in this field, separated by commas.

Thomas, Peter, and Rolf.  Thanks for your suggestions.  I've been using Mercury for over 5 years.  As it turned out, I had to put in the IP address or my setup would not resolve the DNS lookup.

I just upgraded my Cisco 675 router to an Actiontec M1000 router to increase bandwidth.  The M1000 connects to a Linksys WRT45G for my wireless and LAN.  After putting in the new router was when my problem began.  Mercury was pointing to the Linksys and not able to resolve the address.

I had looked at the page Thomas suggested but miss read the description.

Anyway, thanks for the help.  I'm backup and working. 

glad it works again - many boxes can act as NS-forwarders, and with their own cache - but yes they also cause many problems, and sluggish responses especially when dns updates frequently.

Since we've run with the boxes empty without any trouble for over 8 years on Windows // we ran on NW before //, I was under the same impression as Rolf that Mercury merely gets the pointers from the OS - but - I'd like David to explain the inner workings of Mercury NS-resolv process - since there are quite a few questions and elaborate (and sometimes educated) guesses about its operation - and future development plans.

Actually it's pretty simple, if you put the IP addresses in the MercuryE setup then MercuryE calls the DNS host directly to resolve the host name to IP address;  if you do not then it makes the call to the system relying on the Windows system to do the job.  We do not have to see his actual code to determine that it's better when MercuryE does this directly.