Re: monit SMTP

[Michael Shigorin]

On Sat, Feb 14, 2004 at 09:50:30PM +0100, Martin Pala wrote:
> Hi Michael, my personal point of view:
> 1.) SMTP reliability (general):
> SMTP uses message responsibility chain. In the case that server
> receives some message, it guarantees that it will be not lost
> until it will be delivered to the recipient or to the next hop.

Nope.  It is ensurance that guarantees, they say ;-)

Mail server can blow up itself while the message is queued, its
AV/AS software may go wild and decide to eat your messages (after
DATA went off, so you never really know that unless you're after
bounces somewhere in monit or some hackaround near it),
worm-of-the-week traffic peak can get it down to crawl (when
SMTP client would have to hang on while the message gets accepted
or timeout strikes), etc, etc, etc.

Actually, it was brain-damaged design with one of our MNOs when
they decided to save develoment costs (async processing) by means
of wrapping the whole thing in mail.  Well they got easier lives
of people who needed to do some crap with VB or Delphi to push
mail onto them for the service to work, but when the (previously
unused) backup MX came into action, it got firewalled off.

Another day, when the poor host which was never supposed to
receive mail was forced to (as a part of neighbour host
transition) -- it was *exactly* its own hostname which got
overlooked in a manner that resulted in open relay, a few hours
till it got to SpamCop, and surprisingly little to get shut off
by respectable MNO's relay which was gracefully using spamcop.

Another day, AV software on the host where the messages were
relayed to for processing (in the office) has choked on its
updates -- and MTA gracefully did 550 to ev'rything inbound.

I'm not downplaying my own mistakes made (even if it was some
1... or 3? AM since the transition was "scheduled for yesterday")
-- just trying to show that it's not that obvious and reliable.

What's worse, there may be too much parties involved.

Do you get my drift?

> SMTP is reliable transfer, its problem is that it guarantees no
> delivery time.

Long story short: no.

> The chain is as strong as its weakest link. It is not usual
> that SMTP client drops messages it should deliver in the case
> of error.

It depends.  And involves some queueing if less so.

> Don't worry - TCP and UDP example is far away from this
> problem, mentioned Mozilla mail (or Outlook Express if you'd
> like to) is adequate example.

Still code complexity in that UDP/TCP NFS example is waaay higher
than what's acceptable for monitoring software, and that one on
MM/TB/OE is another order(s) of magnitude that.

> 2.) I like to be notified that something happened with systems

"me too", but...

> Sure - this is not cure-all and another paralel backup methods
> needs to be used to watch the system and handle alerts.

...this is more heart-warming.

Even SMS methods are often accessible via some HTTP which is less
of a chain but rather peer-to-peer.

> 3.) I agree that the code should be clear, simple and modular.
> However i see no problem in using threads in the case that it
> makes sense.

It's libraries and APIs.  Even with the latter not changing that
often, the former do.  Would be glad if it's OK with them on
every platform monit3 runs on.

> Threads are not the evil - like with everything in the life,
> you need to learn it and its pitfalls.

Well aside from libpthread integrity (just parallel to "what if
/usr/lib/sendmail is corrupt?"), I'm really against involving
extra layers of complexity where it's not absolutely needed.

You may say that it works and I'll agree, but something tells me
that putting in all latest and greatest isn't the recipe to be
stable.  Threads involve quite enough unobvious things for some
things that can be (mis)expected to be simple -- like the
aforementioned plugins which are better to be co-authored with
people who really need them.

In the end of the day, I'm not standing by this -- just an
opinion.  If it works, great; if it breaks some day at some host
and some cunning trouble will be the cause -- it would be just as
bad.

> Generaly in the case that some error is found, i will try to
> fix it - problems are here for being solved.

Ugh.  Just got a quote: "Linux brings in powerful tools for
solving problems... which weren't until its install!" :-)

Last time I had to consider threaded design vs processes, finally
it was the latter which won.  It was tiny Ruby project (ruby
doesn't do native threads yet), it was me lazy enough and a lot
of other things -- but watching people solving complex problems,
I tend to think that stacking up _potential_ problems eventually
results in _observed_ ones.

What if lexer's code isn't thread-safe and the infamous segfaults
are thanks to that? :)

> 4.) syslog is very important (maybe you will be surprised that
> it it works via TCP too - for example syslog-ng)

No surprise. :)

> but it provides no advantage if you need to deliver alert for
> example via SMS - in such case it will involve more processes
> to deliver the message, thus it is more error prone.

It was pulled in as another example, not SMS-related at all.

> 5.) inlined SMTP implementation with message queue is still the
> most reliable solution for me.

If it's something that can be replaced, yes.

> Btw. i'm wondering that you are using Sendmail and talking
> about security

At brig.emict.com.ua?  Oh it's some horrible old RH or even SuSE
which apparently has a lot of BSDisms all over its nasty setup
which I'm apparently not responsible for.  (/usr/www/... *shrug*)
It even doesn't have monit! ;-)

As a postmaster for several FOSS related domains here in Ukraine,
I use Postfix (chrooted for a few years), and am somewhat
advocating against sendmail (after having used that with Red Hat
Linux 4.x--5.x).  Still a friend (being one of most heavyweight
postmasters in the country and one of ALT Linux Team members)
tries to pull me -- and the distro -- off onto Exim [by default]
:-)

If you're looking at osdn.org.ua:25 -- that's BSD box with *two*
MTAs configured (the second being postfix) -- odd setup but hey
it's Berkeley style ;-)

-- 
 ---- WBR, Michael Shigorin <address@hidden>
  ------ Linux.Kiev http://www.linux.kiev.ua/

pgpHccfiVItgm.pgp
Description: PGP signature