I'm currently working with a company that has 900 email servers: The outer most relay must have NO user database. That is *critical*.
That's a critical architectural *absence* for EVERY MX because the MX not rejecting unknown recipients causes serious problems for the MX, for the mail system behind the MX, and for other mail servers. Recipient-ignorant MXs are bad practice and bad network citizenship:
1. Spam at the large ISPs I maintain is running 70% to 85% in business hours, more at other times. The bulk of this spam is to unknown recipients, ie, these ISPs are living with a 24x7 dictionary attack. Accepting that volume of mail at the MX only to be dropped or rejected behind the MX is a situation many mail admins do want to accept.
2. With the MX accepting all msgs for all recipients (because the MX doesn't know the valid recipients) and then rejecting internally as unknown recipient, then generating a mailer-daemon non-delivery msg to the envelope sender will cause the return traffic, usually totally bogus, to explode.
3. When the [EMAIL PROTECTED] has been forged with known sender, the MX in an accomplice in a joe-job, sending the delivery failure msgs to the joe-job victim, and propagating the abuse to the innocent MX for the forged domain.
4. When the [EMAIL PROTECTED] has been forged with unknown sender, the outbound relay associated with the MX (if different) is swamped with non-deliverable non-delivery messages, shooting itself in the foot.
5. With an MX accepting all msgs for all recipients, when another legit server probes the MX as part of its "sender address verification" process, the MX says every (probably forged) sender is "ok", so the other server accepts, at the envelope level, your forged senders' mail as a legit sender. Thanks for being part of the mail abuse problem.
Not one of the above situations occurs when the MX rejects invalid recipients.
Ideally, it should also run off a bootable (ie non-writeable) CD. No hard-drive.
You're only thinking IP security. The above problems are at SMTP level. The solutions to hardware failures are in redundant SMTP gateways. It is not difficult to set up and harden, to any standards, an disk-based "appliance" MX that is recipient-aware. If security policies deny setting up best practice MXs, then the security policies are wrong. Putting a database (a simple, indexed file) of known recipients on the MX is not a security risk, since the machine is secure, it's contents are secure. Anyway, there's nothing compromising about a list of public email addresses.
hmm, how do you run a SMTP gateway without a disk anyway? run a multi-GB, multi-$K RAM disk?
(Hiding email addresses is similar to someone asking for DNS help for his public DNS domain, but keeping the public domain a secret, as if spilling his public domain name was a security risk.)
Len
_____________________________________________________________________ http://MenAndMice.com/DNS-training: Atlanta; Orlando; San Jose IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
