Date: Fri, 11 Jan 2002 17:18:18 -0500 From: "John Straiton" <jks@clickcom.com> To: "'Ken Bolingbroke'" <hacker@bolingbroke.com> Cc: <freebsd-questions@FreeBSD.ORG> Subject: RE: OT: Sendmail issues Message-ID: <008201c19aed$e109ff60$4116c60a@win2k.clickcom.com> In-Reply-To: <20020111130047.U5440-100000@fremont.bolingbroke.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I want to open by saying that I really appreciate you taking the time to respond to me and that I really respect your opinion of "fix it, don't hack it". Please, please don't take this the wrong way because I agree with you in spirit, but have to disagree by corporate mentality, let me explain: > If you're saying that the mail for those domains are hosted > elsewhere, then all you do is skip them, because you won't be > getting those "mail loops back to self" errors with those > domains anyway. > If a given domain isn't intended to have mail delivered for > it, it shouldn't have an MX record. That's why an error > message is generated. You're seeking for a hack to silence > the error message rather than correcting the misconfiguration. >Finding a hack as an alternative to > fixing the problem usually just gives you something else that > is going to break down the line. 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. Given the harmless nature of the misconfiguration, putting effort into a hack that would cure all of our problems and allow us to focus on more important messages (like spam complaints) seems to make more sense than spending hours/days patching our automation tools, creating additional ones and repairing the incorrect records. Believe me, I'm all for "lets do it the right way, not the easy way" but in this particular case, I just don't see any other way.... I have to consider the labor costs with the two options. It doesn't make much financial sense for me to blow a ton of time fixing it when revenue generating tasks could be done instead. It's always easier to pitch money-making tasks to the-powers-that-be than money-saving tasks. > The "correct" solution to getting rid of the error messages > would be to remove the cause of the error, by taking out > unused MX records. 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. > As to maintenance, well, when a change is requested, you're > going to be changing things anyway, so why not just do it the > right way to begin with, and then at least you're not seeing > errors from misconfigured services. Because of the possibility for human mistakes. While it seems silly, we get requests all the time from companys demanding we get an email solution for them in hours. If you get them set up , then find out later that the MX is broken, you've just lost time. To be honest, it's seeming that nobody's going to be able to provide a "hack" solution so this problem will go unsolved. I simply ask those of you still reading one more time to please help point me in the right direction before I have to abandon this project as my time-budget is almost expended already just in these emails to newsgroups and mailing lists. I really want to be able to take better care of the "postmaster" role, but I'm human- And it can be very easy to miss important emails when you're besieged by 100's of inconsequential ones. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008201c19aed$e109ff60$4116c60a>