Switch to authenticated mail path

[jdreed]

Unauthenticated mail is on its way out, and we should not waste time special-casing the dialup/VPN changes. I propose the following:

• Punt debathena-msmtp-mta. If you want an MTA, go install one. /usr/sbin/sendmail is not our problem, beyond maybe recommending an upstream MTA if you don't have one at all.
• Ensure that msmtp is really only used by MUAs (that is, something that can reasonably tell the user "Sorry, sending this failed, go fix it")
• Make msmtp only do authenticated mail, ideally preferring tickets (there's currently no non-cleartext way to have it to login-based authentication, right?)
• If users want to use keytabs for sending mail, they need to explicitly configure that, the use case is minimal so there's no need to support it out of the box.

Am I missing anything?

[geofft]

I think we get a decent amount of utility out of having sendmail DTRT -- most users of sendmail are, in fact, MTAs with the ability to tell user that delivery failed, not automated processes. (Think git send-email, caff, bts, etc.) The interesting daemons that send mail, other than people who have explicitly configured their setup for things like apticron and should test that mail delivery works, are things like mdadm degraded array notifications, and they mostly deliver to root on the local machine and nobody ever reads them, so breaking that case is not the worst thing in the world.

I wouldn't really mind making debathena-msmtp (both the -mta and not variants) require tickets to succeed. This would be a little nicer if we did local delivery to the root account (without requiring tickets), but I think we've discussed that a few times before.

I also wouldn't in general mind a mode (triggered by a configuration file) where debathena-msmtp always uses the machine tickets to send mail, and is like setuid or something. Maybe this would be better done in something on the order of Postfix.

There was at least one  discussion on debian-devel about removing the MTA from the default install, which would entail making these notifications do something else. There was also a  session at UDS-Q about these sorts of notifications, and delivering them to the user in ways other than with an MTA. If these changes land, then we get to stop caring about providing a useful MTA for system components, and only need to provide a useful MTA for (presumably authenticated) users.

[jdreed]

Here's a devil's advocate question: What MUAs are still talking to msmtp and why? mutt and pine can both speak smtps directly to outgoing, right? (Please don't make me sad and say that NMH is the only thing left that _needs_ to use msmtp). Certainly all the graphical clients can speak SMTPS. I'm not suggesting we punt msmtp, especially if we still want an MTA around for the reasons you mentioned, but wouldn't it be better to configure all actual mail clients to talk directly to outgoing? That way users can get immediate notification of delivery failures, etc. Of course, the downside is that you need to either continually enter your password, or save it. Which you already need to do on every other platform. Just sayin'...

[amu]

I believe Gnus and mailx both still normally invoke /usr/sbin/sendmail. Gnus supports direct SMTP as an alternative, but I'm not sure about SMTPS.

[jdreed]

Should debathena-msmtp learn how to get tickets from a keytab, or should we decide that if you want to use a keytab, you get to learn how to set KRB5CCNAME yourself? The latter is certainly easier, and we can go ahead and recommend a Real MTA(tm) to people who want cron or something to send mail.