Re: monit SMTP

[Michael Shigorin]

> > smtp server is not needed, tiny smtp null mailer only for relay (see
> > nullmailer, ssmtp, msmtp)
> I think this is misunderstand - we don't plan to implement SMTP server in monit.

Well it seems to be miswording. :)

> Monitoring software generaly should be as indepent as possible (Christian 
> explained reasons).

Yep.  But more importantly, it should work.  More code means more 
problems and development/support/use costs (money, time, nerves...).

Re reasons given:

> - what if you system doesn't/can't have a smtp server installed?

Then it doesn't need that probably.  If it does, supporting setup with
e.g. nullmailer is better than handling zillion "what-ifs" for
supposedly at least a bit knowledgeable to get to monit at all sysadmin.

ICQ counter-question was very reasonable ;-)

> - what if that certain smtp server fails?

Then it's not the transport.  What if it never comes back up?  Resort
to scanning internet for open relays? ;-)

> - what if /usr/lib/sendmail is corrupted?

Disable SMTP transport.

> - what if the mail server config file is corrupted?

Disable SMTP transport (if corruption is accidental, then the server is
most likely not to start with it and refuse any client's attempts to
send mail; if not, then it's likely that we're owned and it's IDS job to
try and get message out, not monit's)

Look at syslog: it's critical *but* uses UDP nevertheless. (I know NFS
has suffered badly upon that, but then again -- they tried to implement
something reliable based on something adherently inreliable and failed,
even being well-funded)

> Proposed SMTP refactoring serves for more secure SMTP client functionality.

As a humble monit user, I'd argue that users like me *don't* need that
for the following reasons:

- networked code is more dangerous in general, thus some additional
  expertise is needed to keep the avreage product level the same;
- reimplementing the wheel or pulling some (patched) implementation in
  is *not* an option for reasonable software given that reasonable
  "wheels" already exist and are usable in component manner.

Let me elaborate a bit.

If you invent yet another SMTP client to rely upon it, you get:

+ internal solution, no dependencies, no more complicated code to
  crash/thrash;
+ it can be more specialized, tiny, lightweight.

It's good.  But:

- if I don't need that and prefer more reliable signalling means, it's
  more networked code to sit in memory (not listen to the sockets, ok);
- if the implementation you're basing on has yet unknown security
  problems, forking/pulling in is *evil*: see e.g. zlib story.

> In the case that all SMTP relays failed, monit will queue messages for later attempt. 

Ah, one more thing:

- mail is unreliable by default -- so focusing on it as The Transport
  is really wrong.  In case of network outages, you're likely better off
  with GSM modem or serial link based notifier than having a pile of
  rubble mail when the dust gets down

> This way we will not loose messages in the case of temporary problem (for 
> example network outage).

But do we need them then?  Isn't logging for that?

The question is whether mail is considered reliable transport, compare
with UDP vs TCP.

I'd bet that your efforts are unbalanced with the fact that mail (SMTP
in real world) is *not* reliable for a long time.

> > > - what if that certain smtp server fails?
> > yes what if "trusted mail hub" fails ? what if smtp session fails
> > (timeout) ?
> Monit supports more then one mailhub (smtp relay).

Beautiful.  But more complex code.  Thus more problems with monit
itself.

> In the case that no relay is available, monit will queue message and try to 
> deliver it laterr.
> Again - this is normal for SMTP clients - for examle Mozilla mail

Oh no!  Please don't mix up user software like Mozilla where any bloat
is acceptable and crashing is no big prob with tools which are leaning
to the mission-critical area somewhat.

> > > - what if /usr/lib/sendmail is corrupted?
> > what if monit died with queued message(s) ?
> In the case of crash you can loose data on any system.

And with more complex watchdog we're closer to crash.  monit is complex
enough already for me to put it under init(8) directly, disabling
initscript-based startup.

> We will try to design the queuing method as secure as possible.

You'd really better concentrate on getting things architecturally
isolated: main process is small, simple code that does its job.  If
there are any web monitoring/config thingies (which are OK when
everything's right, but can step in the way when it isn't -- and that
time is exactly when it *must* work it's best!) -- said thingies are
separate and can die peacefully by themselves.

Bringing in databases, web/smtp servers/clients must not hurt the main 
virtue of monit -- watching processes and helping them to move on.

> Client code will not mean extra security problem.

Client exploits are a class on their own.  I understand that trusted 
relay shouldn't be that dangerous, but nobody knows.

------------------------------------------------------------------

See: we've done some mobile-related platform last year.  Some similar
problems regarding transports involved (SMPP over different wrappers,
specialized APIs, etc) were predicted, additionally appeared, and solved
with differing success.

The most obvious mistake in such projects is *counting* on some
transport to be reliable, and/or making the system single-moduled enough
to spiral down with all the things when one thing (considered reliable)
suddenly breaks.

What if your queue takes more resources than available until network is
available again?  Yes, more complicated queue manager is doable, but
that's an area of research on its own (we've looked into that, believe
me) -- and still it's NOT monit's main business doing queues, so it's
NOT worth main effort.

Even making it not to segfault when parsing bad config would be much
better investment.  It's different issue (startup-time, not runtime) but
it is.

Or are you supplied with free time much better than we were with paid
one in *quite* funded project? ;-)

PS: I'm sorry if the wording is a bit too harsh but bloating code which
has enough segfaults in the latest production version seems unreasonable
to me.  Hope that v.4 will be beautiful and reliable -- and I already
have some plans on integrating support for it in the distribution we
with Igor help maintaining -- ALT Linux -- and in our server products
(we're FOSS consulting and development firm in Ukraine), but it would be
too bad if reimplementing monit itself would be less pain than living
with too much onboard reimplementations in it.

Hope this helps; if it doesn't make it to the list, could you forward?
If any replies are on the list, please drop me a Cc:.

Yours,

--
Michael Shigorin
EMT.Com.UA