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

[Dale Ghent]

> On Nov 5, 2015, at 3:29 PM, Paul B. Henson <henson at acm.org> wrote:
> 
>> From: Andy Fiddaman
>> Sent: Wednesday, November 04, 2015 2:45 PM
>> 
>> Not directly. I install my own Sendmail package (which lives in
>> /opt/sendmail/ and use the mta mediator to link it from /usr/lib/sendmail
>> etc., replacing mailwrapper.
> 
> Out of curiosity, as long as you are installing a replacement MTA, why stick
> with Sendmail instead of one of the other more modern alternatives?

So I've been meditating on this question, and the broader, more general concept around MTAs on OmniOS.

First, let's take a look at the current lay of the land:

1) OmniOS packages and includes the sendmail source as it exists in illumos-gate (usr/src/cmd/sendmail)
    - This version of sendmail is quite old, last touched in any substantial way in 2010 by updating it to 8.14.4
    - There is at least one CVE against that version. Current Sendmail release is 8.15.2
    - There are some differences between Sun Sendmail and out-of-the-box sendmail.org Sendmail [1]
       -- Somewhere out there is an actual patch for this stuff, but I think that has been lost to the sands of time/Oracle

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.

3) It lacks at least one modern compile-time feature, possibly others as well.

In the end, we have an creeky old (5 year old) sendmail serving as the mail subsystem in illumos/omnios, that some utilities depend on for at least part of their functionality, and has its presence is baked in to at least 1 system header file. It's also not *standard* sendmail code, and its alterations are poorly understood and seemed to have been maintained by only John Beck @ Sun, which I think is the main reason why it has rotted for so long in illumos-gate as these changes make it sp00ky territory. To add insult to injury, the various aforementioned components references it in different locations - /usr/lib/sendmail, /usr/sbin/sendmail. Researching this led me to discover that the in-tree version of libsasl is also outdated, based on cryrus-sasl 2.1.15, where the latest is 2.1.25. Undoubtably, this also has some CVEs reg'd against it.

Software that people just immediately toss out the door and replace with something else, be it a self-rolled modern version of Sendmail or something else altogether such as Postfix or EXIM, is Bad. It just underscores how much of a failure it is due to its unmaintained state. Other than it providing a generic local delivery function, is there much use for it?

So what to do? Clearly the state of the current sendmail is far from desirable, but something needs to be there to satisfy the requirements of the other various utilities that want to spam one with annoying administrivia. With that, here are some options I've been able to figure:

OPTION 1a:
----------------
1) Find the Sun patches for sendmail and review them for relevancy, and integrate them into a modern sendmail (8.15.2 as of this writing) and push that updated wad into usr/src/cmd/sendmail to replace the current version.
2) Modernize the compile-time options of sendmail
3) Update any supporting cast (eg, libsasl)
4) Restructure sendmail packaging to break it up into separate parts (sendmail-server, sendmail-client, libmilter, etc or whatever's clever)

OPTION 1b:
----------------
1) As above, but dispense with the Sun patches (how or what this would affect is unknown to me, but if it's interop-related stuff with old unbundled Sun products, I'm more inclined to cut ties with it)

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?

OPTION 3:
----------------
1) Replace in-tree sendmail with an alternative (unscientific survey shows people seem to prefer Postfix)
2) Let users worry about any conversion process for sendmail -> postfix
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.

Of course, some of these options go beyond just being an OmniOS thing and are more of a general illumos-gate stewardship question.

Any thoughts?

[1] https://www.sendmail.com/sm/open_source/docs/vendor_info/sun/differences.html