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

[Dale Ghent]

> On Nov 6, 2015, at 1:15 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
> 
> On Thu, Nov 05 2015 17:47:56 -0500, Dale Ghent wrote:
>> 2) Several other in-tree components either depend on, or at least would sorely miss a functional LDA (at a minimum). These include crond, FMA, vi/vim, audit_warn(1M), rdist, mailx, and UUCP (ha!) "/usr/sbin/sendmail" is also the value defined by _PATH_SENDMAIL in <paths.h> but nothing in-tree seems to use it. Let's not forget nightly.sh's end-of-run mails and whatever else in omnios-userland that expects a working mail transport to be present.
> 
> I already said as much on github, but these are why I think OmniOS does
> need an MSA+LDA at least.

I know, I was just bringing to conversation to a wider audience.

> 
>> 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.

>> OPTION 3:
>> ----------------
>> 1) Replace in-tree sendmail with an alternative (unscientific survey shows people seem to prefer Postfix)
> 
> I've been trying to avoid painting this particular bikeshed until it's
> at least planned to be built, so I wouldn't draw any conclusions yet.
> 
>> 2) Let users worry about any conversion process for sendmail -> postfix
> 
> There's no I can see reason anyone wanting to keep using sendmail
> couldn't use a different copy, so I don't consider this a problem.
> 
>> 3) Package it similarly to (OPTION 1a) so that it can be removed/replaced easily from a packaging perspective
>> 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)

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.

> 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.

/dale