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.
