To recap just a bit: I'd hoped that on a backup mail server I could replace:
domain.com = domain.com.smtp with: [EMAIL PROTECTED] = [EMAIL PROTECTED] [EMAIL PROTECTED] = [EMAIL PROTECTED] [EMAIL PROTECTED] = [EMAIL PROTECTED] [EMAIL PROTECTED] = [EMAIL PROTECTED] ... And that mail to any other account (any account without its own router entry) would be rejected by the secondary mail host. I wanted this to avoid the clutter that accumulates on a backup server due to dictionary attacks. It was suggested that I needed angle brackets, as in: <[EMAIL PROTECTED]> = [EMAIL PROTECTED] and possibly that I did not need the account name on the right side of the router as in: <[EMAIL PROTECTED]> = domain.com.smtp Here's what I have learned through trial-and error. Yes, the left-hand side of the router must be in angle brackets. As for whether the right side needs the [EMAIL PROTECTED] When the router reads:" <[EMAIL PROTECTED]> = [EMAIL PROTECTED]" here's what I get: RCPT TO: [EMAIL PROTECTED] 250 [EMAIL PROTECTED] will relay and the mail is indeed relayed. But when the router reads:" <[EMAIL PROTECTED]> = domain.com.smtp" here's what I get: RCPT TO: [EMAIL PROTECTED] 250 [EMAIL PROTECTED] recipient accepted and this mail never shows up at the destination. Instead, it goes into the unknown account on the backup server, if you have one configured. I don't know what happens to it if you have no unknown account. It would appear then that the proper form is: <[EMAIL PROTECTED]> = [EMAIL PROTECTED] For each valid account at the domain in question, with this type router entry in place on the backup server, the backup will accept mail only for valid accounts. Mail to any other accounts will get a "We do not relay" error and, with any luck, the queue will not fill up with failed dictionary attack messages and their matching bounce messages to bogus senders. I know that some of you have stopped using a backup MX because of spam-related considerations. Typically, a dictionary attack on the backup server results in it relaying mail to the primary for all sorts of non-existent accounts and this would get the backup server temp-banned. And, of course the queue on the backup server filled with these failed emails and the resulting bounce messages. If you don't mind setting up an additional router entry on the backup server each time you add an account on the primary, then the solution I've outlined above may be of use. One last, very important note: If the primary mail server happens to be a trusted client of the backup server, router entries don't seem to matter much. The backup server will accept mail for any account, real or bogus, associated with any domain hosted by that secondary MX. There can be NO router entries at all for domainXYZ on the backup server but if domainXYZ resolves to the IP address of any host in the client hosts list, the backup MX WILL accept mail for that account. This doesn't seem right, but that is the way SIMS acts. -- Warren Michelsen <[EMAIL PROTECTED]> Online Tools For Business -- <http://www.OTFB.com/> Small Business & E-commerce web hosting ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
