If you delete the domain from the old IMail server, and leave the HOSTS entry in there along with the relay settings, I believe that the old IMail server will forward the E-mail from the default domain's IP address. The trick is to delete the domain from IMail, then you can IPBYPASS the single IP of the old server's default domain, that way spam filtering should work perfectly the same as it would if it was received directly. This is basically a backup MX setup when you do it this way. IMail will only use the IP that E-mail is received on if there is a host configured for that IP, otherwise it forwards it from the default domain (if I'm wrong about this, please someone chime in).
Matt
Scot Desort wrote:
The E-mail that comes in for accounts that are no longer hosted on that
server can be safely refused after 2 days passes. I believe a lot of
mail servers will try the A record when delivery fails to the MX, or the
MX can't be resolved. The E-mail should be queued on the sending server
and retried if it does fail due to a glitch. It should never default to
an A record of course.
That's what I was hoping. I don't think there is any need to leave the old Imail server with an entry in the HOSTS file pointing to the new server after, say, a week to be safe.
I believe that when IMail is set up as a gateway server, all of the E-mail will be forwarded by way of the IP of the gateway if you set it up as a host, or by the default domain's IP if you don't have a host set up on the backup MX's address. You can therefore IPBYPASS just that one IP. Your master IMail server should accept all E-mail addressed to a local domain, so you shouldn't have to do anything with the ColdFusion or MS SMTP stuff if I'm correct.
FYI, I'm not sure if I followed you perfectly.
LOL. And I am not sure I followed *you*. IPBYPASS has a 20 IP limit, so it's not practical to bypass the IP address of the old mail host. On the old box, each site has it's own IP (non-virtual) in Imail. Therefore, each domain that goes to Declude would need to have a unique IPBYPASS entry. EVen if the old Imail server forwards all outgoing email to a gateway first (my postfix box, for example), mail being delivered via a HOSTS entry is not forwarded to the gateway. The HOSTS entry takes precedence, and Imail stamps the header with the A record IP address and forwards the email directly to the declude box.
I am going to remove those HOSTS entries for one small domain and see if the user complains about not receiving some email. I am fairly confident it will not cause a problem. The "old" Imail servers, in these cases, have been in service for a long time, back when we kept mail and web on the same box (duh). New sites that we get for hosting have mail and web separate, and there isn't even *any* SMTP running on the A record box. All mail is handled by the MX host alone. And no one has complained about non-receipt of email.
Thanks,
-- Scot
Mattweb
Scot Desort wrote:
I have run across a dilema.
We run Imail on the same server as IIS for web sites we host. A normal
changeshosting customer therefore has DNS records that look like this
@ IN A 192.168.1.1 www IN A 192.168.1.1 mail IN A 192.168.1.1 somedomain.com IN MX 10 mail.somedomain.com.
As web hosting customers subscribe to spam filtering with us, we migrate their mail to our Declude server, leaving their web site on the existing server. Assuming the IP address of the declude server is 192.168.1.2, we make the following change to DNS:
@ IN A 192.168.1.1 www IN A 192.168.1.1 mail IN A 192.168.1.2 somedomain.com IN MX 10 mail.somedomain.com.
No MX records point to the web server. At the time of migration, DNS
"old"are obviously not immediate. So we make the following changes to the
toserver
1. Edit the registry and rename the "official host name" in the Imail
registry key for 192.168.1.1 to something obscure, and change any aliases
somethingsomething obscure (we don't delete the host in IADMIN just in case
relaybackfires and we need to go back to the "old" server).
2. We make an entry in the HOSTS file on the old mail server:
192.168.1.2 mail.somedomain.com
so any email still coming into the old IP address gets forwarded to the
Declude box until DNS refreshes, making the old server function like a
Coldfusionserver for somedomain.com.
Now, the web server is IIS, and therefore has Frontpage forms and
weforms, and other email generated by the web server. This stuff often gets
tripped on some declude tests. Customers have leads and other important
customer contact forms that need to always get delivered. So, naturally,
Amake an entry in our global.cfg file:
WHITELIST IP 192.168.1.0/24
to whitelist all email coming from our web servers.
Here is the problem:
Spammers often do not try to connect to the MX record. They are using the
(192.168.1.1record. So, Imail on the old server stamps it's own IP address
subnetsin this example) into the header, and forwards the email to the Declude (new) Imail server. Declude sees our IP in the header, and whitelists the spam. Obviously this is a problem.
We can't IPBYPASS all of the individual IP addresses in all of our
yousince there is a limit of 20, and we can't IPBYPASS entire subnets like
Butcan with WHITELIST IP.
We could set HOPHIGH to 1 to force declude to scan the prior host also.
comingthat would add some additional overhead to declude, and not all email
Orinto declude is effected by this scenario, possibly creating false positives.
So, the answer is to remove the entry in the HOSTS file on the old mail server so it no longer relays to the new server, now that enough time has passed and DNS has completely updated across all root servers.
Is there any chance in losing legit email (broken mail servers that don't
connect to MX records), or any other consequences of making this change?
triesis there some other work-around in declude? Any attempt to whitelist by REVDNS would cause the same problem. I suppose I could negative filter on specific headers inserted by frontpage and coldfusion, but it seems like more work than necessary.
I know that there may be a rare occassion where a sending SMTP server
direct Aan A record connection when there is no MX record, or the MX host is
unreachable. But I know from experience that spammers often attempt
unreachable,record connections, because we see a lot of email coming in that bypasses
the MX record for domains that we do some mail filtering on a front-end
Postfix box. The spam never travels through the MX Postfix box - it goes
right into the A record host. The Postfix box is NEVER down or
amso there is no reason why a remote SMTP server operating according to RFC
should try to connect directly to an A record host in this case, unless I
mistaken.
TIA,
Scot
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
