On Sun, Jul 22, 2018 at 08:53:44AM -0400, Rich Freeman wrote > On Sun, Jul 22, 2018 at 6:57 AM Alan Mackenzie <a...@muc.de> wrote: > > Yeah, there is nothing wrong with nullmailer. It is a minimalist MTA > for systems where you just want to relay mail to another host without > running a full MTA.
The problem is brain-dead packages which gratuitously pull in an mta because they "might" need one in certain edge cases that most people do not use them for. > > > > You must have installed a package that depends on virtual/mta, > > > presumably because it needs to send emails. > > > > The package was gnupg, which surely doesn't need to send email. > > > > https://wiki.gnupg.org/WKS > https://bugs.gentoo.org/658164 ###################################################### emerge -pv gnupg These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-crypt/gnupg-2.2.8::gentoo USE="bzip2 readline smartcard ssl -doc -ldap -nls (-selinux) -tofu -tools -usb -wks-server" 0 KiB ###################################################### On my system, gnupg has the "-wks-server" USE flag, but it is still hard-coded to depend on mta-1. procmail also pulls in mta-1, even though I only use it to filter incoming email. > Plus, you really don't want to have a system without any MTA - That should be my decision. > in your case you had installed one outside of portage, but if you > don't have any that is what nullmailer is for.) There was already a /usr/sbin/sendmail symlink, as the OP pointed out. Is there a way to make the presence of that file satisfy mta-1? Speaking of "sendmail" symlinks, I do ***NOT*** want them. My most embaressing linux moment occured years ago at a more newbie stage, when a chatty cron job started spewing stuff to root. ssmtp does one thing; it forwards emails to my ISP's mta for dispatch. I was more of a newbie back the, and din't realise that ssmtp splatters symlinks all over the place... /usr/bin/sendmail /usr/lib64/sendmail (64-bit systems) /usr/lib/sendmail (32-bit systems) /usr/sbin/sendmail I wasn't aware of filtering outbound email by UID. Net result; cronjob spam ended up going to root@<my ISP>. Not appreciated. I eventually figured this out, and took the following safety precaution... ###################################################### #!/bin/bash rm -rf /usr/bin/sendmail rm -rf /usr/lib64/sendmail rm -rf /usr/lib/sendmail rm -rf /usr/sbin/sendmail mkdir /usr/bin/sendmail touch /usr/bin/sendmail/.keep mkdir /usr/lib64/sendmail touch /usr/lib64/sendmail/.keep mkdir /usr/lib/sendmail touch /usr/lib/sendmail/.keep mkdir /usr/sbin/sendmail touch /usr/sbin/sendmail/.keep ###################################################### This blocked the creation of sendmail symlinks. I "lived happily ever after"... until Portage changed policy to fail hard when it couldn't create the symlinks. So an @world update dies in the middle. Now, if a "-pv" run shows that ssmtp will be updated, I have to... * "rm -rf" the "sendmail" directories * emerge -1 ssmtp * re-run the symlink-killer script * do the @world update. Yes, I do filter emails for low UIDs now, but I like defense-in-depth. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
