Nothing should recommend/depend msmtp-mta; installer should deal

[jdreed]

I encountered a user today who had postfix installed and configured, and debathena clobbered it with debathena-msmtp-mta. msmtp-config should not recommend msmtp-mta, but rather the installer should look and see if you have an mta, and if you don't, offer msmtp-mta.

[andersk]

I’m not convinced that -standard users should be given an MTA (or an “MTA”) at all, but Recommends: debathena-msmtp-mta | mail-transport-agent might do what you want.

[jdreed]

This is probably even more relevant, now that you can't send unauth mail. Users likely will want a "real" MTA that does direct delivery or something. I wonder if we should put some effort into coming up with exim or postfix configs that will use a keytab or something, or at least documenting. I don't think such configs should be included as part of any metapackage (or depended on by anything else), but maybe making them available would be clever.

[jdreed]

To clarify, in out-of-band conversations with Garry and Mark, it's been noted that unauth mail is only going to get more restrictive, not less. I think we need to think harder about this. Some points to consider.

• Back in the day (like, the 8.4 days -- Greg or someone should correct me if my memory or inferences are wrong), we moved from Athena machines doing direct delivery to all going through outgoing. I think was from a desire not only to have mail take a known path, but also because a broken sendmail config could easily cause stupid mail loops. If we move back to encouraging direct delivery, we should make sure we've thought about this.
• Keytabs are not obviously the wrong answer here for private machines, and we should encourage their use.
• Saving credentials on machines probably _is_ the wrong answer. Should we support this anyway?

I think my personal preference is for debathena-msmtp (and by extension, -mta) to begin to fail if they can't do authenticated delivery. We can add a setting that users can explicitly enable to allow a fallback to unauth mail and explain that it might fail. We can also document how to go install a real MTA if you want one, and the caveats that come with that.

[jdreed]

See also #1140.

[kaduk]

Replying to jdreed:

This is probably even more relevant, now that you can't send unauth mail. Users likely will want a "real" MTA that does direct delivery or something. I wonder if we should put some effort into coming up with exim or postfix configs that will use a keytab or something, or at least documenting. I don't think such configs should be included as part of any metapackage (or depended on by anything else), but maybe making them available would be clever.

I think I would prefer the "documenting" route to actually coming up with config packages that are not depended on anywhere. The latter seems to have potential for ending up with broken/stale packages.

[jweiss]

• Back in the day (like, the 8.4 days -- Greg or someone should correct me if my memory or inferences are wrong), we moved from Athena machines doing direct delivery to all going through outgoing. I think was from a desire not only to have mail take a known path, but also because a broken sendmail config could easily cause stupid mail loops. If we move back to encouraging direct delivery, we should make sure we've thought about this.

I have a vague recollection that something specific broke, and pushed us in the direction of using outgoing for everything. However, it's possible that I'm conflating this occasion with one of the several others where some change to the mail system actively broke what Athena workstations were doing at the time, and the reasons you mentioned were the only ones that applied.

• Keytabs are not obviously the wrong answer here for private machines, and we should encourage their use.
• Saving credentials on machines probably _is_ the wrong answer. Should we support this anyway?

I think my personal preference is for debathena-msmtp (and by extension, -mta) to begin to fail if they can't do authenticated delivery. We can add a setting that users can explicitly enable to allow a fallback to unauth mail and explain that it might fail. We can also document how to go install a real MTA if you want one, and the caveats that come with that.

Right now, debathena-msmtp looks at $DEBATHENA_SENDMAIL_AUTH If it is set to "yes" it sends authenticated mail or fails with and error. If it is undefined (or empty) it tries to send auth'd mail, but falls back to unauth'd if it can't find tickets. If it si set to anything else it sends unauth'd mail. If you simply take the second case and make it behave like the first case, I think you get what you want, tho I suppose you lose the setting for auth if possible but unauth if needed (tho you could certainly define a new value of this variable to check for).

I'll also note that I think this is pretty reasonable, tho I'd want the error to stat mentioning "renew" and for us to consider whether we have exactly the same behavior if we're running as root (since that's where I expect automated mail to run without having tickets).

[jdreed]

I suspect changing msmtmp to Anders' suggestion is the right answer here. debathena-msmtp-mta may have its failings, but it's arguably no worse than upstream msmtp-mta (which also Provides: mail-transport-agent).

[jdreed]

r25900

[jdreed]

committed  8a87dc59d489c42fbc602baff1117f3b8030cf32 (Prompt for debathena-msmtp-mta) to master

[jdreed]

This is fixed. We should, in the future, consider making this into a package that simply diverts sendmail, rather than attempting to replace it, and then it can co-exist with anything that provides /usr/sbin/sendmail.