Summary: | mail-mta/sendmail - MSP runner only | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | ranaldo |
Component: | New packages | Assignee: | Andrea Barisani (RETIRED) <lcars> |
Status: | RESOLVED NEEDINFO | ||
Severity: | enhancement | CC: | net-mail+disabled |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
ranaldo
2007-03-29 07:45:56 UTC
This is not a security bug, re-assigning. I know about MSP mode but I don't think this deserves a USE flag. You are already free to just *not* start the daemon and tweak submit.mc accordingly. What would a specific USE flag accomplish? We cannot prompt for the server to be specified in submit.mc in the ebuild (it's bad to have interactive questions) and we don't put sendmail in default runlevel by default when emerging. So I'm not sure what do you think the USE flag would do, everything is already there. Cheers P.S. The 'conclusion' section of that article is sadly hilarious. Having a local MTA still helps in some scenarios (and it can be bind to 127.0.0.1), MSP only submit.cf is known to have issues when you want TLS/SSL encryption and validation for instance.
>
> P.S.
> The 'conclusion' section of that article is sadly hilarious. Having a local MTA
> still helps in some scenarios (and it can be bind to 127.0.0.1), MSP only
> submit.cf is known to have issues when you want TLS/SSL encryption and
> validation for instance.
>
Ok this last comment wasn't actually against the suggestion per se, just a bit of a rant about the over-sensationalist conclusions of the article ;).
It still makes sense to allow MSP operation (which is a good thing), but I fail to see how the current setup could be improved.
If you have any suggestions about how you think this should be done, please shoot :)
|