From owner-freebsd-arch@freebsd.org Thu Dec 7 16:49:33 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F27CE8C1FC for ; Thu, 7 Dec 2017 16:49:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 08AD96CD49 for ; Thu, 7 Dec 2017 16:49:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 0813FE8C1FB; Thu, 7 Dec 2017 16:49:33 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 07BEBE8C1FA for ; Thu, 7 Dec 2017 16:49:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C64256CD47 for ; Thu, 7 Dec 2017 16:49:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id 68so15812046ite.4 for ; Thu, 07 Dec 2017 08:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=YWLS8d8vtSYEU40Q7hIhoccoOr2Znhpzb9KGfcauDjA=; b=JLOfc7AY/PTQ94W64APY8xIh9d6THwmRwKm+xRvp5AlAA1RT+Ks/Swr6lnRLTVdyuu wy5y9uATeQy5lewQCuLMvVn7e+UOFRjApl6tv23ebtuUNKhXJeaONWuJMhCeWItSMRF7 isy/qdh0108OILzF92SYnVF2QVzkK4EAAc638gplJmWUIsDuYDq7NLPQAVur1hQU/Gqf 5kCvhJULBl1Q4SbC7caxadG1k4pXBYFqZygpOGvM6591lqiw9cd1OMJShgtKwO7Vrchy EpbxLywKU7pE3Vnzkw+9raGJfBjxp153JMP0enYKC609FK3QcRKh4zPksyilkpME9Tu9 PZ9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YWLS8d8vtSYEU40Q7hIhoccoOr2Znhpzb9KGfcauDjA=; b=QBzS/CEVvffvhCfljf78+MrANuCpxmC64TJAN/6CncVb79rr0dxnjD4TpV9UH8ggwX kJJEQO7ZCN1FvnyUgyCLmEgJaH+JOLcu4EFhd54AouSN3gLOgKH6+0vzaHGB2eTPOTmx 4YYbbHB1p2ecXafeFWN6lVSUmbHnIKTHYGAaATMeJsoooE5d/n4ZWVdWp9DEa9+0XARe f+0cVk6RhOk4Ond5umeWzKXEn2qxvMlc6rKB2zd14uUYQRwxfnu+xajg2EoeD/0NUDc7 dd9Uf1wZvM0XPN0YLdzaKPo+kRqDGE6x5M0FfKWN/ptk+CWeQqIlAAI3aHA2QXaL9TYj G29A== X-Gm-Message-State: AJaThX7IwN9g5UgSDgmk9EE4ALYPQ3vH8JGbj2GyNMlB6UwE2AgV5lWX xwsHnflZ++W8XYhA+vyIJ6kEmAjqN3cAoAIvKgLAnA== X-Google-Smtp-Source: AGs4zMYz50OFHsym5HD1oCDTlAc2ihNZ3ah3qlep+IOfOcwomoTtj4TmpGw4L1VWFIvf8orul0JS0S8kODiXhpyCJvQ= X-Received: by 10.107.104.18 with SMTP id d18mr35370938ioc.136.1512665371867; Thu, 07 Dec 2017 08:49:31 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Thu, 7 Dec 2017 08:49:31 -0800 (PST) X-Originating-IP: [107.77.197.129] In-Reply-To: <201712071605.vB7G58ek062860@pdx.rh.CN85.dnsmgr.net> References: <20171206223341.iz3vj4zz2igqczy7@ivaldir.net> <201712071605.vB7G58ek062860@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Thu, 7 Dec 2017 09:49:31 -0700 X-Google-Sender-Auth: znQ2rA45h4bF8KEP1CqdJdLzNL8 Message-ID: Subject: Re: RFC: Sendmail deprecation ? To: "Rodney W. Grimes" Cc: Baptiste Daroussin , "freebsd-arch@freebsd.org" , gshapiro@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 16:49:33 -0000 On Thu, Dec 7, 2017 at 9:05 AM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > Hi all, > > > > I would like to propose the deprecation then removal of sendmail in base. > > > > Deprecation will happen in the form of FreeBSD 12.0 being built > WITHOUT_SENDMAIL > > by default > > Thats not proper by procedure, FreeBSD 12.0 needs to have a binary that > spits out a > "This program is depricated and well be removed in the next release", > that would include all programs that are part of sendmail. > OK. We've never actually implemented this policy in the past. You keep saying it's the policy, but can you point to any program we've ever done this with? Ever? And for sendmail this is especially stupid because it runs hundreds or thousands of times a day on any given server with its output directed no place useful. This is a stupid thing to ask. > > > > removal would happen in FreeBSD 13.0 > > if you set WITHOUT_SENDMAIL in 12.- it is removed from 12.0 release, > so if your intent is to "remove" it in 13 you need to change when > you set WITHOUT_SENDMAIL to 13.0 It's still buildable. And this is saying, effectively, with our long release cycles we can't deorbit anything in less than 5 years, which is also insane. That's a stupid policy and one that will, in reality, be ignored and you'll send angry emails about rather than one that would be helpful to our project or our users. It's also something project has never ever been able to achieve in the past. To this day, we're not printing a warning that gcc is deprecated on every invocation (which would be F****ing stupid), and we absolutely are going to remove it before 12. > > sendmail in base it not really usable as a full featured mta due to the > fact it > > does not support anything an entreprised grade mta setup would require: > ldap > > support for example, check the number of options available in the > sendmail port. > > I suspect that less than 1% of FreeBSD users are "entreprised(sp) grade" > so the > argument that our users need ldap is just a strawman. The fact that you > use dma(8) to replace it only reinforces that fact. > > It is bad that sendmail has way to many compile time options and that many > of those options need stuff not in base to make work, but that is the state > of software spaghetti. It's bad that sendmail is such a security nightmare too. We should likely have turned it off years ago, so I applaud this move. > > > Users for that use case would be better served by the port version of > sendmail. > Again, strawman, that use case is I am fairly sure a very small one. Actually, they likely would... Better to have a small, secure, simple mailer in the base, and those with enterprise needs install the sendmail port. This would be a better state than the current state of affairs that expose more users to sendmail's security holes. So, yes, our users would be better off with sendmail as a port. Not really a strawman at all since part of the argument is that all users are better off w/o sendmail, or with sendmail as a port. > > The other kind of users are the one using the default setup of sendmail: > > relaying emails externally and deliver locally. > > > > We have dma(8) which is way smaller than sendmail(8) have a > configuration file > > understandable by most users (yet that is subjecttive) and have the > setuid > > binary capsicumized. > > > > dma(8) has been modified to fix issues reported by clusteradm preventing > its > > usage in real life situations: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208263 > > That bug is still open???? > > > > > I think only providing dma(8) by default and let users choose a full > featured > > mta via packages is a good solution and better for both sendmail users > and non > > sendmail users. > > > > If noone express a strong opinion by then, I will turn sendmail option > off by > > december 15th. > > Strong opinion expressed, procedure is not being followed by this request, > hence I would say no to this request as worded. > Further more this request appears to be biased on the idea that our users > need ldap in sendmail and I just do not see that as a truth. > And even further more it appears as if the proposed replacement has open > bugzilla reports that proclude it from even simple operation using > .forward files. > And my final point, the whole sendmail/dma issue goes to /dev/null if we > had pkg base working. So lets stop wasting time talking about culling > little parts of BSD out and get to spending that time on helping get > pkg base done. Except it doesn't go to /dev/null. We have a higher security officer burden with it in the base than as a port-based package. Warner