[plug] E-MAIL NON DELIVERY UPDATE

[Craig Foster]

> -----Original Message-----
> From: plug-bounces at plug.org.au [mailto:plug-bounces at plug.org.au] On
> Behalf Of Bernd Felsche
> Sent: Friday, 28 September 2007 7:21 AM
> To: plug at plug.org.au
> Subject: Re: [plug] E-MAIL NON DELIVERY UPDATE
> 
> Alex Polglaze <apolglaze at book-keepingnetwork.com.au> wrote:
> >Alex Polglaze wrote:
> 
> >>> In trying to work out why it no longer works, the IT guy at his
> work,
> >>> I am reluctant to use the word expert, has finally worked out that
> >>> when they upgraded their MS exchange, it is no longer able to send
> to
> >>> e-mail to Linux boxes.
> 
> >>> Therefore, the problem must be at my office and I need to change
my
> OS.
> 
> >UPDATE
> 
> >It started working today, we rec'd an e-mail, first one for months.
> 
> >We rang to say that we had rec'd one.
> 
> >The IT "expert" now realises that they have a major problem and that
> it
> >has nothing to do with me using Linux here.
> 
> >Thank you to all those who replied and apologies to those who took
> >offence at my suggestion that the guy was an idiot.
> 
> >Luckily for me, I knew that the problem was not here and therefore
> >didn't spend time, which I can't spare, and money, that I couldn't
> >really afford to waste, chasing a solution for a non existent
problem.
> 
> >This would not necessarily be the case for other people and
businesses
> >and therefore, this "expert" would have wasted other peoples
> resources.
> >Hence my criticism.
> 
> A common problem in this "industry" is that there is a basic lack of
> fault-finding skills. I.T. qualification is typically by training;
> the following of relatively few routine processes.  As a result,
> _blame_ gets shifted around (because *I* have followed all the
> procedures it's not my fault) without even first identifying the
> real problem or isolating it to a "black box".
> 
> It would be more appropriate (IMHO) if it were by a process of
> education; one of incrementally increasing the students'
> understanding of underlying principles and how they apply within the
> various higher levels of the operating computer system and network.
> 
> I.T. can be an Engineering discipline. Problems can be solved
> systematically by analysis, testing and measurement. And problems
> can be averted by systems design based on the underlying principles,
> quantitative analysis of requirements, testing and controlled
> deployment.
> 
> I.T. staff need to at least concentrate on solving problems and not
> attributing blame.
> 
> It is relatively trivial to test stuff like SMTP delivery; from
> differently-configured machined ranging from plain-vanilla to those
> struggling in a quagmire. It only requires a telnet client.
> 
> It is also trivial to check log files (on the *nix side at least) to
> ensure that things are running as expected.
> 
> A lot of time and money is spent on hardware upgrades that simply
> are not necessary. Abuse of existing systems is often the problem;
> not one of insufficient capacity to cope with stuff that should be
> happening.
> --
> /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
<snip>

At the risk of moving this further off-topic, I'll add my two cents...

I cannot agree more strongly with Bernd's words. 

SMTP can be tested using telnet in nearly every instance (except when my
mad cisco skillz are in effect :P ) and there is logging on both Windows
and Linux mail servers. Admittedly the linux logging is nicer in most
respects. I have a shell account provided by a third party, *purely* for
testing little things like this where variables need to be removed or
controlled.

Like whether the Exchange server having issues with EHLO vs HELO, or
Exchange's weird AUTH requirements, simple problem solving is not out of
anyone's league. 

A quick google wouldn't hurt either. Funniest response I've heard to
"What does 'Microsoft Certified Partner' mean?" was,
"I have to use Google better than most..."

While I won't name my company, we build our business on the fact we make
the issues our personal responsibility. If your IT person doesn't,
someone decent in the industry will need to or your IT needs will
suffer. 

/soapbox

Regards,

Craig Foster