[OmniOS-discuss] Bloody // mailwrapper & mta mediator

[Lauri Tirkkonen]

On Fri, Nov 06 2015 01:55:54 -0500, Dale Ghent wrote:
> >> OPTION 2:
> >> ----------------
> >> 1) Kick in-tree sendmail to the curb, and let distros/distro users figure MTAs out for themselves
> >> 2) Improve mailwrapper(1M) to be cognizant  of /usr/bin/mail, /usr/ucb/Mail, /usr/bin/mailx and maybe provide some sort of no-frills local delivery only to /var/mail functionality.
> >> 3) Or no mail delivery functionality of any kind?
> > 
> > What happens to the consumers listed above if this happens?
> 
> Thats where mailwrapper (or some component in addition to it) comes in and provides a very basic local delivery only. Like, not even remote delivery, and the destination user must be in /etc/passwd. No-frills, but it gets a mail to some destination. It would need to be coded. Hell, it could be written in perl or python for all I care. I have no final form in my head, just a general concept.

Ah, okay. I'm fine with that but it sounds like more work than dropping
in an alternative.

> >> 4) We'll still need sendmail.org Sendmail source bits in order to deliver libmilter and milter functionality into Postfix.
> > 
> > Where does the milter requirement come from? Per KYSTY I would think
> > OmniOS should only deliver what it needs to function itself. Are there
> > milter consumers in -gate or omnios-userland?
> 
> Well, if we bring in a sendmail replacement and we neuter its features, no one will use it or at least consider serious level of use of it; and it will end up being uninstalled and thrown out like the sendmail we currently have. This is a flaw that the current in-tree sendmail suffers from (in addition to being woefully out of date)

I'm not really saying we should actively neuter a replacement's features
because OmniOS itself doesn't need them, but I don't see the point of
bringing in milter either.

> Which brings us back to the philosophical question - why include software that nobody wants because its most basic level of functionality is often insufficient? But if we don't include it, other things suffer or are degraded in out-of-the-box functionality. I believe in KYSTY - but to a point. In these grey areas of overlap, some exceptions or special considerations must be made. Let's be real here. There are many area in illumos that someone can point to and ask why its there if one to strictly interpret KYSTY in all cases.

Sure, generally speaking. In this particular context I believe users
should ship their own if they want to deploy a mail server, but all
nodes should be able to deliver mail locally. It would also be great if
the default install lended itself to mail submission (eg. a satellite
mailer configuration), perhaps even with opportunistic TLS, to cover
more of the common use cases, but that might be just my personal bias
talking.

> > If you're asking for opinions on what to do, I don't think keeping
> > sendmail on life support is worth it, which removes option 1. Since
> > there are MSA/LDA consumers, option 2 isn't feasible either. That leaves
> > only option 3, unless "do nothing" is an option.
> 
> Well "do nothing" has been the apparent course of action for almost 6 years now. But that's speaking in general illumos-gate terms. As far as OmniOS goes, we can completely ignore that part of the tree and install our own thing in our own way... but I want to at least explore the options which have a bearing on illumos-gate (ie; the greater illumos community) first.

True. I do think that excising sendmail and replacing it with something
would also benefit the greater illumos community, but I'm already
dreading a potential developer list discussion on the subject :)

-- 
Lauri Tirkkonen | lotheac @ IRCnet