From owner-freebsd-questions Fri Jan 11 16:43:18 2002 Delivered-To: freebsd-questions@freebsd.org Received: from fremont.bolingbroke.com (adsl-216-102-90-210.dsl.snfc21.pacbell.net [216.102.90.210]) by hub.freebsd.org (Postfix) with ESMTP id 3E88B37B400 for ; Fri, 11 Jan 2002 16:43:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fremont.bolingbroke.com (8.12.1/8.12.1) with ESMTP id g0C0h7s6037193; Fri, 11 Jan 2002 16:43:07 -0800 (PST) Date: Fri, 11 Jan 2002 16:43:07 -0800 (PST) From: Ken Bolingbroke X-X-Sender: ken@fremont.bolingbroke.com To: John Straiton Cc: freebsd-questions@FreeBSD.ORG Subject: RE: OT: Sendmail issues In-Reply-To: <008201c19aed$e109ff60$4116c60a@win2k.clickcom.com> Message-ID: <20020111150752.A5440-100000@fremont.bolingbroke.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 11 Jan 2002, John Straiton wrote: > I want to open by saying that I really appreciate you taking the time to And let me offer my apology that I'm not giving you the solution you want. But you might still find it helpful at some point. > Believe me, I'm all for "lets do it the right way, not the easy way" Actually, in sysadmin work, the "right way" _IS_ most often the "easy way" ... in the long term. Look at what's happening right now--you're spending time trying to find a workaround now for a short-term "easy" hack that was implemented in the past. Had you spent a few extra minutes doing it the right way the first time around, right now you would be using your time for something else (playing golf? :-) today. Laziness is a virture for sysadmins, because when the sysadmin does things the right way, the systems run by themselves, and the sysadmin can go nuts playing Doom or whatever. > Yes, that's what I'm looking for- a hack. The misconfiguration is > actually there to prevent problems. If a customer sets up email with us > and someone forgot to set up a MX record, then there's trouble. If the > MX is always set up, then there's no risk of anyone making that mistake. > One link of the chain has just been made stronger. Not really. Consider, for example, if there's that much chance they'll forget to setup the MX record, might they not also forget to setup up the local-host-names entry? If you succeed in silencing the loops-to-self errors, you then wouldn't notice when you have a real problem affecting your customers when you forget something else. That's the reason the error message is there in the first place, after all. I mean, if you're successful in silencing this error message, the next guy might spend hours pulling his hair out trying to figure out why customers aren't getting their email message, because he's not getting the critical error message that would tell him exactly what's wrong. Also, if there's really that much chance that people are forgetting steps in the process, they're going to forget more than just the MX record. You perhaps should consider a solution that addresses the whole setup method, not just a single hack so that MX records aren't forgotten. You might go all out and make an automated script that does everything, or it might just be as simple as a checklist of items to do for each domain. > I concur. If I didn't think it would take 3 hours to find/implement a > hack vs 40 hours to "fix" the problem, I would correct the problem the > right way. 40 hours to make a list of domains for /etc/mail/local-host-names? Or alternatively, to take out the unneeded MX records: foreach f ( {list of zone files that don't need mail} ) grep -v MX $f > $f.new mv $f.new $f end # (assuming "MX" doesn't occur anywhere but in the MX record designation) A little creativity, scripting, and it won't take anywhere near 40 hours. Unless you have 40 million domains, or something.... Or if you really, really want to shoot yourself in the foot: > To be honest, it's seeming that nobody's going to be able to provide a > "hack" solution so this problem will go unsolved. Setup a procmail recipe to catch and reroute or dump the unwanted errors. Ken Bolingbroke hacker@bolingbroke.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message