We use ssmtp in addition to other (real) MTA. Please allow installing SSMTP without support for MTA so it wouldn't conflict with one. I prefer mailwrapper support but since it was removed, this is the only way to have SSMTP installed with a real MTA.
This would result in several file blockers. Marking this one as WONTFIX.
What file blockers? There would be no difference if "mta" would be the default and provide files like /usr/sbin/sendmail and /usr/lib/sendmail. the "-mta" would not provide them not anything that would block. I am asking to remove all "file blockers" if mta is not required.
simply skip this part in src_install and we will have no file blockers: dosym ../sbin/ssmtp /usr/lib/sendmail || die dosym ../sbin/ssmtp /usr/bin/sendmail || die dosym ssmtp /usr/sbin/sendmail || die dosym ../sbin/ssmtp /usr/bin/mailq || die dosym ../sbin/ssmtp /usr/bin/newaliases || die we won't need conflist with virtual/mailwrapper nor virtual/mta this way.
Working on it.
Okay added with version 2.64-r2. Unfortunately not all the MTA allows installing them side-by-side simply because they don't support a modern enough EAPI. See bug #364493. So depending on what else you wanted to use on the same system your problem could be fixed entirely or only half-fixed.
With this new use flag (mta) not being there by default (at least on my system) ... ssmtp will get replaced with courier (the next in the list providing mail services) ... only a entry in /etc/portage/package.use -> mail-mta/ssmtp mta fixes that. This behavior looks broken to me, because I (and probably many others) don't want to full blown MTA on most systems ... and adding this line in package.use on every single system I currently update should NOT be the default solution!
The admin must always decide which MTA should be used and install it. ssmtp can be used without MTA functionalities and installing ssmtp should imho not cause conflicts with MTAs with the default USE flags