To begin programming one has to know what to program against. Right now no one knows what the perfered mail server is.
John Mizell
Am Sa, den 30.10.2004 schrieb John Mizell um 2:35:
When can we expect development to start on a Mail server Gui tool? It seems this is one of the last servers that does not have a gui.
John Mizell
Feel free to start programming :)
Btw. what do you mean with the term "mail server"? Any specific one of the 3 MTAs Fedora ships with (Sendmail, Postfix, Exim) or Cyrus-IMAPd or dovecot for the IMAP/POP3 serving?
Alexander
Am Sa, den 30.10.2004 schrieb John Mizell um 18:18:
To begin programming one has to know what to program against. Right now no one knows what the perfered mail server is.
John Mizell
Again, what stands the term "mail server" for you? The preferred MTA is certainly that one you are most experienced and knowing about. For the IMAP/POP3 server this may be a bit different, because it depends more on the environment you want to set up the IMAP/POP3 server for. The feature rich Cyrus-IMAPd is the most powerful available on *NIX and can handle really large mail user bases. I would think dovecot does not scale that good and has less capabilities.
Alexander
I disagree. I believe the fedora project needs to come to a consensus about which MTA or which imap/pop program is the preferred application. Just because you know an application does not mean it is the best one for the job. If I make that choice then I risk that the programming will go unused because other mail programs are preferred. I already know how to configure several MTAs and imap/pop servers. I am looking to keep the community effort in place not to push one's agenda.
John Mizell
On Sat, 2004-10-30 at 18:44 +0200, Alexander Dalloz wrote:
Am Sa, den 30.10.2004 schrieb John Mizell um 18:18:
To begin programming one has to know what to program against. Right now no one knows what the perfered mail server is.
John Mizell
Again, what stands the term "mail server" for you? The preferred MTA is certainly that one you are most experienced and knowing about. For the IMAP/POP3 server this may be a bit different, because it depends more on the environment you want to set up the IMAP/POP3 server for. The feature rich Cyrus-IMAPd is the most powerful available on *NIX and can handle really large mail user bases. I would think dovecot does not scale that good and has less capabilities.
Alexander
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
Am Sa, den 30.10.2004 schrieb John Mizell um 19:14:
I disagree. I believe the fedora project needs to come to a consensus about which MTA or which imap/pop program is the preferred application. Just because you know an application does not mean it is the best one for the job. If I make that choice then I risk that the programming will
I must say that I do not understand that argument. From my understanding what you say is in contrast giving the reason why there is hardly the one and always fitting MTA. If you know that you have the choice between alternates then just decide yourself, based on the project conditions.
go unused because other mail programs are preferred. I already know how to configure several MTAs and imap/pop servers. I am looking to keep the community effort in place not to push one's agenda.
What is the problem with the current alternates Fedora Core ships and the MTA switching mechanism?
John Mizell
Alexander
On Sat, 30 Oct 2004, John Mizell wrote:
I disagree. I believe the fedora project needs to come to a consensus about which MTA or which imap/pop program is the preferred application.
There is no one preferred MTA or pop/imap program. THere are already 2 or 3 MTA's included with Fedora, for example. If you try and force one you will have one large religious war on your hands, unless of course you pick Postfix for the MTA. :-)
Ducks and runs!!
Regards,
Tom
On 10/30/2004 11:10:36 AM, Tom Diehl wrote:
On Sat, 30 Oct 2004, John Mizell wrote:
If you try and force one you will have one large religious war on your hands, unless of course you pick Postfix for the MTA. :-)
postfix should be the default mta in a chroot jail. It satisfies the needs of the vast majority of users - and I think has a cleaner codebase and is easier to config then sendmail.
Sendmail should be available, but I think the default should be postfix.
I also think the default cron daemon should be fcron, but that's another thread ...
--On Saturday, October 30, 2004 7:20 PM +0000 "Michael A. Peters" mpeters@mac.com wrote:
postfix should be the default mta in a chroot jail. It satisfies the needs of the vast majority of users - and I think has a cleaner codebase and is easier to config then sendmail.
In the default case, what's to config?
It's only in the non-default case that things get interesting.
A unified configuration utility is only a problem if the choices offer different and conflicting features. Otherwise you just write a common front end and MTA-specific back ends to edit the files. So first come up with a front end design that enumerates all the features you want to control.
On 10/30/2004 02:17:54 PM, Kenneth Porter wrote:
--On Saturday, October 30, 2004 7:20 PM +0000 "Michael A. Peters" mpeters@mac.com wrote:
postfix should be the default mta in a chroot jail. It satisfies the needs of the vast majority of users - and I think has a cleaner codebase and is easier to config then sendmail.
In the default case, what's to config?
Even in the default case postfix is better. You can run it more securely in a chroot jail than you can sendmail, and it's security record isn't nearly as blemished as sendmail.
And for cases where you do need to change default configuration, for the vast majority of them postfix is both easier to configure and more secure.
But Fedora won't change to postfix because of management people of the kind you see in Dilbert who insist upon sendmail in RHEL and if they aren't going to switch to postfix in RHEL then they won't switch to postfix in Fedora.
The Fedora merger I had hoped would shoot for desktop market - but instead it shoots for a testing platform for RHEL. This is probably also why they royally screwed up the benefits of rpm by now WITHOUT WARNING allowing files from one rpm to replace files of another.
I hate this kind of smurf. It is the wrong thing to do. Oh well.
/rant
On Sat, 2004-10-30 at 21:07, Michael A. Peters wrote:
[snip]
Even in the default case postfix is better. You can run it more securely in a chroot jail than you can sendmail, and it's security record isn't nearly as blemished as sendmail.
That blemished past is pretty far in the past. The number of security holes per year has dramatically decreased in recent years. Note that it used to be measured in holes/week, but take a look at www.sendmail.org and you'll see that the last hole was over a year ago. So it's a matter of preference, really. But I'm hoping this doesn't turn into an all-out 'my-MTA-is-better-than-yours' religious war. Please let's endeavor to not let that happen. But in the default case, your argument doesn't hold much water. I don't know if it's possible to run sendmail in a chroot jail, but given that it only listens to localhost by default, it's not that big a deal. Those who enable it to listen on the public interface should know what they are doing, and that goes for *any* deamon listening on a public interface.
And for cases where you do need to change default configuration, for the vast majority of them postfix is both easier to configure and more secure.
Easier is a relative term. Depends on what you are used to. Certainly, its easier for the average joe, agreed.
But Fedora won't change to postfix because of management people of the kind you see in Dilbert who insist upon sendmail in RHEL and if they aren't going to switch to postfix in RHEL then they won't switch to postfix in Fedora.
Man, oh, man. When we will people stop with these silly conspiracy theories? Find me one PHB who even knows what sendmail and postfix *are*.
The Fedora merger I had hoped would shoot for desktop market - but instead it shoots for a testing platform for RHEL.
Well, you're entitled to hope, but Fedora was *never* targeted at the desktop market. Or any *market*, so to speak:
Purpose: Server/Desktop/Workstation User: Enterprise/Home/Hobbyist-Enthusiast-Developer
The above two classifications are orthogonal. Combine any one from the first list with any one from the second list. Fedora is aimed at the Hobbyist-Enthusiast-Developer. That does not preclude Server, Desktop, or Workstation, but your mileage may vary. It's pretty much implied in the stated goals of Fedora that it is where new things get tried out before being included in RHEL. Red Hat tries not break things horribly. And I've think it's done a pretty good job. Except, see below.
This is probably also why they royally screwed up the benefits of rpm by now WITHOUT WARNING allowing files from one rpm to replace files of another.
Though I don't think it is why it's screwed up the benefits of rpm, I do agree that the recent fileconflicts handling (or non-handling) is a major boo-boo, and hope that the change is backed out before release of FC3. It's bad, real bad.
Le samedi 30 octobre 2004 à 21:28 -0400, Paul Iadonisi a écrit :
On Sat, 2004-10-30 at 21:07, Michael A. Peters wrote:
[snip]
Even in the default case postfix is better. You can run it more securely in a chroot jail than you can sendmail, and it's security record isn't nearly as blemished as sendmail.
That blemished past is pretty far in the past. The number of security holes per year has dramatically decreased in recent years. Note that it used to be measured in holes/week, but take a look at www.sendmail.org and you'll see that the last hole was over a year ago. So it's a matter of preference, really. But I'm hoping this doesn't turn into an all-out 'my-MTA-is-better-than-yours' religious war. Please let's endeavor to not let that happen.
Even if the sendmail codebase finaly reached the quality of its competitors that's no reason to inflict sendmail conf files on users.
Regards,
On Sun, 2004-10-31 at 04:23, Nicolas Mailhot wrote:
[snip]
Even if the sendmail codebase finaly reached the quality of its competitors that's no reason to inflict sendmail conf files on users.
Heh.
I eat sendmail rulesets for breakfast. ;-)
Never saw anyone use 'inflict' when talking about sendmail conf files. But I guess that's appropos. The best description I've heard of them is that they look like line noise.
Oh, and 'quality' may be overstating it a bit. I've seen core sendmail developers mention things like sendmail being full of hacks (that's ugly hacks, not cool hacks). SendmailX is rewritten from the ground up, with lessons learned in mind. We'll have to wait and see how well that takes off.
Paul Iadonisi wrote:
On Sun, 2004-10-31 at 04:23, Nicolas Mailhot wrote:
[snip]
Even if the sendmail codebase finaly reached the quality of its competitors that's no reason to inflict sendmail conf files on users.
Heh.
I eat sendmail rulesets for breakfast. ;-)
Never saw anyone use 'inflict' when talking about sendmail conf files. But I guess that's appropos. The best description I've heard of them is that they look like line noise.
Now for the stupid question of the day: Why wasn't the config files changed to something decent? Why is it still using cryptic m4 macros to create even more cryptic configs?
Oh, and 'quality' may be overstating it a bit. I've seen core sendmail developers mention things like sendmail being full of hacks (that's ugly hacks, not cool hacks). SendmailX is rewritten from the ground up, with lessons learned in mind. We'll have to wait and see how well that takes off.
The ugly rumor that I heard is that parts of the codebase are too messy for an audit. It passed the point of "rewrite is less work than fixing" a long time ago. Anyone tried commercial sendmail? Is it different?
On Sun, 2004-10-31 at 10:50, Z wrote:
[snip]
Now for the stupid question of the day: Why wasn't the config files changed to something decent? Why is it still using cryptic m4 macros to create even more cryptic configs?
Um, actually, what makes you say that the m4 macros are cryptic? Now, m4 itself is *extremely* difficult to read and debug if you are writing your own FEATURES, HACKS, or proto.m4 changes, but that's another matter. The whole purpose of using m4, however, is to make life easier...and it certainly does, as features now have meaningful names, instead of stuff like R*&$&^!( And if you *can* do everything with m4 macros (you can't, but almost can), then who really cares what the .cf file looks like? It's no different than compiling a source program getting a binary result. Yes, many would argue that the output looks the same (heh), but if you stick modifying the m4 file, it shouldn't really matter. That said, I believe one of the significant changes in SendmailX is the new config file format. From what I've seen, it looks *much* more readable. I don't know about actual rewriting rulesets, however. I think the changes are aimed more at the everything but the rulesets (map definitions, options, milter definitions, etc.). Given what the rulesets actually do, it's hard to imagine a better way to do it and still maintain the current flexibility. But I could be wrong...that may be changed, too. I have a copy of smX-0.0.16, so I'll take a look.
[snip]
Anyone tried commercial sendmail? Is it different?
A few years ago, yes, I did. But the codebase is the same, with a few features added strictly for administration, plus the web gui. Nothing to write home about, IMHO.
Paul Iadonisi wrote:
On Sun, 2004-10-31 at 10:50, Z wrote:
[snip]
Now for the stupid question of the day: Why wasn't the config files changed to something decent? Why is it still using cryptic m4 macros to create even more cryptic configs?
Um, actually, what makes you say that the m4 macros are cryptic? Now,
Well, stuff like "define(`confAUTH_OPTIONS', `A p y')dnl" is not exactly self-describing...
m4 itself is *extremely* difficult to read and debug if you are writing your own FEATURES, HACKS, or proto.m4 changes, but that's another matter. The whole purpose of using m4, however, is to make life easier...and it certainly does, as features now have meaningful names, instead of stuff like R*&$&^!( And if you *can* do everything with m4 macros (you can't, but almost can), then who really cares what the .cf file looks like? It's no different than compiling a source program getting a binary result. Yes, many would argue that the output looks the same (heh), but if you stick modifying the m4 file, it shouldn't really matter.
The problem is that I don't believe tha every possible combination of macros has been validated. If things don't work as you expect, you'll have to see if the generated .cf indeed looks like what you tried to accomplish. At that point, you're screwed.
That said, I believe one of the significant changes in SendmailX is the new config file format. From what I've seen, it looks *much* more readable. I don't know about actual rewriting rulesets, however. I think the changes are aimed more at the everything but the rulesets (map definitions, options, milter definitions, etc.). Given what the rulesets actually do, it's hard to imagine a better way to do it and still maintain the current flexibility. But I could be wrong...that may be changed, too. I have a copy of smX-0.0.16, so I'll take a look.
[snip]
Anyone tried commercial sendmail? Is it different?
A few years ago, yes, I did. But the codebase is the same, with a few features added strictly for administration, plus the web gui. Nothing to write home about, IMHO.
Thanks for the info. Spared me some work.
Z
devel@lists.stg.fedoraproject.org
-
Alexander Dalloz -
John Mizell -
John Mizell -
Kenneth Porter -
Michael A. Peters -
Nicolas Mailhot -
Paul Iadonisi -
Tom Diehl -
Z