Thomas M Steenholdt (tmus(a)tmus.dk) said: > I noticed that Exim is being installed as the default MTA, at least on > the Desktop installation of Fedora 7 test1. Is this change intentional? Not exactly. It's how the dependencies got fulfilled.

Sounds like one of the packages has a bad/missing Requires then, or the soname was bumped but passwd wasn't rebuilt, or something like that.

No its better because you like it more. I think you have been pushing for this since at least 1999 (2000 for sure). Me I would like postfix :)

Me I would like postfix :)

Of course I have a sendmail centric installation, and someone out there probably has a distro wide CVS search for dependencies. Besides, this simple search may be yeild a few false positives. Regardless, upstream packages should get more generic on their MTA of choice. But this proves to me the importance of sendmail of the other MTAs.

strings for 'postfix'

gcalctool-5.8.25-1.fc6

b) and all reasonable MTAs support /usr/sbin/sendmail -- what does it have to do with choice of particular package for Fedora?

On 2/3/07, David Woodhouse <dwmw2(a)infradead.org&gt; wrote: > Not exactly. It's how the dependencies got fulfilled. > > It's probably a good thing though -- it _is_ a better choice because > it's much easier to deal with and much more versatile than the other > options; _especially_ than sendmail :) > No its better because you like it more. I think you have been pushing for this since at least 1999 (2000 for sure). Me I would like postfix :)

Thomas M Steenholdt (tmus(a)tmus.dk) said: > I noticed that Exim is being installed as the default MTA, at least on > the Desktop installation of Fedora 7 test1. Is this change intentional? Not exactly. It's how the dependencies got fulfilled. Bill

> I just checked the contents of the DVD image, and the only MTA I can > find there is Exim. I guess that's the real reason. > > /Thomas No, this is not the real reason. "exim" is even preferred when both "Core" and "Extras" repositories are enabled while a program requiring "/usr/sin/sendmail" is scheduled for install. For instance, this can happen after a minimum install. In ordinary cases [e.g. desktop install], "sendmail" gets picked up during system install since it is listed in "comps.xml".

On Sun, 2007-02-04 at 11:37 +0100, Thomas M Steenholdt wrote: > Still - Only Exim is available on the DVD. That's _because_ it was automatically chosen to satisfy the /usr/sbin/sendmail dependency. Pungi did that, at about the same time it decided _not_ to include the 64-bit libuser package to satisfy the libuser.so.1()(64bit) dependency in /usr/bin/passwd :)

On Sat, 2007-02-03 at 22:59 +0100, Thomas M Steenholdt wrote: > "If we change the Default MTA in Fedora - Which should it be?" > > I'm sure a lot of people will say Exim is great (i can't say, since i've > never worked with it). Others will yell for Postfix, towards which i'm > probably slightly biased, since that's what I currently use in most > places. I'm sure yet others will have other MTA's listed as their > favorite one. Exim certainly does the job for me. None of the others do, as far as I can tell. I'd be happy to be corrected on that count though, so I'll elucidate... I'd like to be able to do greylisting -- but not indiscriminately; I want to greylist only mail which actually looks suspicious in some way, rather than delaying perfectly genuine mail. Mail gets greylisted only if it has some SpamAssassin points, or it's HTML, or it comes from a machine with no reverse DNS or which is listed in a RBL, etc.

That's a few lines of Exim ACL code, demonstrated (the quick hack version) at http://david.woodhou.se/eximconf/include/acl-greylist or perhaps more sanely with jgarzik's better SQLite-based version which is available in the same directory although I haven't yet switched over to it.

Is it possible to do that kind of thing in other MTAs? Without writing or installing external software (or, perhaps, calling out to Exim? :)

I also need to be able to run virtual domains on the cluster of mail machines I operate, but I don't really want to set up yet another distributed database; I _already_ have DNS running, after all. I keep aliases for virtual domains in TXT records,

and I use Dynamic DNS so that owners of a given virtual domain can update their forwarding records with a trivial script round nsupdate. Currently, that's handled just a few lines of Exim router configuration in the same directory as the above (routers-dns-virtual). Can I do this in any of the other MTAs on offer?

Even Postfix would also be a better choice than sendmail -- that isn't exactly a hard accolade to achieve. But it's much less versatile than Exim and much less flexible in handling and filtering of incoming mail. It might serve the newbies OK and those who really don't ask much of it, but it's less useful for anyone who actually wants to get _serious_ about running a spam-resistant mail server these days.

I do not want mail that SA has classified as almost certainly not spam to be greylisted. But then I'd like to greylist everything that is not blocked, but that is still suspicius (I.E. a score lower than N, but higher than M). But I geuss this is best solved by talking to the developers of one of the greylist-milters, to make them add a feature to whitelist email based on a custom header. (For instance "X-Spam-Level: ***")

> Although it's useful to give examples of how to do such things, it's > also important not to make the _default_ configuration too baroque. > Debian gets this very wrong, which is why I've been slightly reluctant > to include more than the basics in the Fedora package. But these days I > suspect that greylisting _is_ counted amongst the basic requirements of > a public-facing mail server so I think I'll have to include it. Including this, but having it commented out sounds very good. > Would you (or anyone else, for that matter) be interested in being a > guinea pig to help me assess how easy it is for newbies to Exim to use > such a thing if I add it? I am ;-) I still run sendmail, but exim has been on my wishlist for a very long time now.

The point in greylisting is very simple: it's to check that the mail is coming from a 'proper' mail server which actually does retry mail when you give a temporary rejection. Some people naïvely delay all incoming mail (and some outgoing mail too, if they reject at RCPT TO and the recipient uses callouts) by greylisting indiscriminately. I prefer mail to be fast in the common case, so I like to delay _only_ mail which actually looks suspicious in some way, and I prefer _never_ to greylist mail from a host (IP address) which was already observed to retry in the past.

>>>> "NP" == Nils Philippsen <nphilipp(a)redhat.com&gt; writes:

The IP I send this from is static. It is also supposedly a "known" dynamic IP. I would agree with you if the dynamic IP lists were actually dynamic IP lists.

On Sun, 2007-02-04 at 22:21 -0300, Horst H. von Brand wrote: > > Exim certainly does the job for me. None of the others do, as far as I > > can tell. I'd be happy to be corrected on that count though, so I'll > > elucidate... I note you make no pretence at claiming Postfix can do these things; only arguments that I shouldn't _want_ to. This despite the fact that they're only _examples_ of the kind of thing people do with mail servers, and the fact that these are the reasons people come to me and _ask_ for an account on my systems. But despite the fact that it's a complete digression and you seem to have already conceded the point I was making, it's a subject which interests me so I'll play along... > > I'd like to be able to do greylisting -- but not indiscriminately; I > > want to greylist only mail which actually looks suspicious in some way, > > rather than delaying perfectly genuine mail. Mail gets greylisted only > > if it has some SpamAssassin points, or it's HTML, or it comes from a > > machine with no reverse DNS or which is listed in a RBL, etc. > > The /point/ in greylisting is not to expend any effort on mail that comes > from suspect origins. Resources are cheap, right up to the point the mail is accepted and delivered to my mailbox. At _that_ point I start to resent it. The point in greylisting is very simple: it's to check that the mail is coming from a 'proper' mail server which actually does retry mail when you give a temporary rejection. Some people naïvely delay all incoming mail (and some outgoing mail too, if they reject at RCPT TO and the recipient uses callouts) by greylisting indiscriminately. I prefer mail to be fast in the common case, so I like to delay _only_ mail which actually looks suspicious in some way, and I prefer _never_ to greylist mail from a host (IP address) which was already observed to retry in the past. > Stopping mail from an RBLed origin or no reverse DNS > (or non-matching reverse DNS) are other, independent anti-spam > measures. Sure, they can be integrated into greylisting (milter-greylist > for sendmail integrates RBLs), but they are still independent. So is > spamassassin's score, etc. You may have been trained to treat them independently because that's all you're used to being able to do, but personally I don't want to be limited in that fashion. I _want_ to be able to combine SA score with other reasons for considering a mail 'suspicious', and use that as a trigger for stuff like greylisting. For someone else, I used a similar set of criteria to trigger Exim's 'fakereject' feature which allows one to give a 550 rejection but still actually accept the message. It was configured to 'freeze' the mail on the queue, and give a URL with the rejection message as well as an explanation. When the recipient of the bounce went to that URL they would get a far more coherent explanation of the offences which caused the mail to be 'rejected', and could complete a captcha to verify that the mail _is_ genuine and have it unfrozen for delivery. That's not something I would normally have done; I prefer just to bounce and let people fix their sending mail servers if they're broken enough to get rejected. But the client in this case was adamant that this was what they wanted, and it allows them to peruse the frozen spam on the queue for false positives. It's better than accepting it and putting it into a spam folder, because that way the recipient wouldn't get a bounce, so they might think their mail is actually going to be read. > > Is it possible to do that kind of thing in other MTAs? Without writing > > or installing external software (or, perhaps, calling out to Exim? :) > > Why is "installing external software" (specially if it is written to > standardized interfaces defined exactly for such uses) off-limits? I suppose it isn't off-limits if it's versatile enough to be tweaked to users' requirements and if it's shipped in Fedora. Standardised interfaces are fine, again as long as they're versatile enough. For a long time, Exim had SpamAssassin support (sa-exim) which used a similar interface -- running on the mail just after DATA and giving a decision about whether to accept it or not. That wasn't good enough for folks who were used to better things, and it was very quickly replaced with full content scanning support within the ACL language. We finally dropped sa-exim from the Fedora packages in FE6, after keeping it around for a long time for compatibility. http://fedora.redhat.com/docs/release-notes/fc6/en_US/sn-Extras.html#id29... > > I also need to be able to run virtual domains on the cluster of mail > > machines I operate, but I don't really want to set up yet another > > distributed database; I _already_ have DNS running, after all. I keep > > aliases for virtual domains in TXT records, > > Lousy missuse of DNS, if you ask me. DNS is a distributed database which automatically synchronises between all the machines in the cluster. It also allows me to give 'keys' to certain users in order that they can modify certain subdomains as they desire. It was already running; I didn't have to set up a new database. Yes, it's 'abuse of DNS'. It's also _extremely_ convenient. If I want bondage and discipline I'll go back to programming in Modula-3. > > and I use Dynamic DNS so > > that owners of a given virtual domain can update their forwarding > > records with a trivial script round nsupdate. Currently, that's handled > > just a few lines of Exim router configuration in the same directory as > > the above (routers-dns-virtual). Can I do this in any of the other MTAs > > on offer? > > Why does an MTA have to bend over to such abuse of DNS? An MTA should be flexible enough that the admin can do what he/she need to do with with it. Because of the way SMTP works, especially the need to avoid sending bounces _after_ accepting mail, stuff _does_ need to be pushed down into the MTA to be done at SMTP time. And in the current environment, you have to get more and more involved to stay ahead of the game. I've just highlighted a few of the things I do with it; that's all. It wasn't an exhaustive list; just a glimpse of how Exim makes the mail system work much better for _me_ (and my users) than any other MTA could manage. OK, so returning to the original topic... now I've got two kinds of responses. First the "oh, I think I'll switch to Exim" and now the somewhat more disingenuous "you shouldn't want to do that anyway" :) -- dwmw2

> Are we really changing the default MTA just because of a cock-up in > resolving dependencies? No. We change it because sendmail sucks and needs to die.

On 5 Feb 2007, at 18:58, Jesse Keating wrote: > If somebody packages up the 'aa' package that provides smtpdaemon and > plays with alternatives right, 'aa' would win, again because of the > sort.

I came -><- this close to adding a wishlist item to the Exim bugzilla to change its name to 'a' (or do numerics sort earlier?) Fun fun fun...

I'm not going to debate which mailer is best, but I have to say this... Knowing that exim will win a dependency race for for /usr/sbin/sendmail, including the package on the media and installing it by default (even if it's to satisfy a dep.), comes very very close to being a conscious decision.

Precisely. So let's make sure that whatever is put on the media, is something that we can somehow justify as our default packages for whatever. I don't care about which mailer is chosen as default, but I'm not too fond of the: "package XXX is the default choice for function YYY, because it won the *sort* contest". If we are going to include an MTA on the media at all - and install should of course be possible without network connectivity - we should be in charge of which mailer goes there. It should not be left to chance.

sense to me. Is there a candidate for this perhaps?!?

On Tuesday 06 February 2007 15:48, Thomas M Steenholdt wrote: > Precisely. So let's make sure that whatever is put on the media, is > something that we can somehow justify as our default packages for > whatever. I don't care about which mailer is chosen as default, but I'm > not too fond of the: "package XXX is the default choice for function > YYY, because it won the *sort* contest". If we are going to include an > MTA on the media at all - and install should of course be possible > without network connectivity - we should be in charge of which mailer > goes there. It should not be left to chance.

I really really don't want to make that decision, because no matter _what_ decision I make, people with pitchforks are going to come after me. So I'm perfectly happy to make _no_ decision and let the tool sort it out.

I can only imagine the reactions if/when somebody submits some niche MTA into the repository mid-release that happens to get selected over exim.

> No. > We change it because sendmail sucks and needs to die. Says who?

In all the discussions I have witnessed and participated in on this particular subject (on this list and elsewhere) there has never been a significant group wanting to keep sendmail.

On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: > That's because people get flamed to a crisp when they even suggest > sendmail. I still use it on almost all of my servers. sendmail can do things no other MTA can. Period. 99.44% of people do not need those things, but the remainder _really_ needs them.

Surely the default should be not to include an MTA, I'm guessing a large majority of people never one it anyway (myself included).

How many "Desktop" users configure logwatch, fetchmail or mdadm? On the server spin sure, but on a Desktop?

*shrug* I can certainly see mdadm used on a desktop that uses local raid to store important data, like ogg files. Fetchmail is still unfortunately used a lot :/

These things need to be moved to dbus with an optionnal dbus-to-sendmail remoter sink

RAID isn't too common right now, but all the (higher-end) desktop machines I've bought lately have RAID controllers built in.

Yes, what's Really Needed (tm) is a very lightweight smtpdaemon designed to fill this need and nothing more.

On Tue, Feb 06, 2007 at 10:30:40AM -0500, Jesse Keating wrote: > > Surely the default should be not to include an MTA, I'm guessing a large > > majority of people never one it anyway (myself included). > That would require creating something to take the place of the smtpdaemon > requirement of things like mdadm, fetchmail, logwatch, etc... Yes, what's Really Needed (tm) is a very lightweight smtpdaemon designed to fill this need and nothing more.

On Tuesday 06 February 2007 4:02:21 pm Richard Hughes wrote: > Surely the default should be not to include an MTA, I'm guessing a large > majority of people never one it anyway (myself included). If my memory serves me correctly, an MTA is a requirement spelled out in RFC 1123. Having a Unix host without an MTA would surely be surprising, desktop use or not.

sendmail can do things no other MTA can. Period.

On Tue, 2007-02-06 at 10:05 -0500, Alan Cox wrote: > On Tue, Feb 06, 2007 at 09:15:37AM -0500, Matthew Miller wrote: > > sendmail can do things no other MTA can. Period. > > This is false. Sorry. There is nothing sendmail can do that exim > cannot as both are (within the limits of memory) turing complete. Well, Exim's ACLs aren't _quite_ Turing-complete because it limits recursion to about 20 calls iirc. But that doesn't stop silly people

On Tue, Feb 06, 2007 at 10:05:00AM -0500, Alan Cox wrote: > > sendmail can do things no other MTA can. Period. > This is false. Sorry. There is nothing sendmail can do that exim cannot as > both are (within the limits of memory) turing complete. Well, sure, and we have the source and all. So add "without significant coding".

> This is false. Sorry. There is nothing sendmail can do that exim cannot as both > are (within the limits of memory) turing complete. milter?

sendmail has milter - exim does not (at least as shipped by Fedora AFAICT). No amount of configuration language is going to change that (unless exim's config language allows you to open TCP sockets and talk the milter protocol). Also, exim does not provide the libmilter client library.

On Tue, Feb 06, 2007 at 06:22:37PM +0000, David Woodhouse wrote: > > > This is false. Sorry. There is nothing sendmail can do that exim cannot as both > > > are (within the limits of memory) turing complete. > > milter? > Which one? Any arbitrary existing one. That's the point.

Not for the desktop MTA, certainly.

Nor for the default MTA either (although as noted, I think exim is overkill there too).

By the way, does anyone know, which MTA will be the default for RHEL 5?

I think it will be sendmail. Path of least surprise. Much harder to make any sort of change like that in RHEL :/

>>>>> "MM" == Matthew Miller <mattdm(a)mattdm.org&gt; writes: MM> On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: >> That's because people get flamed to a crisp when they even suggest >> sendmail. I still use it on almost all of my servers. MM> sendmail can do things no other MTA can. Period. MM> 99.44% of people do not need those things, but the remainder MM> _really_ needs them. Is there really anything useful left which exim can't do? UUCP bang paths are the only limitation I can think of off the cuff, and hopefully noone uses those. Exim can do UUCP with domain addressing though, if anyone still uses UUCP.

On Tue, 2007-02-06 at 18:51 +0000, Peter Robinson wrote: > > >>>>> "MM" == Matthew Miller <mattdm(a)mattdm.org&gt; writes: > > > > MM> On Mon, Feb 05, 2007 at 09:04:58PM -0600, Chris Adams wrote: > > >> That's because people get flamed to a crisp when they even suggest > > >> sendmail. I still use it on almost all of my servers. > > > > MM> sendmail can do things no other MTA can. Period. > > > > MM> 99.44% of people do not need those things, but the remainder > > MM> _really_ needs them. > > > > Is there really anything useful left which exim can't do? UUCP bang > > paths are the only limitation I can think of off the cuff, and > > hopefully noone uses those. Exim can do UUCP with domain addressing > > though, if anyone still uses UUCP. > > Yes, I have a few sites that require it.... but then I also know how > to 'yum install sendmail' too, as I'm sure just about everyone who > uses UUCP does, or else compiles sendmail themsleves. This would put me in the "just not about everyone" group as I use postfix and UUCP. It was really easy to setup, but I might have to try out something different for more effective anti-spam stuff.

On Wed, 2007-02-07 at 09:36 -0500, Jarod Wilson wrote: > As for the performance issue someone else quoted regarding exim... At one > point in time, I worked at a place that had lots of mail servers moving > tens of millions of emails per day. There was no way in hell exim could > handle the load (we tried). Both sendmail and qmail (ew) had their issues > as well. Postfix was rock-solid, and had no problems holding up under the > stress. Granted, this is a few years ago now, so postfix could have > regressed (unlikely) and the others (save qmail) could have improved... I've heard anecdotes the other way round too, and there are some very large deployments of Exim. I suspect that it depends a lot on how well-tuned it is. With large queues, you definitely need the 'split_spool_directory' option turned on to avoid putting too many files in a single directory -- it's going to suck quite hard otherwise; especially on older kernels. You may also want multiple queue-runner processes in parallel, if you have a large number of mails stuck on the queue that aren't immediately deliverable.

Notice that Exim CAN do UUCP, just not UUCP bang paths. That is, the old foo!bar!baz stuff.

sendmail can do things no other MTA can. Period. 99.44% of people do not need those things, but the remainder _really_ needs them.

> 0.56% of people need Towers of Hanoi? (don't mind me, just passing > through...)

Alan is the one who brought that up, and IIRC in relation to exim, not sendmail.

Once upon a time, Ralf Ertzinger <fedora(a)camperquake.de&gt; said: > In all the discussions I have witnessed and participated in on this > particular subject (on this list and elsewhere) there has never > been a significant group wanting to keep sendmail.

That's because people get flamed to a crisp when they even suggest sendmail. I still use it on almost all of my servers.

>>>> "DW" == David Woodhouse <dwmw2(a)infradead.org&gt; writes:

"The bottom line is that Exim does not perform particularly well in environments where the queue regularly gets very large. It was never designed for this; deliveries from the queue were always intended to be 'exceptions' rather than the norm."

Hi. On Wed, 7 Feb 2007 06:46:41 +0000 (UTC), Bojan Smojver wrote: > "The bottom line is that Exim does not perform particularly well in > environments where the queue regularly gets very large. It was never > designed for this; deliveries from the queue were always intended to > be 'exceptions' rather than the norm." Depends on what you call 'large'. 10000 mails in the queue are not really a problem.

I have a machine here (FallbackMX for our mailing list handler, will probably do the same duty for our regular mailservers soon) where the queue is normally around 2000 messages, with highs in the low 4000s.

Any comment regarding the SUID stuff?

I noticed that Exim is being installed as the default MTA, at least on the Desktop installation of Fedora 7 test1. Is this change intentional? I can't seem to find it mentioned anywhere?!? Thanks in advance /Thomas

Shortest name, not alphabetical.

All of these virtually provide /usr/bin/whizbang and use alternatives to handle this.

One possibility would be to prompt the user, once alternative package choices appear and to let him pick one of them.

Think "expect"?

No need to get sarcastic. I mentioned "expect" only as an example, and it's not even required: already now, the -interactive- user input during an "anaconda" install procedure is processed in order to produce a valid kickstart file for later use. I do not see any fundamental difference in this respect. If packages can be selected by the user at will at install time, why not prompt him in case of anbiguities when the dependencies get processed? Once the final package selection has been established, it can be retained for the kickstart file, and for later automated installs, this question does not even need to be asked again, ... right?

On Saturday 03 February 2007 15:12, Joachim Frieben wrote: > The bug got closed by J. Katz after classification as "NOTABUG". The > argument was that the "sendmail" command is provided by several packages in > "FC/FE" without particular ranking and "exim" simply seems to win by > alphabetical order compared to "postfix" or "sendmail" .. :-/ Do you have any other suggestions on how to programattically decide what choice out of many options you'd use to satisfy a dep? fooz barz billy go All of these virtually provide /usr/bin/whizbang and use alternatives to handle this. bingo requires /usr/bin/whizbang, and doesn't care which one. What way to you decide which to grab? Currently yum does a sort of all that provide /usr/bin/whizbang and picks the one at the top. Shorter names sort before longer ones, so in this case, 'go' wins.

Abort transaction when it is ambiguous (kickstart)

Such a behavior is just a maintainance nightmare. 'kickstart' is used to build systems in a reproducible way. Having a clear semantic ("transactions must be always unambigous") would help to avoid bad surprises.

> > If you reproducably want sendmail then tell kickstart so instead of > relying on side effects. Exactly. That's why, kickstart should abort on ambigous transactions.

Hi. On Sat, 03 Feb 2007 22:28:13 +0100, Enrico Scholz wrote > Abort transaction when it is ambiguous (kickstart) Err, no. If a dependency can be satisfied in various ways then anaconda is free to choose any one of the possibilities at it's discretion in my book. If I want a certain package then I as the admin can put it into the kickstart file.

What in a desktop install could possibly require an MTA.. it seems a bit daft to me. - David

That's a packaging bug. 'mutt' requires a program with a sendmail compatible CLI, but not an MTA.

What in a desktop install could possibly require an MTA.. it seems a bit daft to me.

> fetchmail.  Some desktops do read email. Desktops use a GUI mail client, though.

fetchmail. Some desktops do read email.

lør, 03 02 2007 kl. 16:47 +0100, skrev Thomas M Steenholdt: > I noticed that Exim is being installed as the default MTA, at least on > the Desktop installation of Fedora 7 test1. Is this change intentional? > I can't seem to find it mentioned anywhere?!? > What in a desktop install could possibly require an MTA.. it seems a bit daft to me.