At 10:06 AM 2/11/03 -0800, Doug Sampson wrote:
"The" scanner works on whatever it chooses to. Most actual scanners I am familiar with test at the network (IP address - OSDI 3) and transport (TCP, UDP port - OSDI 4) layers. The usual standard for "open" (at least for TCP) is that something at that IP address responds at that port (instead of an icmp failure packet or no response at all). I don't use scanners that identify "stealth" ports, so I'm not sure what qualifies for that ... maybe silence instead of one of the standard "Connection Refused" responses (but you'd have to look at the docs for the actual scanner you are using to be sure).Ray/Charles,I was afraid you'd both still point to the TCP/IP settings of the Exchange box as the cause for the failure. I had thought that scanning a range of ports was to check if it was open. But it looks like my assumption was wrong. It checks for responses and obviously the scanner isn't getting a proper response from port 25. What layer does the scanning work on? Layer 3 or higher (especially the application layer?) of the OSDI model?
We're mainly Linux experts here, not Windows experts here (at least that is true of me), so at some point you're going to need to turn elsewhere for detailed help with the Exchange setup. And you've never described the proxy server (and I don't exactly know how a proxy server proxies SMTP anyway, except by running its own MTA), so we can't advise you about it.Since this Exchange box is active, I cannot change the IP settings until after hours.
But ... the ONLY change we are suggesting you make is to the Exchange server's default gateway. Does that *really* require a reboot on Windows? (I know the old joke about "You have moved your mouse - press any key to reboot", but surely Microsoft has make networking reconfiguration a bit more sane by now). OR does the proxy server require that it be the default gateway to function (if so, in what sense does it proxy)?
In principle, this approach should work just fine for not dropping mail. But remember to do it far enough in advance so that the change propagates to cached records elsewhere. And consider if the Exchange server itself requires any special reconfiguration. The added MX record should point to an FQN that is externally resolvable to the router's IP address.I also would need to change the MX record settings on our external DNS server. I wonder if there's a neat trick one can do to ensure no loss of email during this phase? For example, I could create a new MX record for the Dachstein router leaving the original MX record in place but assigning a different priority to the new MX record. When external mail server checks for MX records, they would attempt to contact our mail server with the first MX setting and failing that, check the next MX record and find the mail server active at that MX record. Does this make sense? Is this do-able? Should the MX record contain the name of the router port-forwarding the mail to the Exchange box instead the name of the Exchange box?
A quick check of your MX records says that you already have external MX backups:
autovcr@waverly:~$ host -t MX dawnsign.com
dawnsign.com MX 20 smtp.easydns.com
dawnsign.com MX 30 smtp2.easydns.com
dawnsign.com MX 0 mercury.dawnsign.com
dawnsign.com MX 10 mail.dawnsign.com
Both the 0 and 10 entries point to your proxy-server IP address. But if the 20 and 30 entries are functional, they should protect you against e-mail loss during your test phase.
But before you go on with this ... why do you need this Exchange server to be reachable both via the old proxy server and via the new Dachstein router? Is it just a transition issue, or is there something more fundamental that requires this duplication? Why not handle everything through suitable MX entries that get all mail to a single IP address?
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
