> 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 > > Matt > > > > 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 web > >hosting 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 changes > >are obviously not immediate. So we make the following changes to the "old" > >server > > > >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 to > >something obscure (we don't delete the host in IADMIN just in case something > >backfires 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 relay > >server for somedomain.com. > > > >Now, the web server is IIS, and therefore has Frontpage forms and Coldfusion > >forms, 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, we > >make 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 A > >record. So, Imail on the old server stamps it's own IP address (192.168.1.1 > >in 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 subnets > >since there is a limit of 20, and we can't IPBYPASS entire subnets like you > >can with WHITELIST IP. > > > >We could set HOPHIGH to 1 to force declude to scan the prior host also. But > >that would add some additional overhead to declude, and not all email coming > >into 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? Or > >is 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 tries > >an A record connection when there is no MX record, or the MX host is > >unreachable. But I know from experience that spammers often attempt direct A > >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 unreachable, > >so 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 am > >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. > --- [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.
