mailwrapper(8): do not use _PATH_DEFAULTMTA if mailer.conf cannot be opened #969
Conversation
Previously, mailwrapper(8) would default to invoking _PATH_DEFAULTMTA (i.e., dma) if mailer.conf couldn't be opened for any reason, including transient errors like ENFILE. This behaviour is undesirable, because if the administrator has configured a different MTA in mailer.conf, they almost certainly don't want mailwrapper to unpredictably fall back to the compiled-in default; and in any case, the default MTA is probably not running, meaning the mail may be queued and then never delivered, which is worse than not accepting it to begin with. Change this behaviour depending on why mailer.conf can't be opened: - If it doesn't exist, keep the existing behaviour of falling back to the default MTA, on the assumption that this is a reasonable default if mailer.conf hasn't been configured at all. - If it cannot be opened for any other reason, do not invoke an MTA and instead return an error to the caller. PR: 25218
|
@bsdimp closed the bug with,
|
|
alright. i suppose this can be closed too then if no one wants to merge it, although i still think the default behaviour is wrong (and potentially a security issue, if a very minor one). |
|
can you fix the commit message, please? ENFILE —> ENOFILE otherwise: this looks harmless to me, closing in on net positive. 👍🏻 from me |
|
i think |
|
I hadn't seen this when i closed the bug. I honestly thought nobody still cared and with more resources this problem stopped happening. I think it may be worth a chat on arch@freebsd.org to see if we can get more input. |
|
So I can't land this... I think it needs more discussion somewhere. If I missed that, please add a pointer. |
|
There's a discussion in arch@ |
Previously, mailwrapper(8) would default to invoking _PATH_DEFAULTMTA (i.e., dma) if mailer.conf couldn't be opened for any reason, including transient errors like ENFILE. This behaviour is undesirable, because if the administrator has configured a different MTA in mailer.conf, they almost certainly don't want mailwrapper to unpredictably fall back to the compiled-in default; and in any case, the default MTA is probably not running, meaning the mail may be queued and then never delivered, which is worse than not accepting it to begin with. Change this behaviour depending on why mailer.conf can't be opened: - If it doesn't exist, keep the existing behaviour of falling back to the default MTA, on the assumption that this is a reasonable default if mailer.conf hasn't been configured at all. - If it cannot be opened for any other reason, do not invoke an MTA and instead return an error to the caller. PR: 25218 Reviewed by: imp, emaste, markj Pull Request: #969
|
landed |
Previously, mailwrapper(8) would default to invoking _PATH_DEFAULTMTA (i.e., dma) if mailer.conf couldn't be opened for any reason, including transient errors like ENFILE. This behaviour is undesirable, because if the administrator has configured a different MTA in mailer.conf, they almost certainly don't want mailwrapper to unpredictably fall back to the compiled-in default; and in any case, the default MTA is probably not running, meaning the mail may be queued and then never delivered, which is worse than not accepting it to begin with.
Change this behaviour depending on why mailer.conf can't be opened:
If it doesn't exist, keep the existing behaviour of falling back to the default MTA, on the assumption that this is a reasonable default if mailer.conf hasn't been configured at all.
If it cannot be opened for any other reason, do not invoke an MTA and instead return an error to the caller.
PR: 25218
note that there was on discussion on the PR about whether this change is desirable or not, and in particular the original submitter changed their mind about it. i think this is worth reconsidering because the current behaviour does not seem very good: the world has changed a lot in the last 20 years, and nowadays any remotely important system will almost certainly be monitored by an external NMS, so the idea of depending on this as a "last gasp" attempt to send a notification mail doesn't seem to justify the downsides.