[9062] in athena10
Re: [Debathena] #1140: Switch to authenticated mail path
daemon@ATHENA.MIT.EDU (Debathena Trac)
Tue May 22 13:19:07 2012
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@MIT.EDU
To: jdreed@MIT.EDU, geofft@MIT.EDU
Date: Tue, 22 May 2012 17:19:03 -0000
Reply-To:
Message-ID: <057.b1070d5871c92e7a557fb7d2d867063d@mit.edu>
In-Reply-To: <042.eb199a4034cac835b7215ab21d35dfa9@mit.edu>
Content-Transfer-Encoding: 8bit
#1140: Switch to authenticated mail path
-------------------------+--------------------------------
Reporter: jdreed | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Precise Release
Component: -- | Resolution:
Keywords: | Upstream bug:
-------------------------+--------------------------------
Comment (by 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
[http://thread.gmane.org/gmane.linux.debian.devel.general/172032
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
[http://summit.ubuntu.com/uds-q/meeting/20497/foundations-q-degraded-hw-
notification/ 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.
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/1140#comment:1>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
