-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
cheers Lutz
On Fri, Oct 17, 2008 at 01:31:32PM +0200, Lutz Lange wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
This is a (very) controversial issue. If I recall well, it has been decided not to change anything for F10, but there was an heated thread some time ago, and maybe this could be discussed in the timeframe of F11. To sum up some people considered that local delivery was a must for the default MTA, and that a send-only MTA wasn't good enough, eg, for cronie. My personnal opinion is that there should not be any MTA in the @base or @code group, and that a MTA should be chosed if it is pulled in as a dependency, so it could be sendmail or anything else. Whether local delivery is a must for cronie or other packages that today require /usr/sbin/sendmail is another story that caould be discussed a bit more, though in the end it seems to me that this should be up to the maintainer.
But could you please elaborate a bit more on something like a proposal?
-- Pat
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrice Dumas schrieb:
On Fri, Oct 17, 2008 at 01:31:32PM +0200, Lutz Lange wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
This is a (very) controversial issue. If I recall well, it has been decided not to change anything for F10, but there was an heated thread some time ago, and maybe this could be discussed in the timeframe of F11. To sum up some people considered that local delivery was a must for the default MTA, and that a send-only MTA wasn't good enough, eg, for cronie. My personnal opinion is that there should not be any MTA in the @base or @code group, and that a MTA should be chosed if it is pulled in as a dependency, so it could be sendmail or anything else. Whether local delivery is a must for cronie or other packages that today require /usr/sbin/sendmail is another story that caould be discussed a bit more, though in the end it seems to me that this should be up to the maintainer.
But could you please elaborate a bit more on something like a proposal?
-- Pat
Hi Pat,
i'm an instructor an just had students wondering why we still ship sendmail as default. All i was really looking for was a good argumentation shows why we do it like that. I wanted to show that is was a choice and that we do it for good reason. The for me obvious alternative is using postfix as default. This seams more up to date, easier to configure, and it's not a big blob of binary software as sendmail seams to be. For the stability argument, i've hear that sendmail and postfix are quite comparable and have had about the amount of bug both in severity and count over the last few years. But to be fair, i will confess, i'm not really that deep into Mail and therefore the wrong person to judge from a professional perspective. Though i think we should provide good reasons for the thinks we ship / do. An just arguing we've done this for X years this way, doesn't seam enough somehow.
Cheers Lutz
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
It works. It can be configured to do just about anything. Everyone who has every worked with a unix-like system is used to it. Every program written for unix-like systems is likely to expect it to be installed. Even though the original design and code weren't particularly secure, the current version is probably one of the most audited pieces of code and the milter capability lets you extend it with features that don't share the full permissions of the main process yet can interact in real time during delivery.
Le Ven 17 octobre 2008 14:39, Les Mikesell a écrit :
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
It works.
Sort of
It can be configured to do just about anything.
Like others
Everyone who has every worked with a unix-like system is used to it.
No
Every program written for unix-like systems is likely to expect it to be installed.
They only expect the sendmail interface alternatives are also providing
Even though the original design and code weren't particularly secure, the current version is probably one of the most audited pieces of code and
And upstream has such a confidence in the result they're rewriting it from scratch.
the milter capability lets you extend it with features that don't share the full permissions of the main process yet can interact in real time during delivery.
Milter is supported by alternatives too
Not that I particularly want to shoot ambulances, but those are not good arguments.
Nicolas Mailhot wrote:
Not that I particularly want to shoot ambulances, but those are not good arguments.
They would be lousy arguments for changing to sendmail but they are fairly good arguments for keeping it. One needs a fairly compelling reason to change something that is already there. The above arguments amount to "there is no compelling reason to change".
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
shmuel siegel schrieb:
Nicolas Mailhot wrote:
Not that I particularly want to shoot ambulances, but those are not good arguments.
They would be lousy arguments for changing to sendmail but they are fairly good arguments for keeping it. One needs a fairly compelling reason to change something that is already there. The above arguments amount to "there is no compelling reason to change".
What about : it's not easy to configure it right or to learn how to do it. If you already know it, you might be fine. If not you might be in trouble. And: It's second choice for an MTA for most people i know. I may know the wrong people but as an instructor i meet quite a lot of them :)
Cheers Lutz
On Fri, 2008-10-17 at 15:13 +0200, Lutz Lange wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
shmuel siegel schrieb:
Nicolas Mailhot wrote:
Not that I particularly want to shoot ambulances, but those are not good arguments.
They would be lousy arguments for changing to sendmail but they are fairly good arguments for keeping it. One needs a fairly compelling reason to change something that is already there. The above arguments amount to "there is no compelling reason to change".
What about : it's not easy to configure it right or to learn how to do it. If you already know it, you might be fine. If not you might be in trouble.
If you're old school and insist on editing the .cf I might agree with you but that then contradicts your "If not" clause. If you don't know what you're doing you might be deceived by complainers into thinking that's how it's configured and that's how you have to do it.
OTOH... The .m4 configurations are not very complicated. Very straight forward to enabled and disable features and configure names and tokens and files. I don't find the m4 interface to be any more complicated to configure than say smail or postfix and a hell of a lot simpler than many other utilities. I find sendmail far easier to configure than, say, squid or other complex utilities requiring acls and filters, which we largely take for granted. I also find that sendmail generally works just fine out of the box for simple systems.
And: It's second choice for an MTA for most people i know. I may know the wrong people but as an instructor i meet quite a lot of them :)
Not quite sure I know how to parse that last one. Do you mean that sendmail is a second choice? Or what is a second choice? I'm not sure one what the "It" is that you are referring to or how you are arguing there.
You mean that people given a list would place sendmail second? I know a lot of people in the business and have known a lot of them down through the last two decades. I know people who are passionate about QMail and I know Wietse and I happen to think Postfix is wonderful and I've personally contributed to the Smail project many many years ago and I've even worked with and ported and configured MMDF (anyone remember MMDF, the default MTA on SCO Unix for many many years?). I would not make the statement that most would put Sendmail second. I would not make the statement that most would put Sendmail first. I know that both Postfix and Sendmail are very popular. Sendmail is well established as the default with a reasonably easy option to switch to Postfix, and I see no compelling reason to switch.
Cheers Lutz
Regards, Mike
Nicolas Mailhot wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
It works.
Sort of
What does that mean? It delivers most of the mail on the internet and always has.
Even though the original design and code weren't particularly secure, the current version is probably one of the most audited pieces of code and
And upstream has such a confidence in the result they're rewriting it from scratch.
And its not the first time. All good programs are periodically rewritten and improved.
the milter capability lets you extend it with features that don't share the full permissions of the main process yet can interact in real time during delivery.
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Not that I particularly want to shoot ambulances, but those are not good arguments.
Sorry, but I don't see any counterargument here. The alternatives are all worse.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Les Mikesell schrieb:
What does that mean? It delivers most of the mail on the internet and always has.
...
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Not that I particularly want to shoot ambulances, but those are not good arguments.
Sorry, but I don't see any counterargument here. The alternatives are all worse.
The question remains, is it the best option for the most users? That's what the default MTA should be right?
Cheers Lutz
On Friday, 17 October 2008 at 15:13, Les Mikesell wrote:
Nicolas Mailhot wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
[...]
the milter capability lets you extend it with features that don't share the full permissions of the main process yet can interact in real time during delivery.
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Postfix will: http://www.mimedefang.org/kwiki/index.cgi?Milter ... Milter and Postfix
The Postfix MTA implemented partial Milter support in version 2.3 and more complete support in 2.4. See http://www.postfix.org/MILTER_README.html for details. MIMEDefang 2.63 works with Postfix. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not that I particularly want to shoot ambulances, but those are not good arguments.
Sorry, but I don't see any counterargument here. The alternatives are all worse.
Postfix is not worse. I'd argue that's it's better in every respect, but I guess you wouldn't listen anyway and I'm a bit short on time.
Regards, R.
Dominik 'Rathann' Mierzejewski wrote:
[...]
the milter capability lets you extend it with features that don't share the full permissions of the main process yet can interact in real time during delivery.
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Postfix will: http://www.mimedefang.org/kwiki/index.cgi?Milter ... Milter and Postfix
The Postfix MTA implemented partial Milter support in version 2.3 and more complete support in 2.4. See http://www.postfix.org/MILTER_README.html for details. MIMEDefang 2.63 works with Postfix. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Interesting - that doesn't seem to be generally known. I hadn't seen it mentioned on the MimeDefang list. Maybe it is just because the distributions stable enough to be used as a mail server don't include 2.4 yet.
Not that I particularly want to shoot ambulances, but those are not good arguments.
Sorry, but I don't see any counterargument here. The alternatives are all worse.
Postfix is not worse. I'd argue that's it's better in every respect, but I guess you wouldn't listen anyway and I'm a bit short on time.
It's worse at backwards compatibility. Fedora seems to assume that their users don't already have something working, so maybe that's not a concern to anyone here. If it shipped with a decked-out, well tested setup already integrated with MimeDefang/clamd/spamassassin it might be enough of an improvement to switch.
On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Some of the better alternatives don't even _try_ to run milters, because they are fully-featured enough in their own right, without needing to rely on external software.
David Woodhouse wrote:
On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Some of the better alternatives don't even _try_ to run milters, because they are fully-featured enough in their own right, without needing to rely on external software.
Which means that you can't run your choice of tests on a message during the smtp conversation before you accept it - at least without starting a new process for each one which is expensive for large programs like spamassassin. And if you accept a message but don't deliver it, you are supposed to generate a bounce to the sender, but that is always the wrong thing to do if you think it might be spam or a virus. Running your checks in time to do an smtp reject eliminates that problem.
On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
Which means that you can't run your choice of tests on a message during the smtp conversation before you accept it - at least without starting a new process for each one which is expensive for large programs like spamassassin.
As is often the case, it seems, you are entirely incorrect.
David Woodhouse wrote:
On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
Which means that you can't run your choice of tests on a message during the smtp conversation before you accept it - at least without starting a new process for each one which is expensive for large programs like spamassassin.
As is often the case, it seems, you are entirely incorrect.
One of my choices of tests on an inbound relay machine has been to check that the user exists using an smtp check against the internal delivery host. How would I do that on an MTA that does not handle milters?
On 10/19/2008 02:04 PM, Les Mikesell wrote:
One of my choices of tests on an inbound relay machine has been to check that the user exists using an smtp check against the internal delivery host. How would I do that on an MTA that does not handle milters?
Not taking sides on milters or not but ..
This can be achieved in sendmail (et al) with virtusertable. Doesnt use an smtp check from border to inside as you stated, and it does need a virtusertable on the border relay.
On Sun, Oct 19, 2008 at 2:17 PM, Mail Lists lists@sapience.com wrote:
On 10/19/2008 02:04 PM, Les Mikesell wrote:
One of my choices of tests on an inbound relay machine has been to check that the user exists using an smtp check against the internal delivery host. How would I do that on an MTA that does not handle milters?
Not taking sides on milters or not but ..
This can be achieved in sendmail (et al) with virtusertable. Doesnt use an smtp check from border to inside as you stated, and it does need a virtusertable on the border relay.
Everyone - Mail Lists has spoken. End of thread!
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
There's two types of people using fedora: 1) People who don't run a mail server 2) People who very deliberately do
For 1), all three are wrong. Really. All you really need is some minimalist commandline compatible thing that just forwards to some smart host (or maybe does only local delivery). SSMTP or similar is perfectly fine for this, while not taxing memory or boot time.
For 2) these folks have a VERY specific personal preference. This entire discussion proves that. These folks already have to configure their system from the default... making "pick a mail server of your taste" part of that is the least of their worries.
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality...
On 10/19/2008 02:37 PM, Arjan van de Ven wrote:
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality...
Agreed - tho it would be nice to ship dkim-milter and dk-milter along with sendmail/postfix etc.
On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality...
(+1)
Good point, but don't forget that Fedora is pretty ambivalent distribution. It's a "desktop distribution" where some people want to disable non-X console and other people use postfix, port packages to s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a base for Red Hat Enterprise distribution :-)
Karel
On Sun, Oct 19, 2008 at 3:26 PM, Karel Zak kzak@redhat.com wrote:
On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality...
(+1)
Good point, but don't forget that Fedora is pretty ambivalent distribution. It's a "desktop distribution" where some people want to disable non-X console and other people use postfix,
That's right - desktops are different from servers. Fedora's core should be driven from the use cases, and where the use cases have things in common, they're shared. Where they don't, they're not.
Specifically regarding an MTA, as I said before I understand there's the "workstation" use case where you're say doing web development and you want to install Apache or Tomcat or something locally and run logwatch on it. We obviously will support that. But it doesn't make sense for the default desktop OS to be sending you email about all the junk going on under the hood.
On Sun, 2008-10-19 at 15:32 -0400, Colin Walters wrote:
But it doesn't make sense for the default desktop OS to be sending you email about all the junk going on under the hood.
I understand where you are coming from but I have to say the above statement is, imo, fundamentally wrong.
-sv
On Sun, Oct 19, 2008 at 09:47:58PM -0400, seth vidal wrote:
But it doesn't make sense for the default desktop OS to be sending you email about all the junk going on under the hood.
I understand where you are coming from but I have to say the above statement is, imo, fundamentally wrong.
I agree with Seth. Since most desktop users don't have a centralized logserver but do have an e-mail account somewhere, it makes perfect sense. We need to work some on getting e-mail going somewhere useful, though, and on making the e-mails sent be not "junk".
Matthew Miller (mattdm@mattdm.org) said:
I understand where you are coming from but I have to say the above statement is, imo, fundamentally wrong.
I agree with Seth. Since most desktop users don't have a centralized logserver but do have an e-mail account somewhere, it makes perfect sense. We need to work some on getting e-mail going somewhere useful, though, and on making the e-mails sent be not "junk".
I'm trying to think of a single thing that logwatch (or cron) would send about now that would be useful to forward to a random desktop user's yahoo address. I'm failing.
Bill
Bill Nottingham wrote:
Matthew Miller (mattdm@mattdm.org) said:
I understand where you are coming from but I have to say the above statement is, imo, fundamentally wrong.
I agree with Seth. Since most desktop users don't have a centralized logserver but do have an e-mail account somewhere, it makes perfect sense. We need to work some on getting e-mail going somewhere useful, though, and on making the e-mails sent be not "junk".
I'm trying to think of a single thing that logwatch (or cron) would send about now that would be useful to forward to a random desktop user's yahoo address. I'm failing.
Most people would probably like to know if smartctl thinks their disk drive is likely to fail or if a raid member has already failed and they are running in degraded mode. And maybe if a bazillion ssh login attempts have failed. As for cron, that would be up to what the user has scheduled. It just needs to behave as documented and expected.
On Mon, Oct 20, 2008 at 2:23 PM, Les Mikesell lesmikesell@gmail.com wrote:
Most people would probably like to know if smartctl thinks their disk drive is likely to fail or if a raid member has already failed and they are running in degraded mode.
Should be exposed through HAL and then the desktop can listen for that event and present it in a suitable way - e.g. a notification bubble.
Les Mikesell (lesmikesell@gmail.com) said:
I'm trying to think of a single thing that logwatch (or cron) would send about now that would be useful to forward to a random desktop user's yahoo address. I'm failing.
Most people would probably like to know if smartctl thinks their disk drive is likely to fail or if a raid member has already failed and they are running in degraded mode. And maybe if a bazillion ssh login attempts have failed.
... which should be pop-up alerts of some sort on the machine itself. Not sent halfway across the world waiting for you to connect to the internet.
Bill
Bill Nottingham wrote:
I'm trying to think of a single thing that logwatch (or cron) would send about now that would be useful to forward to a random desktop user's yahoo address. I'm failing.
Most people would probably like to know if smartctl thinks their disk drive is likely to fail or if a raid member has already failed and they are running in degraded mode. And maybe if a bazillion ssh login attempts have failed.
... which should be pop-up alerts of some sort on the machine itself. Not sent halfway across the world waiting for you to connect to the internet.
You are kind of missing the point of a machine with a network, automated scheduling and the native ability to run single apps in a remote window. Users don't need to sit in front of every machine they have for it to be doing something useful for them. The user may in fact be halfway around the world when you'd present that pop-up that he'll never see in some window manager he's not running. Messages you want should come to you, rather than having to do the reverse.
On Mon, Oct 20, 2008 at 2:43 PM, Les Mikesell lesmikesell@gmail.com wrote:
You are kind of missing the point of a machine with a network, automated scheduling and the native ability to run single apps in a remote window. Users don't need to sit in front of every machine they have for it to be doing something useful for them. The user may in fact be halfway around the world when you'd present that pop-up that he'll never see in some window manager he's not running. Messages you want should come to you, rather than having to do the reverse.
So set up logwatch or whatever other server machine monitoring software you prefer.
On Mon, Oct 20, 2008 at 01:43:42PM -0500, Les Mikesell wrote:
You are kind of missing the point of a machine with a network, automated scheduling and the native ability to run single apps in a remote window. Users don't need to sit in front of every machine they have for it to be doing something useful for them. The user may in fact be halfway around the world when you'd present that pop-up that he'll never see in some window manager he's not running. Messages you want should come to you, rather than having to do the reverse.
Once you're beyond the typical desktop use case, then yes, an MTA probably makes sense. But that's not an argument for an MTA in the default desktop install.
Matthew Garrett wrote:
On Mon, Oct 20, 2008 at 01:43:42PM -0500, Les Mikesell wrote:
You are kind of missing the point of a machine with a network, automated scheduling and the native ability to run single apps in a remote window. Users don't need to sit in front of every machine they have for it to be doing something useful for them. The user may in fact be halfway around the world when you'd present that pop-up that he'll never see in some window manager he's not running. Messages you want should come to you, rather than having to do the reverse.
Once you're beyond the typical desktop use case, then yes, an MTA probably makes sense. But that's not an argument for an MTA in the default desktop install.
OK, if you really are so elitist that you think typical users can't figure out how to use standard programs, consider the case where you install the software for one of your incapable friends or family members and you'd like those impending failure warnings to come to you since the user won't understand them anyway.
Les Mikesell (lesmikesell@gmail.com) said:
Once you're beyond the typical desktop use case, then yes, an MTA probably makes sense. But that's not an argument for an MTA in the default desktop install.
OK, if you really are so elitist that you think typical users can't figure out how to use standard programs, consider the case where you install the software for one of your incapable friends or family members and you'd like those impending failure warnings to come to you since the user won't understand them anyway.
Then you, the *administrator* of that machine (because, truly, that's your role) can configure it to do so. It doesn't mean it should do so out of the box.
Bill
On Mon, Oct 20, 2008 at 3:24 PM, Bill Nottingham notting@redhat.com wrote:
Then you, the *administrator* of that machine (because, truly, that's your role) can configure it to do so. It doesn't mean it should do so out of the box.
That said, I do wish Fedora made it easier to do the remote admin for family/friends type thing. I'm not really thinking of setting up mail servers, but more putting together something like Copilot (https://www.copilot.com/) from the tools we have (Vino, ssh, Telepathy). But that's another discussion...
Colin Walters wrote:
On Mon, Oct 20, 2008 at 3:24 PM, Bill Nottingham notting@redhat.com wrote:
Then you, the *administrator* of that machine (because, truly, that's your role) can configure it to do so. It doesn't mean it should do so out of the box.
That said, I do wish Fedora made it easier to do the remote admin for family/friends type thing. I'm not really thinking of setting up mail servers, but more putting together something like Copilot (https://www.copilot.com/) from the tools we have (Vino, ssh, Telepathy). But that's another discussion...
I think policykit introduces some really ugly issues issues here - or at least if it works the same as in ubuntu in terms of giving unwarranted privileges to console sessions and requiring a console session to use the GUI admin tools if you don't log in as root. You could use VNC or NX/freenx session shadowing with an already logged in console user session, but that's not exactly right for administration since it might really be an unprivileged user sitting there.
Bill Nottingham wrote:
Les Mikesell (lesmikesell@gmail.com) said:
Once you're beyond the typical desktop use case, then yes, an MTA probably makes sense. But that's not an argument for an MTA in the default desktop install.
OK, if you really are so elitist that you think typical users can't figure out how to use standard programs, consider the case where you install the software for one of your incapable friends or family members and you'd like those impending failure warnings to come to you since the user won't understand them anyway.
Then you, the *administrator* of that machine (because, truly, that's your role) can configure it to do so. It doesn't mean it should do so out of the box.
But it is even more important for the more common case where the user is his own administrator. The right way to handle that case is not to change it conceptually by re-inventing a less capable - and unexpected - message transport and storage facility, but to make the standard capability more obvious by adding a choice for the root alias at firstboot configuration and a mail notifier applet to the default desktop. This gives you a configuration that both an administrator and a first-time user can understand and use, and even the first-time user will see that the capabilities are better than he'd have on a stock MS windows box.
On Mon, Oct 20, 2008 at 02:17:39PM -0500, Les Mikesell wrote:
Matthew Garrett wrote:
Once you're beyond the typical desktop use case, then yes, an MTA probably makes sense. But that's not an argument for an MTA in the default desktop install.
OK, if you really are so elitist that you think typical users can't figure out how to use standard programs, consider the case where you install the software for one of your incapable friends or family members and you'd like those impending failure warnings to come to you since the user won't understand them anyway.
I'm pretty solidly of the opinion that email is nowhere near being the most sensible way to get important information to a typical desktop user. If a failure is important then the user needs to know about it as soon as possible - mail provides no guarantees about timely delivery. We have plenty of desktop infrastructure to give important alerts to users, we're just failing to do so.
Matthew Garrett wrote:
On Mon, Oct 20, 2008 at 02:17:39PM -0500, Les Mikesell wrote:
Matthew Garrett wrote:
Once you're beyond the typical desktop use case, then yes, an MTA probably makes sense. But that's not an argument for an MTA in the default desktop install.
OK, if you really are so elitist that you think typical users can't figure out how to use standard programs, consider the case where you install the software for one of your incapable friends or family members and you'd like those impending failure warnings to come to you since the user won't understand them anyway.
I'm pretty solidly of the opinion that email is nowhere near being the most sensible way to get important information to a typical desktop user. If a failure is important then the user needs to know about it as soon as possible - mail provides no guarantees about timely delivery. We have plenty of desktop infrastructure to give important alerts to users, we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other notification method would have succeeded. The important point is that the user may not be present when the event occurs, and that desktop infrastructure may not even be running - and even if it is, the interested party may want the notification to be forwarded elsewhere.
On Tue, Oct 21, 2008 at 08:52:27AM -0500, Les Mikesell wrote:
Matthew Garrett wrote:
I'm pretty solidly of the opinion that email is nowhere near being the most sensible way to get important information to a typical desktop user. If a failure is important then the user needs to know about it as soon as possible - mail provides no guarantees about timely delivery. We have plenty of desktop infrastructure to give important alerts to users, we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other notification method would have succeeded. The important point is that the user may not be present when the event occurs, and that desktop infrastructure may not even be running - and even if it is, the interested party may want the notification to be forwarded elsewhere.
Local delivery of mail is a poor solution, since it provides no indication of priority difference between "You've got spam" and "Your hard drive is failing". If there's nobody to present it to, it can be queued and presented at login - if the user is running on their system but doesn't have the desktop infrastructure running, then by definition they're already outside the standard desktop usecase.
I'm not arguing about the utility of an MTA for various situations. I'm arguing that for one specific and very common situation, using an MTA to deliver system alerts is a poor way of handling it. We should fix that. As a happy side effect, it removes the need for a default MTA in the desktop install. People who want an MTA then get to choose whichever MTA they want and net human happiness is increased.
On Tue, Oct 21, 2008 at 03:07:13PM +0100, Matthew Garrett wrote:
queued and presented at login - if the user is running on their system but doesn't have the desktop infrastructure running, then by definition they're already outside the standard desktop usecase.
You mean like boot, shutdown, being logged out, ...
As a happy side effect, it removes the need for a default MTA in the desktop install. People who want an MTA then get to choose whichever MTA
Actually that I question somewhat. Both POSIX and the LSB require local mail delivery services. A suprising number of applications that don't currently specify sendmail dependancies appear to use it. Have a grep...
And if we are going to worry about desktop experiences then perhaps making evolution not totally suck, fixing the way the desktop totally disintegrates when you run out of disk space, a working gdm again and a few other items would be far better use of time than macdinking with log delivery.
My own experience is that if you are using gnome and run out of local disk and or quota the fact your mail is not delivered is the least of the problems, and managing to log in and then having to restore half your desktop settings are far bigger ones.
Alan
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
Actually that I question somewhat. Both POSIX and the LSB require local mail delivery services. A suprising number of applications that don't currently specify sendmail dependancies appear to use it. Have a grep...
Every package with application that calls /usr/sbin/sendmail should require that file. Isn't it the case? If you know about cases like that, tell, I'll file bugs.
Now this is only part of the story since currently programs that don't do local delivery, or are not configured for local delivery out-of-the-box provides /usr/sbin/sendmail. I think that is is right, but maybe a virtual dependency, like mail(local) is needed somewhere to force installation of an app that does local delivery, either as a dependency, or as part of the default install, though there is no agreement on that currently.
-- Pat
Patrice Dumas wrote:
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
Actually that I question somewhat. Both POSIX and the LSB require local mail delivery services. A suprising number of applications that don't currently specify sendmail dependancies appear to use it. Have a grep...
Every package with application that calls /usr/sbin/sendmail should require that file. Isn't it the case? If you know about cases like that, tell, I'll file bugs.
If POSIX requires it, it should be a safe assumption on any system that claims compliance.
Now this is only part of the story since currently programs that don't do local delivery, or are not configured for local delivery out-of-the-box provides /usr/sbin/sendmail. I think that is is right, but maybe a virtual dependency, like mail(local) is needed somewhere to force installation of an app that does local delivery, either as a dependency, or as part of the default install, though there is no agreement on that currently.
Apps that send mail don't and shouldn't know where delivery is going to happen. That is entirely up to the transport.
On Tue, Oct 21, 2008 at 04:50:35PM +0200, Patrice Dumas wrote:
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
Actually that I question somewhat. Both POSIX and the LSB require local mail delivery services. A suprising number of applications that don't currently specify sendmail dependancies appear to use it. Have a grep...
Every package with application that calls /usr/sbin/sendmail should require that file. Isn't it the case? If you know about cases like that, tell, I'll file bugs.
Try grep. That is how I did a scan.
On Tue, 21 Oct 2008 12:13:57 -0400 Alan Cox alan@redhat.com wrote:
On Tue, Oct 21, 2008 at 04:50:35PM +0200, Patrice Dumas wrote:
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
Actually that I question somewhat. Both POSIX and the LSB require local mail delivery services. A suprising number of applications that don't currently specify sendmail dependancies appear to use it. Have a grep...
Every package with application that calls /usr/sbin/sendmail should require that file. Isn't it the case? If you know about cases like that, tell, I'll file bugs.
Try grep. That is how I did a scan.
fwiw ssmtp and all those guys do provide a /usr/bin/sendmail, but one that doesn't queue just does local delivery.
On Tue, Oct 21, 2008 at 10:36:49PM +0200, Patrice Dumas wrote:
On Tue, Oct 21, 2008 at 12:13:57PM -0400, Alan Cox wrote:
Try grep. That is how I did a scan.
A grep in what? In a strings on all binaries?
source packages
On Tue, Oct 21, 2008 at 10:33:43AM -0400, Alan Cox wrote:
On Tue, Oct 21, 2008 at 03:07:13PM +0100, Matthew Garrett wrote:
queued and presented at login - if the user is running on their system but doesn't have the desktop infrastructure running, then by definition they're already outside the standard desktop usecase.
You mean like boot, shutdown, being logged out, ...
Times when mail delivery isn't a terribly effective solution either.
And if we are going to worry about desktop experiences then perhaps making evolution not totally suck, fixing the way the desktop totally disintegrates when you run out of disk space, a working gdm again and a few other items would be far better use of time than macdinking with log delivery.
Also, we should stop doing any kernel development until ipw4965 actually works. I'm pretty sure we don't need another slab allocator.
On Tue, Oct 21, 2008 at 06:13:56PM +0100, Matthew Garrett wrote:
And if we are going to worry about desktop experiences then perhaps making evolution not totally suck, fixing the way the desktop totally disintegrates when you run out of disk space, a working gdm again and a few other items would be far better use of time than macdinking with log delivery.
Also, we should stop doing any kernel development until ipw4965 actually works. I'm pretty sure we don't need another slab allocator.
And how many years as gnome out of disk been broken, or evolution crap ?
No we don't need another slab allocator, but last time I checked nobody in Red Hat was writing one either. They are all far too busy working on stuff that needs doing.
Alan
On Tue, Oct 21, 2008 at 06:33:51PM -0400, Alan Cox wrote:
On Tue, Oct 21, 2008 at 06:13:56PM +0100, Matthew Garrett wrote:
Also, we should stop doing any kernel development until ipw4965 actually works. I'm pretty sure we don't need another slab allocator.
And how many years as gnome out of disk been broken, or evolution crap ?
To be fair to evolution, it's getting on for being in the region of half as big as the kernel. Making it non-crap isn't a five minute job, and asking people to spend three years failing to get very far through it isn't likely to win many friends. We have insane quantities of crap code in the distribution and stopping feature development in order to fix all of it wouldn't actually result in customers beating our door dwn.
No we don't need another slab allocator, but last time I checked nobody in Red Hat was writing one either. They are all far too busy working on stuff that needs doing.
We needed Ubuntu on Sparc64? A functional desktop is something that needs doing. We can quibble over what's actually required for a functional desktop (and I'll agree that evolution isn't a shining example of functionality), but I'm fairly convinced that getting system alerts to a relevant user in a timely manner is one component of it. Doing so via mail worked fine when most Unix systems were maintained by people who understood cron, but that's not current reality.
On Tue, Oct 21, 2008 at 10:33 AM, Alan Cox alan@redhat.com wrote:
And if we are going to worry about desktop experiences then perhaps making evolution not totally suck, fixing the way the desktop totally disintegrates when you run out of disk space, a working gdm again and a few other items would be far better use of time than macdinking with log delivery.
I agree there are some dire things broken in the desktop. The disk space one is particularly evil - we should have at least a notification nowadays (http://cgwalters.livejournal.com/2008/02/09/).
However, startup speed is something that impacts nearly everyone and is an immediately visible part of the interaction with the computer. It makes sense to prioritize fixing it.
Colin Walters wrote:
On Tue, Oct 21, 2008 at 10:33 AM, Alan Cox alan@redhat.com wrote:
And if we are going to worry about desktop experiences then perhaps making evolution not totally suck, fixing the way the desktop totally disintegrates when you run out of disk space, a working gdm again and a few other items would be far better use of time than macdinking with log delivery.
I agree there are some dire things broken in the desktop. The disk space one is particularly evil - we should have at least a notification nowadays (http://cgwalters.livejournal.com/2008/02/09/).
However, startup speed is something that impacts nearly everyone and is an immediately visible part of the interaction with the computer. It makes sense to prioritize fixing it.
You can certainly defer the sendmail daemon startup so you don't have to wait for it - and it doesn't need to run at all if you aren't accepting inbound messages and nothing is in the queue.
Matthew Garrett wrote:
I'm pretty solidly of the opinion that email is nowhere near being the most sensible way to get important information to a typical desktop user. If a failure is important then the user needs to know about it as soon as possible - mail provides no guarantees about timely delivery. We have plenty of desktop infrastructure to give important alerts to users, we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other notification method would have succeeded. The important point is that the user may not be present when the event occurs, and that desktop infrastructure may not even be running - and even if it is, the interested party may want the notification to be forwarded elsewhere.
Local delivery of mail is a poor solution, since it provides no indication of priority difference between "You've got spam" and "Your hard drive is failing".
That's a solvable problem within the context of email, whereas starting from scratch and re-inventing delivery to arbitrary user-selectable endpoints is somewhat insane.
If there's nobody to present it to, it can be queued and presented at login - if the user is running on their system but doesn't have the desktop infrastructure running, then by definition they're already outside the standard desktop usecase.
Does that mean their system should die with no attempt at notification? Or that desktop administration should be confusingly different than standard systems?
I'm not arguing about the utility of an MTA for various situations. I'm arguing that for one specific and very common situation, using an MTA to deliver system alerts is a poor way of handling it. We should fix that.
No, you should fix it so mail delivery is useful.
As a happy side effect, it removes the need for a default MTA in the desktop install.
Unless, of course, you care to follow standards.
People who want an MTA then get to choose whichever MTA they want and net human happiness is increased.
That has been the case for some time already. As long as the alternative presents a command-line compatible /usr/sbin/sendmail, standard programs will work.
On Tue, Oct 21, 2008 at 10:10:37AM -0500, Les Mikesell wrote:
Matthew Garrett wrote:
Local delivery of mail is a poor solution, since it provides no indication of priority difference between "You've got spam" and "Your hard drive is failing".
That's a solvable problem within the context of email, whereas starting from scratch and re-inventing delivery to arbitrary user-selectable endpoints is somewhat insane.
I'm sure the anti-spam companies would be delighted to hear it. Yes, it's a solvable problem - but you're conflating two things, important system updates and personal email. I think trying to present these two quite different things in the same way is a bad idea.
If there's nobody to present it to, it can be queued and presented at login - if the user is running on their system but doesn't have the desktop infrastructure running, then by definition they're already outside the standard desktop usecase.
Does that mean their system should die with no attempt at notification? Or that desktop administration should be confusingly different than standard systems?
I'm reasonably sure that I didn't suggest that, no.
I'm not arguing about the utility of an MTA for various situations. I'm arguing that for one specific and very common situation, using an MTA to deliver system alerts is a poor way of handling it. We should fix that.
No, you should fix it so mail delivery is useful.
And then have to modify every single MUA so it automatically flags high-priority system information. I'm not convinced getting that into gmail is going to happen.
Matthew Garrett wrote:
Local delivery of mail is a poor solution, since it provides no indication of priority difference between "You've got spam" and "Your hard drive is failing".
That's a solvable problem within the context of email, whereas starting from scratch and re-inventing delivery to arbitrary user-selectable endpoints is somewhat insane.
I'm sure the anti-spam companies would be delighted to hear it. Yes, it's a solvable problem - but you're conflating two things, important system updates and personal email. I think trying to present these two quite different things in the same way is a bad idea.
I think it is a bad idea for you to decide which of those things is more important to me or anyone else, or where I want them delivered. Just supply the tools, please, with some convenient default setting so the system messages are available.
If there's nobody to present it to, it can be queued and presented at login - if the user is running on their system but doesn't have the desktop infrastructure running, then by definition they're already outside the standard desktop usecase.
Does that mean their system should die with no attempt at notification? Or that desktop administration should be confusingly different than standard systems?
I'm reasonably sure that I didn't suggest that, no.
If you don't use email, you will have to invent something new that will almost certainly be less capable and less useful.
I'm not arguing about the utility of an MTA for various situations. I'm arguing that for one specific and very common situation, using an MTA to deliver system alerts is a poor way of handling it. We should fix that.
No, you should fix it so mail delivery is useful.
And then have to modify every single MUA so it automatically flags high-priority system information. I'm not convinced getting that into gmail is going to happen.
No, you don't have to modify every MUA. You just have to let people use the one they have had years to tune to their liking already. And supply some reasonable default for the one or two users you might pick up that don't already have a preference or an assortment of accounts already created for different priority messages.
On Tue, Oct 21, 2008 at 3:33 PM, Les Mikesell lesmikesell@gmail.com wrote:
Matthew Garrett wrote:
Local delivery of mail is a poor solution, since it provides no indication of priority difference between "You've got spam" and "Your hard drive is failing".
That's a solvable problem within the context of email, whereas starting from scratch and re-inventing delivery to arbitrary user-selectable endpoints is somewhat insane.
I'm sure the anti-spam companies would be delighted to hear it. Yes, it's a solvable problem - but you're conflating two things, important system updates and personal email. I think trying to present these two quite different things in the same way is a bad idea.
I think it is a bad idea for you to decide
Let's be clear - this is a meritocracy, not a vote-by-email-repetition system.
Colin Walters wrote:
Local delivery of mail is a poor solution, since it provides no indication of priority difference between "You've got spam" and "Your hard drive is failing".
That's a solvable problem within the context of email, whereas starting from scratch and re-inventing delivery to arbitrary user-selectable endpoints is somewhat insane.
I'm sure the anti-spam companies would be delighted to hear it. Yes, it's a solvable problem - but you're conflating two things, important system updates and personal email. I think trying to present these two quite different things in the same way is a bad idea.
I think it is a bad idea for you to decide
Let's be clear - this is a meritocracy, not a vote-by-email-repetition system.
If you don't permit the 'merit' to be decided by potential users of the system you are designing a vote-by-feet system.
On Tue, Oct 21, 2008 at 02:53:59PM -0500, Les Mikesell wrote:
Colin Walters wrote:
Let's be clear - this is a meritocracy, not a vote-by-email-repetition system.
If you don't permit the 'merit' to be decided by potential users of the system you are designing a vote-by-feet system.
Nobody's talking about removing MTAs from the repository. Potential users are always free to decide how their system works.
On Tue, 21 Oct 2008 08:52:27 -0500 Les Mikesell lesmikesell@gmail.com wrote:
I'm pretty solidly of the opinion that email is nowhere near being the most sensible way to get important information to a typical desktop user. If a failure is important then the user needs to know about it as soon as possible - mail provides no guarantees about timely delivery. We have plenty of desktop infrastructure to give important alerts to users, we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other notification method would have succeeded.
local mail is rather taxing on a system. If a harddisk is marginal for example... a mail delivery will cause the entire pagecache to be written to the disk, and guess what... the MTA will get stuck on that.
And that assumes that the local user even reads "root" email.
On Tue, Oct 21, 2008 at 07:29:50AM -0700, Arjan van de Ven wrote:
And that assumes that the local user even reads "root" email.
This definitely needs to be addressed as part of this discussion. There's two parts, really:
1) Root mail needs to go somewhere useful. 2) The world needs something better than Logwatch.
Arjan van de Ven wrote:
On Tue, 21 Oct 2008 08:52:27 -0500 Les Mikesell lesmikesell@gmail.com wrote:
I'm pretty solidly of the opinion that email is nowhere near being the most sensible way to get important information to a typical desktop user. If a failure is important then the user needs to know about it as soon as possible - mail provides no guarantees about timely delivery. We have plenty of desktop infrastructure to give important alerts to users, we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other notification method would have succeeded.
local mail is rather taxing on a system.
Which is why mail is a sensible delivery mechanism. It already knows how to deliver elsewhere if you want.
If a harddisk is marginal for example... a mail delivery will cause the entire pagecache to be written to the disk, and guess what... the MTA will get stuck on that.
Which is why it is important to get the warning messages from smartctl and the disk space check _before_ you are toast. Face it - nothing is going to save you after the disk fries or is completely out of space.
And that assumes that the local user even reads "root" email.
That's the piece that needs to be fixed.
Les Mikesell (lesmikesell@gmail.com) said:
Which is why mail is a sensible delivery mechanism. It already knows how to deliver elsewhere if you want.
With built-in mechanisms to allow for easy spoofing of critical events to the user from anyone on the internet, no less!
This is outside of the issue that any such critical notification delivered via e-mail makes it nigh-impossible to safely and sanely undertake specific actions on user input acting on the notice.
Should the information be sent via e-mail to an adminstrator, and stored for later viewing in general? Yes. Does that mean e-mail is the best mechanism for presenting it? No.
Bill
Bill Nottingham wrote:
Les Mikesell (lesmikesell@gmail.com) said:
Which is why mail is a sensible delivery mechanism. It already knows how to deliver elsewhere if you want.
With built-in mechanisms to allow for easy spoofing of critical events to the user from anyone on the internet, no less!
I'm surprised you are able to do that with fedora's default mail configuration that only accepts from localhost... Perhaps you should let us in on the secret.
This is outside of the issue that any such critical notification delivered via e-mail makes it nigh-impossible to safely and sanely undertake specific actions on user input acting on the notice.
What? If there was a specific way to fix the problem you should just do it without bothering a user.
Should the information be sent via e-mail to an adminstrator, and stored for later viewing in general? Yes. Does that mean e-mail is the best mechanism for presenting it? No.
If you have a bad email mechanism, fix that problem.
-- Les Mikesell lesmikesell@gmail.com
Les Mikesell (lesmikesell@gmail.com) said:
Bill Nottingham wrote:
Les Mikesell (lesmikesell@gmail.com) said:
Which is why mail is a sensible delivery mechanism. It already knows how to deliver elsewhere if you want.
With built-in mechanisms to allow for easy spoofing of critical events to the user from anyone on the internet, no less!
I'm surprised you are able to do that with fedora's default mail configuration that only accepts from localhost... Perhaps you should let us in on the secret.
????
We're talking about arbitrary mail delivery. It could be forwarded to any e-mail account, anywhere. (After all, that's what you're asking for with redirection of root e-mail.) Ergo, anyone with knowledge of 1) your e-mail address 2) your machine could send you a spoof/phishing/etc.
Should the information be sent via e-mail to an adminstrator, and stored for later viewing in general? Yes. Does that mean e-mail is the best mechanism for presenting it? No.
If you have a bad email mechanism, fix that problem.
I think attempting to have all cron/alert/whatever mail gpg-signed with a host-specific key would be waaaaaaaaaaaay overkill.
Bill
Bill Nottingham wrote:
Which is why mail is a sensible delivery mechanism. It already knows how to deliver elsewhere if you want.
With built-in mechanisms to allow for easy spoofing of critical events to the user from anyone on the internet, no less!
I'm surprised you are able to do that with fedora's default mail configuration that only accepts from localhost... Perhaps you should let us in on the secret.
????
We're talking about arbitrary mail delivery. It could be forwarded to any e-mail account, anywhere. (After all, that's what you're asking for with redirection of root e-mail.) Ergo, anyone with knowledge of
- your e-mail address 2) your machine could send you a spoof/phishing/etc.
But that's true whether or not you use it yourself. And it is relatively difficult to spoof the originating host IP since it is recorded by the receiving server.
Should the information be sent via e-mail to an adminstrator, and stored for later viewing in general? Yes. Does that mean e-mail is the best mechanism for presenting it? No.
If you have a bad email mechanism, fix that problem.
I think attempting to have all cron/alert/whatever mail gpg-signed with a host-specific key would be waaaaaaaaaaaay overkill.
The value of unix-like systems is that they provide the user with a standard toolbox to be used in an appropriate way for any situation. Good working defaults are just a plus - the tools, and the fact that they follow standards, are the critical part.
On Tue, Oct 21, 2008 at 11:44:01AM -0400, Bill Nottingham wrote:
I think attempting to have all cron/alert/whatever mail gpg-signed with a host-specific key would be waaaaaaaaaaaay overkill.
Although relatively easily-accomplished overkill. :)
On Tue, Oct 21, 2008 at 02:20:03PM +0100, Matthew Garrett wrote:
I'm pretty solidly of the opinion that email is nowhere near being the most sensible way to get important information to a typical desktop user. If a failure is important then the user needs to know about it as soon as possible - mail provides no guarantees about timely delivery. We have plenty of desktop infrastructure to give important alerts to users, we're just failing to do so.
Important does not always mean urgent, and there are a lot of cases when the person in front of the keyboard, if any, is not the one interested in the information.
Another way to say it is "stop thinking in Microsoft Windows terms".
OG.
On Mon, 2008-10-20 at 13:23 -0500, Les Mikesell wrote:
And maybe if a bazillion ssh login attempts have failed.
No. SSH scanning is commonplace nowadays. All my exposed machines are constantly pounded on by rumplestiltskin bots. Alerting on this would equate to "Congratulations, you are using the internet!" every 5 minutes...
On Sun, Oct 19, 2008 at 7:47 PM, seth vidal skvidal@fedoraproject.org wrote:
On Sun, 2008-10-19 at 15:32 -0400, Colin Walters wrote:
But it doesn't make sense for the default desktop OS to be sending you email about all the junk going on under the hood.
I understand where you are coming from but I have to say the above statement is, imo, fundamentally wrong.
I am in mixed boat about this... trying to go through 100+ logwatches every day is a headache as it is :). But knowing that there is a failed cron job on some desktop because the rootkit was b0rked is valuable... but I am not the average user.
So the first question that comes to mind.. is if the user doesn't know that the email is being generated.. does it matter it exists? And what environments are we dealing with?
1) Home use. Does Grandma want to know about logwatch or noisy cron jobs? Does she even know that there is email in the root user mailbox since she shouldn't ever log into it?
2) Small scale environment. (2-30 systems). 3) Medium environment (30-100) systems. 4) Large environment 100-1000 systems 5) Ginormouse 1000+ systems.
Each has its use case. When you get to the large to ginormous ones.. you really need to work on the tools for centralized logging, with agents and things to track usage.
The small to medium are the ones which are probably the ones that need more work. The Small one might have someone who knows to look at the root mail spool but most of the time its going to be someone who has his worn "Linux for Dummies" book from the last person who set up the lab.
Email only makes sense for this person if a) its easy to setup. b) it gives useful information. c) and they know what to do with it.
It really doesn't matter if a box has postfix, exim, ssmtp, smail, etc if the email is just stuck on the local machine and the user has no idea where it is, how to get it, or what it does. And in that case, does generating the email in the first place help anything? If this were some new service versus one that we system administrators have been raised to think as a god-given right.. and we were looking at adding it to the desktop environment would we? [I am talking about the default state where email stays local, and the local user probably has no idea its there.]
On Sun, 19 Oct 2008 21:26:24 +0200 Karel Zak kzak@redhat.com wrote:
On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality...
(+1)
Good point, but don't forget that Fedora is pretty ambivalent distribution. It's a "desktop distribution" where some people want to disable non-X console and other people use postfix, port packages to s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a base for Red Hat Enterprise distribution :-)
I'm all in favor having any and all of those as options. Really. For the people who want to run a mail server, they absolutely should. But those already have to significantly customize their OS already. Installing a MTA of their choice as part of that is no big deal, and probably entirely expected by those who really want to run a mail server.
But I stand by: The default: none of the above.
On Sun, Oct 19, 2008 at 12:42:17PM -0700, Arjan van de Ven wrote:
On Sun, 19 Oct 2008 21:26:24 +0200 Karel Zak kzak@redhat.com wrote:
On Sun, Oct 19, 2008 at 11:37:16AM -0700, Arjan van de Ven wrote:
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality...
(+1)
Good point, but don't forget that Fedora is pretty ambivalent distribution. It's a "desktop distribution" where some people want to disable non-X console and other people use postfix, port packages to s390, maintain GFS2 stuff and Spacewalk -- and finally it should be a base for Red Hat Enterprise distribution :-)
I'm all in favor having any and all of those as options. Really. For the people who want to run a mail server, they absolutely should. But those already have to significantly customize their OS already. Installing a MTA of their choice as part of that is no big deal, and probably entirely expected by those who really want to run a mail server.
But I stand by: The default: none of the above.
I agree. Definitely. (I use esmtp(1) for years).
Karel
On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
There's two types of people using fedora:
- People who don't run a mail server
I think you meant to add _incoming_ in there, having mail that's generated on the local machine go somewhere _reliably_ is a basic feature required by all users.
For 1), all three are wrong. Really. All you really need is some minimalist commandline compatible thing that just forwards to some smart host (or maybe does only local delivery).
Or both, and the forwarding has to work when the network is down.
SSMTP or similar is perfectly fine for this, while not taxing memory or boot time.
Yeh, right. SSMTP doesn't have a spool, so anything sending email when the network is down gets their email silently deleted. hell, SSMTP doesn't even support aliases. Look, feel free to have the default be postfix; configured to sendmail locally and/or remotely ... with no daemon and thus. no inbound processing. SSMTP is just worthless for most users, hell having nothing at all would be better (but be ready for every package that needs to send email to point out not having an smtp sender installed by default is retarded).
For 2) these folks have a VERY specific personal preference.
Not true.
This entire discussion proves that.
Right, when almost everyone is saying change to postfix and one or two people are saying "what's so wrong with sendmail" ... that must mean we should do nothing *sigh*.
On Sun, 19 Oct 2008 21:48:13 -0400 James Antill james@fedoraproject.org wrote:
On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
There's two types of people using fedora:
- People who don't run a mail server
I think you meant to add _incoming_ in there, having mail that's generated on the local machine go somewhere _reliably_ is a basic feature required by all users.
most users on the client side use a mail client that has its own queuing.
Once upon a time, Arjan van de Ven arjan@infradead.org said:
most users on the client side use a mail client that has its own queuing.
Most _interactive_ users do. Most automated tasks (e.g. cron) do not have any queueing.
Chris Adams wrote:
Once upon a time, Arjan van de Ven arjan@infradead.org said:
most users on the client side use a mail client that has its own queuing.
Most _interactive_ users do. Most automated tasks (e.g. cron) do not have any queueing.
Even if you are trying to dumb the system down to a Mac's pseudo-single-user style, you still need crontab and mail to work - as it does on a Mac.
Les Mikesell wrote:
Chris Adams wrote:
Once upon a time, Arjan van de Ven arjan@infradead.org said:
most users on the client side use a mail client that has its own queuing.
Most _interactive_ users do. Most automated tasks (e.g. cron) do not have any queueing.
Even if you are trying to dumb the system down to a Mac's pseudo-single-user style, you still need crontab and mail to work - as it does on a Mac.
What happens to emails generated on a Max OSX via crontab or any other automated system? Does it run sendmail or some equivalent of it?
Just curious how they solve it as on a Mac i'd bet you that hardly any typical user will know what root is.
Regards, Phil
On Mon, 2008-10-20 at 17:34 +0200, Phil Knirsch wrote:
Les Mikesell wrote:
Chris Adams wrote:
Once upon a time, Arjan van de Ven arjan@infradead.org said:
most users on the client side use a mail client that has its own queuing.
Most _interactive_ users do. Most automated tasks (e.g. cron) do not have any queueing.
Even if you are trying to dumb the system down to a Mac's pseudo-single-user style, you still need crontab and mail to work - as it does on a Mac.
What happens to emails generated on a Max OSX via crontab or any other automated system?
No clue about the MACs, but what about "mailx"?
It is mandated by POSIX and should be sufficient for local mail delivery.
Ralf
Ralf Corsepius rc040203@freenet.de wrote:
On Mon, 2008-10-20 at 17:34 +0200, Phil Knirsch wrote:
[...]
What happens to emails generated on a Max OSX via crontab or any other automated system?
No clue about the MACs, but what about "mailx"?
It is mandated by POSIX and should be sufficient for local mail delivery.
Its manpage here doesn't mention local delivery, just caching and disconnected operation for IMAP.
[Local delivery is normally handled by a separate program in any case, today typically procmail]
Phil Knirsch wrote:
Les Mikesell wrote:
Chris Adams wrote:
Once upon a time, Arjan van de Ven arjan@infradead.org said:
most users on the client side use a mail client that has its own queuing.
Most _interactive_ users do. Most automated tasks (e.g. cron) do not have any queueing.
Even if you are trying to dumb the system down to a Mac's pseudo-single-user style, you still need crontab and mail to work - as it does on a Mac.
What happens to emails generated on a Max OSX via crontab or any other automated system? Does it run sendmail or some equivalent of it?
10.5 runs postfix.
Just curious how they solve it as on a Mac i'd bet you that hardly any typical user will know what root is.
I don't think anything in the default install sends mail, but if as a user you use 'crontab -e' to create a crontab entry, the output is delivered to /var/mail/yourlogin and the command line mail and mailx programs know where to find it as expected on any unix-like system. Or you can set MAILTO= in the crontab if you want it elsewhere. Following standards is a good thing...
Le Lun 20 octobre 2008 03:48, James Antill a écrit :
On Sun, 2008-10-19 at 11:37 -0700, Arjan van de Ven wrote:
Forget about Sendmail. Or Exim. Or Postfix as default install.
Really.
There's two types of people using fedora:
- People who don't run a mail server
I think you meant to add _incoming_ in there, having mail that's generated on the local machine go somewhere _reliably_ is a basic feature required by all users.
Also filtering mail on MUA startup is just trainwreak recipe. If you want your MUA to start fast you need to pre-filter junk mail in the background (no not everyone uses gmail and gmail is not perfect anyway).
So far, I haven't seen anything beating fetchmail + local MTA + server-side filters + local imap or local maildir delivery in Fedora.
On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
Also filtering mail on MUA startup is just trainwreak recipe. If you want your MUA to start fast you need to pre-filter junk mail in the background (no not everyone uses gmail and gmail is not perfect anyway).
So far, I haven't seen anything beating fetchmail + local MTA + server-side filters + local imap or local maildir delivery in Fedora.
But if you're using fetchmail, it's too late to filter -- because you should be rejecting the stuff you don't want at SMTP time.
Filtering wants to be done on the _real_ mail server that accepts incoming mail. Doing it after fetchmail is almost as bad as doing it in the MUA.
Le Mar 21 octobre 2008 10:05, David Woodhouse a écrit :
On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
Also filtering mail on MUA startup is just trainwreak recipe. If you want your MUA to start fast you need to pre-filter junk mail in the background (no not everyone uses gmail and gmail is not perfect anyway).
So far, I haven't seen anything beating fetchmail + local MTA + server-side filters + local imap or local maildir delivery in Fedora.
But if you're using fetchmail, it's too late to filter -- because you should be rejecting the stuff you don't want at SMTP time.
Filtering wants to be done on the _real_ mail server that accepts incoming mail.
Sure but many people do not have an ISP that provides clueful filtering, and even gmail is not so yummy when you take the privacy and no warranty bits into account.
Doing it after fetchmail is almost as bad as doing it in the MUA.
It's not. It means that when you start your MUA, everything is already available and filtered, instead for waiting for (10s or more) seconds with a massive CPU pike. That makes a huge user experience difference.
Nicolas Mailhot wrote:
Also filtering mail on MUA startup is just trainwreak recipe. If you want your MUA to start fast you need to pre-filter junk mail in the background (no not everyone uses gmail and gmail is not perfect anyway).
So far, I haven't seen anything beating fetchmail + local MTA + server-side filters + local imap or local maildir delivery in Fedora.
But if you're using fetchmail, it's too late to filter -- because you should be rejecting the stuff you don't want at SMTP time.
Filtering wants to be done on the _real_ mail server that accepts incoming mail.
Sure but many people do not have an ISP that provides clueful filtering, and even gmail is not so yummy when you take the privacy and no warranty bits into account.
Doing it after fetchmail is almost as bad as doing it in the MUA.
It's not. It means that when you start your MUA, everything is already available and filtered, instead for waiting for (10s or more) seconds with a massive CPU pike. That makes a huge user experience difference.
The problems are that you don't have a reasonable choice about what to do with questionable items at that point and the mail has already been accepted from the sender, establishing that you are a valid target if it really is spam, probably getting it put on widely sold lists. If your filter generates a bounce it will probably go to a forged address and contribute to the problem. On the other hand if you don't generate a bounce and your filter is mistaken, you lose legitimate messages - or you have to save them in a folder that you manually check. If you can scan during the smtp conversation with the sender you can just reject at that point making it someone else's problem.
What about this (maybe silly) idea:
The default desktop installation is not providing a mta like sendmail, postfix or exim. A tiny local program is using syslog to collect local emails in a file in /var/log in mailbox format. This way emails e.g. from cron or mdadm are not lost and a local email reader could be used to read the emails. Additionally logrotate would help to keep the amount of emails at an acceptable level. SELinux shouldn't be a problem for this solution.
A symlink to /var/spool/mail would be nice, but I think that SELinux does not like this at all.
If a user needs fetchmail or a real mta, he has to install sendmail, postfix or exim. fetchmail could have a requirement for MTA.
What do you think?
Ciao, Thomas
David Woodhouse wrote:
On Mon, 2008-10-20 at 10:51 +0200, Nicolas Mailhot wrote:
Also filtering mail on MUA startup is just trainwreak recipe. If you want your MUA to start fast you need to pre-filter junk mail in the background (no not everyone uses gmail and gmail is not perfect anyway).
So far, I haven't seen anything beating fetchmail + local MTA + server-side filters + local imap or local maildir delivery in Fedora.
But if you're using fetchmail, it's too late to filter -- because you should be rejecting the stuff you don't want at SMTP time.
Filtering wants to be done on the _real_ mail server that accepts incoming mail. Doing it after fetchmail is almost as bad as doing it in the MUA.
On Tue, Oct 21, 2008 at 12:50:48PM +0200, Thomas Woerner wrote:
What about this (maybe silly) idea:
The default desktop installation is not providing a mta like sendmail, postfix or exim. A tiny local program is using syslog to collect local emails in a file in /var/log in mailbox format. This way emails e.g. from cron or mdadm are not lost and a local email reader could be used to read the emails. Additionally logrotate would help to keep the amount of emails at an acceptable level. SELinux shouldn't be a problem for this solution.
Your tiny local program is not going to stay tiny long. Feature creep (multiple log files, routing, filtering, locking...) is going to make it equivalent to a mail delivery agent. So just use one.
OG.
Le Dim 19 octobre 2008 20:37, Arjan van de Ven a écrit :
Anybody trying to argue for the politics of Exim/Postfix/Sendmail as default choice is ignoring the reality...
Fedora is about advancing the state of free software right? And free software does not limit itself to the desktop.
Or I don't see why all the fuss about wikipedia switching side is.
On Sun, 2008-10-19 at 13:04 -0500, Les Mikesell wrote:
David Woodhouse wrote:
On Sun, 2008-10-19 at 09:47 -0500, Les Mikesell wrote:
Which means that you can't run your choice of tests on a message during the smtp conversation before you accept it - at least without starting a new process for each one which is expensive for large programs like spamassassin.
As is often the case, it seems, you are entirely incorrect.
One of my choices of tests on an inbound relay machine has been to check that the user exists using an smtp check against the internal delivery host. How would I do that on an MTA that does not handle milters?
require verify = recipient/callout=20s,use_sender
Les Mikesell lesmikesell@gmail.com writes:
One of my choices of tests on an inbound relay machine has been to check that the user exists using an smtp check against the internal delivery host. How would I do that on an MTA that does not handle milters?
Milters are bad for rcpt verification (at least in sendmail) because they happen before alias/virtusertable expansion. Custom 'Local_check_rcpt' rules plus tables like
| Kdom0_lookup hash -o /etc/mail/dom0-users | Kdom1_lookup socket inet:480@mail-filter
are better and easier to implement.
Enrico
Enrico Scholz wrote:
Les Mikesell lesmikesell@gmail.com writes:
One of my choices of tests on an inbound relay machine has been to check that the user exists using an smtp check against the internal delivery host. How would I do that on an MTA that does not handle milters?
Milters are bad for rcpt verification (at least in sendmail) because they happen before alias/virtusertable expansion. Custom 'Local_check_rcpt' rules plus tables like
In my case, this happens on external relays that have neither aliases nor users of its own. The idea is to make sure the internal target would accept the address as a user or alias without having to update the external relay's virtuser database every time an internal user or alias changes.
Le Dim 19 octobre 2008 16:47, Les Mikesell a écrit :
David Woodhouse wrote:
On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Some of the better alternatives don't even _try_ to run milters, because they are fully-featured enough in their own right, without needing to rely on external software.
Which means that you can't run your choice of tests on a message during the smtp conversation before you accept it - at least without starting a new process for each one which is expensive for large programs like spamassassin.
Actually, you don't need milters to do this in postfix (but you can use milters if you prefer)
Nicolas Mailhot wrote:
Le Dim 19 octobre 2008 16:47, Les Mikesell a écrit :
David Woodhouse wrote:
On Fri, 2008-10-17 at 08:13 -0500, Les Mikesell wrote:
Milter is supported by alternatives too
They pretend to, but won't actually run complex milters like MimeDefang.
Some of the better alternatives don't even _try_ to run milters, because they are fully-featured enough in their own right, without needing to rely on external software.
Which means that you can't run your choice of tests on a message during the smtp conversation before you accept it - at least without starting a new process for each one which is expensive for large programs like spamassassin.
Actually, you don't need milters to do this in postfix (but you can use milters if you prefer)
If you do it without milters, can you get the efficiency factor that MimeDefang manages by unpacking the mime parts only once even if you do multiple scans for spam and viruses? Can it multiplex a small number of milter backends doing 'slow' steps with a much larger number of mailers doing fast operations? (MimeDefang may be the only milter designed for that).
On Fri, Oct 17, 2008 at 4:18 PM, Denis Leroy denis@poolshark.org wrote:
Les Mikesell wrote:
It can be configured to do just about anything.
The sendmail configuration file is arguably one of the most complex and obfuscated configuration format ever designed in the history of computer science. :-)
-denis
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
....so why not try exim4 for a change?
Alan Cox wrote:
On Fri, Oct 17, 2008 at 03:18:52PM +0200, Denis Leroy wrote:
The sendmail configuration file is arguably one of the most complex and obfuscated configuration format ever designed in the history of computer science. :-)
You've clearly never worked with either IBM JCL or TECO
=3.4.2;;;;;;;;;;;;;;;;;;;;;;
-- bk
Denis Leroy wrote:
Les Mikesell wrote:
It can be configured to do just about anything.
The sendmail configuration file is arguably one of the most complex and obfuscated configuration format ever designed in the history of computer science. :-)
Yes, it was designed back in the days of wooden computers and iron programmers - with a prime concern being the runtime processing needed to interpret the configuration. But these days all of the m4 templates anyone might ever need have already been written, so everyone just uncomments or tweaks a few lines in sendmail.mc for options and the default already does the right thing for most people. Or, for complex scenarios you can drop in MimeDefang as a milter and do most of the control steps with perl snippets.
On Fri, Oct 17, 2008 at 7:31 AM, Lutz Lange llange@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
A note - the desktop spin would like to have no MTA by default for F11. We'll likely change the way cron is handled so that if you have per-user cron jobs an MTA is installed.
What MTA the server images use is up to whoever owns server stuff (I like Postfix too personally).
Colin Walters wrote:
A note - the desktop spin would like to have no MTA by default for F11. We'll likely change the way cron is handled so that if you have per-user cron jobs an MTA is installed.
What happens to root's cron jobs (e.g. logwatch)? Do they just go to /dev/null, or do you have some cool new log monitor?
On Fri, Oct 17, 2008 at 8:06 PM, Matthew Woehlke mw_triad@users.sourceforge.net wrote:
Colin Walters wrote:
A note - the desktop spin would like to have no MTA by default for F11. We'll likely change the way cron is handled so that if you have per-user cron jobs an MTA is installed.
What happens to root's cron jobs (e.g. logwatch)? Do they just go to /dev/null, or do you have some cool new log monitor?
/dev/null by default. In the longer term what I would like to see is *some* of this kind of thing integrated with: http://fedoraproject.org/wiki/Features/CrashHandling But most logs from a desktop machine are just pure noise.
Colin Walters wrote:
On Fri, Oct 17, 2008 at 8:06 PM, Matthew Woehlke mw_triad@users.sourceforge.net wrote:
Colin Walters wrote:
A note - the desktop spin would like to have no MTA by default for F11. We'll likely change the way cron is handled so that if you have per-user cron jobs an MTA is installed.
What happens to root's cron jobs (e.g. logwatch)? Do they just go to /dev/null, or do you have some cool new log monitor?
/dev/null by default. In the longer term what I would like to see is *some* of this kind of thing integrated with: http://fedoraproject.org/wiki/Features/CrashHandling But most logs from a desktop machine are just pure noise.
Yes and no. I'd prefer to see some sort of event viewer that would do logwatch, but with much more terse, consolidated output (and by default throw out all but the last N days' entries).
Even on desktops, I'd like to watch who's logging in, but it's such a pain to do right now...
Matthew Woehlke wrote:
Yes and no. I'd prefer to see some sort of event viewer that would do logwatch, but with much more terse, consolidated output (and by default throw out all but the last N days' entries).
Even on desktops, I'd like to watch who's logging in, but it's such a pain to do right now...
gnome-system-log (gnome-utils) might help. KDE has a log viewer as well. Might consider working on it to do what you want it to do otherwise.
Rahul
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
Some people (/me waves) were concerned about the element of surprise when someone configures a new system, throws some (user) cron jobs on it, and expects local mail delivery to Just Work.
I also suggested that setting up what happens to cron's mail in anaconda/firstboot would be an adequate solution. However it was too late to do this for F10.
What I'd be interested in for F11 is a screen during install that requires you to either provide a valid e-mail address recipient for root's mail and the default user's mail (with, I suppose, any other mail going to whatever is set up for root), or else explicitly requesting a local-mail capable MTA.
Um... which is actually another reason for local mail being default; in the event a user's mail recipient is not configured, it goes to a local spool only readable by root and that user. If Sue sets up a computer and adds an account for Bob, it's not really ideal if Bob's mail gets sent to sue@mydomain.com because Bob doesn't have a recipient specified. True, Sue probably has root access and could read Bob's mail if she wanted, but you've gone the extra step to tossing Bob's mail in Sue's inbox without warning.
On Fri, 2008-10-17 at 19:07 -0500, Matthew Woehlke wrote:
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
Some people (/me waves) were concerned about the element of surprise when someone configures a new system, throws some (user) cron jobs on it, and expects local mail delivery to Just Work.
sendmail isn't the only mta in fedora that just works out of the box. I know postfix does and I believe exim does as well.
-sv
seth vidal wrote:
On Fri, 2008-10-17 at 19:07 -0500, Matthew Woehlke wrote:
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
Some people (/me waves) were concerned about the element of surprise when someone configures a new system, throws some (user) cron jobs on it, and expects local mail delivery to Just Work.
sendmail isn't the only mta in fedora that just works out of the box. I know postfix does and I believe exim does as well.
And did anyone have an actual problem with sendmail other than noticing it taking time to start the daemon in the boot sequence. That's a problem that can be solved on its own since you don't really need a daemon then.
Removing mail from the expected services is just the wrong thing to do, especially if the reasoning is that the service isn't understood or used to advantage. Add a setup for a root alias in firstboot and a mail notifier in the gnome panel to make the system more useful instead of less.
Le samedi 18 octobre 2008 à 12:03 -0500, Les Mikesell a écrit :
And did anyone have an actual problem with sendmail other than noticing it taking time to start the daemon in the boot sequence.
I think each one of us who've replaced sendmail with something else has (despite years of RH/Fedora trying force sendmail through our throats).
Even back when postfix was just a powertools option people knew sendmail was a poor default.
As an engineer who likes neat technical stuff and contributes to Fedora because it tends to produce neat technical stuff it makes me cringe each time I'm reminded we ship sendmail instead of something properly designed for an untrusted TCP/IP network world.
You may extend years of hole-fixing and patch a sieve enough it sort of floats but it's still a poor excuse of a boat. Even if passengers only see the "it floats" bit.
Nicolas Mailhot wrote:
Le samedi 18 octobre 2008 à 12:03 -0500, Les Mikesell a écrit :
And did anyone have an actual problem with sendmail other than noticing it taking time to start the daemon in the boot sequence.
I think each one of us who've replaced sendmail with something else has (despite years of RH/Fedora trying force sendmail through our throats).
Even back when postfix was just a powertools option people knew sendmail was a poor default.
Sendmail was a poor default back when it always ran everything as root and accepted and delivered in the same process. Maybe you didn't notice that has changed or the enforced separation of the queuing and delivery steps.
As an engineer who likes neat technical stuff and contributes to Fedora because it tends to produce neat technical stuff it makes me cringe each time I'm reminded we ship sendmail instead of something properly designed for an untrusted TCP/IP network world.
Ummm, when was the last time you saw a network exploit for sendmail? As I recall, postfix has also had some local exploits and probably more recently than sendmail.
You may extend years of hole-fixing and patch a sieve enough it sort of floats but it's still a poor excuse of a boat. Even if passengers only see the "it floats" bit.
You seem to have missed the sea change. And the capabilities added by the milter interface that it took the other contenders many years to duplicate properly.
Le samedi 18 octobre 2008 à 13:34 -0500, Les Mikesell a écrit :
You seem to have missed the sea change.
I didn't notice the "sea change" changing anything about sendmail's terrible monolithic architecture.
And again, upstream seems more convinced than you are about current sendmail's irremediable faults.
Nicolas Mailhot wrote:
Le samedi 18 octobre 2008 à 13:34 -0500, Les Mikesell a écrit :
You seem to have missed the sea change.
I didn't notice the "sea change" changing anything about sendmail's terrible monolithic architecture.
How are separate processes receiving to a queue, processing the queue, delivering locally, with any number of concurrent milters all running under potentially different non-root id's except for the operations that require it, monolithic?
And again, upstream seems more convinced than you are about current sendmail's irremediable faults.
The remedy was done years ago.
On Sat, 2008-10-18 at 13:34 -0500, Les Mikesell wrote:
Sendmail was a poor default back when it always ran everything as root and accepted and delivered in the same process. Maybe you didn't notice that has changed or the enforced separation of the queuing and delivery steps.
There is a significant difference between dropping privileges from one giant piece of code, and having exec boundaries that do separate tasks. Without arguing the more nuanced differences, one obvious and simple (and beneficial) difference is that SELinux can easily confine into separate domains on exec boundaries. Which is why everything is lumped into one sendmail_t, while postfix has a number of separate domains.
As an engineer who likes neat technical stuff and contributes to Fedora because it tends to produce neat technical stuff it makes me cringe each time I'm reminded we ship sendmail instead of something properly designed for an untrusted TCP/IP network world.
Ummm, when was the last time you saw a network exploit for sendmail?
There has been at least one remote buffer overflow in sendmail since postfix went 1.0.
You may extend years of hole-fixing and patch a sieve enough it sort of floats but it's still a poor excuse of a boat. Even if passengers only see the "it floats" bit.
You seem to have missed the sea change.
Probably, because most of us were already using something better before sendmail decided to do the minimum of fixes to it's code base.
And the capabilities added by the milter interface that it took the other contenders many years to duplicate properly.
Yes, sendmail has always had "more features" in that it was the first MTA to have a turing complete language embedded within it (and an awful one at that). But other MTAs have had the features everyone needs for a long time now, and postfix has been a better default for more than long enough for us to change it.
I'd also like to say that personally I still use exim, and I'm likely to continue to do so ... but I'm more than happy to see postfix as the default, because it's probably a better default than exim and an obviously better one than the current default.
On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
And did anyone have an actual problem with sendmail other than noticing it taking time to start the daemon in the boot sequence. That's a problem that can be solved on its own since you don't really need a daemon then.
Removing mail from the expected services is just the wrong thing to do, especially if the reasoning is that the service isn't understood or used to advantage. Add a setup for a root alias in firstboot and a mail notifier in the gnome panel to make the system more useful instead of less.
I never said anything about removing mail. I only said that making postfix the default doesn't mean losing functionality.
Personally, I'm in favor of changing it just to see what shakes out that we've forgotten or missed.
-sv
seth vidal wrote:
On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
And did anyone have an actual problem with sendmail other than noticing it taking time to start the daemon in the boot sequence. That's a problem that can be solved on its own since you don't really need a daemon then.
Removing mail from the expected services is just the wrong thing to do, especially if the reasoning is that the service isn't understood or used to advantage. Add a setup for a root alias in firstboot and a mail notifier in the gnome panel to make the system more useful instead of less.
I never said anything about removing mail. I only said that making postfix the default doesn't mean losing functionality.
It would have been earlier, but if in fact the current version is capable of running MimeDefang as a milter maybe they are finally equivalent.
On Sat, 2008-10-18 at 15:50 -0500, Les Mikesell wrote:
seth vidal wrote:
On Sat, 2008-10-18 at 12:03 -0500, Les Mikesell wrote:
And did anyone have an actual problem with sendmail other than noticing it taking time to start the daemon in the boot sequence. That's a problem that can be solved on its own since you don't really need a daemon then.
Removing mail from the expected services is just the wrong thing to do, especially if the reasoning is that the service isn't understood or used to advantage. Add a setup for a root alias in firstboot and a mail notifier in the gnome panel to make the system more useful instead of less.
I never said anything about removing mail. I only said that making postfix the default doesn't mean losing functionality.
It would have been earlier, but if in fact the current version is capable of running MimeDefang as a milter maybe they are finally equivalent.
for a couple of years now:
http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
-sv
seth vidal wrote:
And did anyone have an actual problem with sendmail other than noticing it taking time to start the daemon in the boot sequence. That's a problem that can be solved on its own since you don't really need a daemon then.
Removing mail from the expected services is just the wrong thing to do, especially if the reasoning is that the service isn't understood or used to advantage. Add a setup for a root alias in firstboot and a mail notifier in the gnome panel to make the system more useful instead of less.
I never said anything about removing mail. I only said that making postfix the default doesn't mean losing functionality.
It would have been earlier, but if in fact the current version is capable of running MimeDefang as a milter maybe they are finally equivalent.
for a couple of years now:
http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
Supporting the milter interface and actually running existing milters that expect sendmail on the other side are two different things. For example, milters may need to know if the connection is authenticated or using SSL. If you are going to claim sendmail compatibility or be a functional replacement you have to provide the same information, the same way whether it was described in the interface documentation or not. Postfix pre-2.4 didn't. It looks like it does now, but I still don't remember any mentions of people actually using it on the MimeDefang list.
And in any case, using MimeDefang as a sendmail milter eliminates most of the complaints anyone would have with sendmail itself since it lets you do the complex parts with control handled in perl instead of sendmail's internal language.
On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
seth vidal wrote:
for a couple of years now:
http://advosys.ca/viewpoints/2006/08/postfix-supports-milter/
Supporting the milter interface and actually running existing milters that expect sendmail on the other side are two different things. For example, milters may need to know if the connection is authenticated or using SSL. If you are going to claim sendmail compatibility or be a functional replacement you have to provide the same information, the same way whether it was described in the interface documentation or not. Postfix pre-2.4 didn't. It looks like it does now, but I still don't remember any mentions of people actually using it on the MimeDefang list.
So? We aren't talking about auto migrating people's existing sendmail deployments, which would require a higher level of compatibility. We are just talking about changing the default, to one which the majority of users are likely to prefer (I appreciate that you have a different preference, but even you must realize you are in a minority).
And in any case, using MimeDefang as a sendmail milter eliminates most of the complaints anyone would have with sendmail itself since it lets you do the complex parts with control handled in perl instead of sendmail's internal language.
Again, that would be your opinion ... and it is different to mine.
Dnia 2008-10-18, o godz. 23:37:23 James Antill james@fedoraproject.org napisał(a):
I appreciate that you have a different preference, but even you must realize you are in a minority
Please, show us numbers :)
Lam
On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
And in any case, using MimeDefang as a sendmail milter eliminates most of the complaints anyone would have with sendmail itself since it lets you do the complex parts with control handled in perl instead of sendmail's internal language.
Man, if you imply perl is anything better, no wonders you defend sendmail :-)
SCNR.
Simo Sorce wrote:
On Sat, 2008-10-18 at 16:13 -0500, Les Mikesell wrote:
And in any case, using MimeDefang as a sendmail milter eliminates most of the complaints anyone would have with sendmail itself since it lets you do the complex parts with control handled in perl instead of sendmail's internal language.
Man, if you imply perl is anything better, no wonders you defend sendmail :-)
Perl has done a lot of work for me (and lots of others) over the last couple of decades, while most of the languages that claim to be better haven't been able to work consistently from one year to the next, making you rewrite everything because they can't pick a syntax that works. Perl has only had one real syntax change from version 1 though 5, when it started interpolating @ in double-quoted strings.
On Sat October 18 2008, Matthew Woehlke wrote: [E-mail was changed]
Um... which is actually another reason for local mail being default; in the event a user's mail recipient is not configured, it goes to a local spool only readable by root and that user. If Sue sets up a computer and adds an account for Bob, it's not really ideal if Bob's mail gets sent to sue@EXAMPLE.com because Bob doesn't have a recipient specified.
Sending log file contents that may contain sensitive data via unencrypted e-mail is not a good thing to do imho.
Please do not quote my e-mail address unobfuscated in message bodies.
I guess the owner of your used mydomain.com e-mail has this wish, too. Unless it is one of your e-mail addresses, you should better use @example.com e-mail addresses. The example.com domain is there, to be used if you need an example domain.
Regards, Till
Till Maas wrote:
On Sat October 18 2008, Matthew Woehlke wrote: [E-mail was changed]
Um... which is actually another reason for local mail being default; in the event a user's mail recipient is not configured, it goes to a local spool only readable by root and that user. If Sue sets up a computer and adds an account for Bob, it's not really ideal if Bob's mail gets sent to sue@EXAMPLE.com because Bob doesn't have a recipient specified.
Sending log file contents that may contain sensitive data via unencrypted e-mail is not a good thing to do imho.
Modern MTA's can encrypt transmission if configured to.
On Mon October 20 2008, Les Mikesell wrote:
Till Maas wrote:
On Sat October 18 2008, Matthew Woehlke wrote: [E-mail was changed]
Um... which is actually another reason for local mail being default; in the event a user's mail recipient is not configured, it goes to a local spool only readable by root and that user. If Sue sets up a computer and adds an account for Bob, it's not really ideal if Bob's mail gets sent to sue@EXAMPLE.com because Bob doesn't have a recipient specified.
Sending log file contents that may contain sensitive data via unencrypted e-mail is not a good thing to do imho.
Modern MTA's can encrypt transmission if configured to.
Yes, this is possible, but how does this help a non technical user that does not know how to this? Also only the encryption of the e-mail itself and decrypting on a trusted machine really protects the sensitive data. This is probably to complicated for the targeted user, so it would be a lot easier to keep the data on the local machine.
Regards, Till
On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
Yes, this is possible, but how does this help a non technical user that does not know how to this?
Our Exim package should be using TLS by default on all outgoing connections (to mail servers which support it). And supporting TLS on incoming connections too.
If there are any _other_ ways it can be improved to help the users who are technical enough to want it, but not particularly familiar with it, then please file RFE bugs. We already ship sample config snippets for decent greylisting, spamassassin, clamav, etc.
On Tue October 21 2008, David Woodhouse wrote:
On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
Yes, this is possible, but how does this help a non technical user that does not know how to this?
Our Exim package should be using TLS by default on all outgoing connections (to mail servers which support it). And supporting TLS on incoming connections too.
If there are any _other_ ways it can be improved to help the users who are technical enough to want it, but not particularly familiar with it, then please file RFE bugs. We already ship sample config snippets for decent greylisting, spamassassin, clamav, etc.
I do not know, because I use gpg for encryption. And this was also not what this sub thread initially was about. It was about adding an option to the installer that may make unexperienced users send sensitive data via untrusted or unencrypted paths.
Regards, Till
On Tue October 21 2008, David Woodhouse wrote:
If there are any _other_ ways it can be improved to help the users who are technical enough to want it, but not particularly familiar with it, then please file RFE bugs. We already ship sample config snippets for decent greylisting, spamassassin, clamav, etc.
Uh, I should have thought faster while writing my previous mail, here is my RFE to make it easier to gpg encode mails:
https://bugzilla.redhat.com/show_bug.cgi?id=467867
Thanks & regards, Till
David Woodhouse wrote:
On Tue, 2008-10-21 at 12:59 +0200, Till Maas wrote:
Yes, this is possible, but how does this help a non technical user that does not know how to this?
Our Exim package should be using TLS by default on all outgoing connections (to mail servers which support it). And supporting TLS on incoming connections too.
Sendmail should do that too.
If there are any _other_ ways it can be improved to help the users who are technical enough to want it, but not particularly familiar with it, then please file RFE bugs. We already ship sample config snippets for decent greylisting, spamassassin, clamav, etc.
Including a MimeDefang package configured to do the same for sendmail would be good.
Lutz Lange wrote:
i've just wondered why sendmail is still the default MTA in Fedora. Please enlighten me?
Changing defaults only makes sense if we're going to get rid of the current default or we're going to put a lot of work into the alternative. Sendmail isn't about to disappear, and we don't do a lot of distro-specific work on MTAs, so there's little point to changing. If you prefer a different MTA, use it.
-- Chris