> In the main, though, you've laid out yet another argument
> against secondary MX.
If so, it's the first anti-secondary-MX argument I've seen that
didn't boil down to "incompetent machine administration causes problems,"
which is true with or without multiple MX - it's just easier for mistakes to
happen with more machines involved.
But even if you got rid of secondary MXs, there's another scenario
this attacks, one which most basic firewall design courses and books
recommend: using a mail relay as a bastion host in the DMZ to disallow
direct access from the Internet to the mail store.
For example, people running Exchange or Notes (and many do, for
various good or bad reasons) may not want that box directly on the Internet,
open to SYN flooding, DOS attacks, and buffer overflow attempts. qmail
makes the perfect intermediate relay - high performance, high security, high
reliability. If the bastion host is attacked, internal mail isn't directly
affected, which is a good thing.
Let me try this argument instead: Between two networkographically
close mail hosts owned by a single entity (Secondary and primary MX, or
bastion relay and mail store), the high bandwidth and low latency of the LAN
connection means that the SMTP latency issue is diminished. Between such
hosts, then, using multiple RCPTs with a single DATA may be faster then
qmail's default behavior, which is tuned for the high-latency Internet
environment. Therefore, having the ability to modify qmail's behavior on a
host-by-host basis (much as smtproutes affects mail routing) might be
useful. It would also close this DOS capability.
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
