Slashdot Mirror

It is. There are many tools out there that implement it. It's the whole reason that we use CAs -- not that they're an ideal solution to the problem, but without some way to verify the authenticity of the public key you're using to bootstrap the key exchange, any PK-based key agreement protocol is subject to MITM attacks.

MITM can be an issue. More detailed information about the state of things at the link below.

https://wiki.exim.org/lurker/m...

Exim MTA - http://exim.org/ - may still be the default sendmail-replacement in quite a few ditros.

http://www.exim.org/lurker/message/20101210.071922.233697ac.en.html

"Paul Fisher and I have successfully run the exploit against a copy of
Exim running in a debugger on debian lenny, and we believe it utilizes
this bug:

http://bugs.exim.org/show_bug.cgi?id=787

It was fixed in 4.70, but not in the version currently in debian
stable.

James E. Blair
UC Berkeley"

http://www.exim.org/lurker/message/20101210.071922.233697ac.en.html

"Paul Fisher and I have successfully run the exploit against a copy of
Exim running in a debugger on debian lenny, and we believe it utilizes
this bug:

http://bugs.exim.org/show_bug.cgi?id=787

It was fixed in 4.70, but not in the version currently in debian
stable.

James E. Blair
UC Berkeley"

This isn't FUD. http://www.exim.org/lurker/message/20101209.150448.ee9f5ce6.en.html

It's been, umm, a very long time since I've been to confession.

It's true, I don't use SPF. I've at least got the TXT line in my DNS hosts file.

But I'm using exim, which only has experimental support, and I'm too afraid to use something experimental like that.

What should I do, server?

It's been, umm, a very long time since I've been to confession.

It's true, I don't use SPF. I've at least got the TXT line in my DNS hosts file.

But I'm using exim, which only has experimental support, and I'm too afraid to use something experimental like that.

What should I do, server?

Can you give examples of good Exchange replacements?

Yes, for that see DVL. Seriously, though you have to define what activities you need to do before you can ask for a replacement. MS Exchange is marketed in many niches and fails (on the surface) in most. The most spectacular is its failure as a mail server replacement, if you look at it as such. If you look at the wonderful cover of plausible deniability it gives executives by randomly losing and delaying mail, then that is a success.

Anyway, try looking these. Keep in mind that, unlike with M$ products, you can combine pieces of several packages.

• Kolab — http://www.kolab.org/
• Citadel — http://www.citadel.org/
• Dingo Calendar Server — http://andrew.triumf.ca/dingo/
• Darwin CalendarServer — http://trac.calendarserver.org/
• Bedework — http://www.bedework.org/
• Zimbra — http://www.zimbra.com/
• OpenGroupware — http://www.opengroupware.org/

If you are simply looking to improve reliability of e-mail they a plain Mail Transfer Agent (MTA) will do. Before it became too embarrassing for M$, it used to be recommended practice to put one of these in front of MS Exchange to improve reliability and security. Also look up ClamAV, Spamassassin and how to do greylisting.

• simta — http://rsug.itd.umich.edu/software/simta/
• Dovecot — http://www.dovecot.org/
• Postfix — http://www.postfix.org/
• Exim — http://www.exim.org/
• Sendmail — http://www.sendmail.org/
• qmail — http://www.qmail.org/

However, before you can think about "replacing" MS Exchange, you will have to get rid of the staff that selected and deployed it in the first place. They ignored all the licensing shortcomings, the bad reviews, high price and ongoing technical failure to instead push ideology over technology. People making decisions based on ideology are not going to accept any technical or economic arguments...

Can you give examples of good Exchange replacements?

Yes, for that see DVL. Seriously, though you have to define what activities you need to do before you can ask for a replacement. MS Exchange is marketed in many niches and fails (on the surface) in most. The most spectacular is its failure as a mail server replacement, if you look at it as such. If you look at the wonderful cover of plausible deniability it gives executives by randomly losing and delaying mail, then that is a success.

Anyway, try looking these. Keep in mind that, unlike with M$ products, you can combine pieces of several packages.

• Kolab — http://www.kolab.org/
• Citadel — http://www.citadel.org/
• Dingo Calendar Server — http://andrew.triumf.ca/dingo/
• Darwin CalendarServer — http://trac.calendarserver.org/
• Bedework — http://www.bedework.org/
• Zimbra — http://www.zimbra.com/
• OpenGroupware — http://www.opengroupware.org/

If you are simply looking to improve reliability of e-mail they a plain Mail Transfer Agent (MTA) will do. Before it became too embarrassing for M$, it used to be recommended practice to put one of these in front of MS Exchange to improve reliability and security. Also look up ClamAV, Spamassassin and how to do greylisting.

• simta — http://rsug.itd.umich.edu/software/simta/
• Dovecot — http://www.dovecot.org/
• Postfix — http://www.postfix.org/
• Exim — http://www.exim.org/
• Sendmail — http://www.sendmail.org/
• qmail — http://www.qmail.org/

However, before you can think about "replacing" MS Exchange, you will have to get rid of the staff that selected and deployed it in the first place. They ignored all the licensing shortcomings, the bad reviews, high price and ongoing technical failure to instead push ideology over technology. People making decisions based on ideology are not going to accept any technical or economic arguments...

The problem is, of course, that UK Gov seems to think that everyone uses an ISP's mail server. And it is true that many (most) ordinary netizens do. However, many companies run their own smtp servers and configuring an encrypted SMTP server is very easy (exim is a wonderful thing) - I have done it for years. One of the features of this is that the actual smtp conversation is encrypted - the senders and recipients are not visible. Given that my MXs are not any ISP, how is GCHQ going to monitor my email senders/recipients - even with fancy deep packet inspection?

They already do. I've done support for W.A. schools that were having problems with their internal Exchange server. They were shocked when we discussed the 'real' price for Exchange. They paid less than $1000 for it including CALs and hardware. MS has some serious sweetheart deals for schools and I bet if it came down to providing even cheaper Windows and Office for schools they will do it.

That's not the real price, though. The real price also includes all the down time, extra re-builds, malware tools, etc. Add to that also the cost of missing incoming messages, missing outgoing messages and delayed messages -- these last add up to more work for the users, which can number in the 100's, rather than just the maintenance staff which can usually be counted on one hand.

Before MS Exchange was hammered through the back door, e-mail was both so fast and reliable that many used it in ways resembling instant messaging.

Worth a look:
Roundcube: http://roundcube.net/
Kolab: http://www.kolab.org/
Citadel: http://www.citadel.org/
Zimbra: http://www.zimbra.com/

If you need a plain vanilla mail transfer agent instead of all the non-essentials, then postfix, exim, qmail, the new sendmail, and simta each have their niche. They're used pretty much everywhere, even if you don't always see the evidence of them outside the message headers.

The whole IT dept at this uni who chose windows live mail (why, for god's sake? WHY???) should be boiled. Very, very, slowly. Then shot, dissected and paraded around the grounds as an example. Then really hurt

The idiots

What you have to do is migrate in a series of stages. First you configure your desktop Outlook clients to listen to a POP3 server. Then you set up a new mail server with something like exim and qpopper. Then you reconfigure Outlook to send via SMTP. Then you turn off the Exchange server altogether. Then you migrate your desktops from Outlook on Windows to Thunderbird on Windows. Then to Thunderbird on GNU/Linux.

Corporate internal web application developers will simply have to learn to cope with non-IE browsers. That will happen when there's a demand for it (which will be soon; Microsoft can't fool everyone forever). Firefox is particularly good to test against, as it runs on both Windows and GNU/Linux.

Of course there is a replacement for Outlook and Exchange! It's called sendmail and it's part of every unix-like system. You install an MTA (either the original sendmail or a compatible replacement) and a POP3 server on a machine (an old desktop is fine), configure your firewall to route incoming traffic on port 25 to that machine, log into your DNS control panel, and set its internet hostname as the MX for your domain. Then you run a normal mail client on each desktop. Specify your mail server's inside IP address as the SMTP and POP3 server in your mail client, and away you go.

Dude! Nobody likes Sendmail. That's why they use things like Exim or Postfix. Getting a legit version of Advanced Server 2003 is serious overkill if you just need a mail server.

The way to tell is to measure how long it takes for the sysadmin to a) notice that it runs sendmail and b) changes it for something else. Personally I use exim, but just about anything is better than sendmail.

Having said that: I would not touch qmail with a bargepole either.

In that the mediocre admins will bodge some hacks into sendmail.cf to make sendmail appear to perform the job they need it to, whilst the best admins will take the presence of sendmail.cf as an indication that they need to remove sendmail and replace it with something that's actually fit for purpose? :-P

The simplest solution in this case is to specify 127.0.0.1 for your SMTP server, and run your own sendmail {or a sendmail replacement such as exim}. You can then switch the MTA configuration whenever you switch connections, as easily as recreating a symlink. NB. Don't forget to send a SIGHUP immediately after doing this, to force it to reread its configuration.

Exim can do this quite simply. I dare say that it is the most flexible mailer in existence (Sendmail might be as flexible, but it can't be done without a PHD in m4). Assuming you want to set up a relay server that mails to both the real server and a test server (I think that was the question), I would try the following.

In an Exim configuration file, you specify a list of routers that deliver the message. At a certain point, you'll usually either use a dnslookup router or some local delivery router to either forward a message to another host or deliver it locally respectively. In your case:

• use the standard dnslookup for remote delivery
• don't do any local delivery
• use the manualroute router to deliver to the main host, set the generic router option unseen=yes
• use another manualroute router to deliver to the test host

The unseen option (detailed here in chapter 15 of the specification) allows the first router to accept the message, but still pass it on to the next router.

I have used this method to do almost the exact thing you are doing here (although it was for logging purposes rather than testing). A word of warning... Your test server may generate bounce messages. Also, your relay server (the exim server in this case) may generate bounces if the test server refuses to accept messages. You can fix the latter by setting the errors_to option to the empty string on the test router (thus indicating bounces be dropped).

Removing the bounce address this way has the undesirable effect of causing the envelope sender on the test server to always be set to the bounce address () which makes it difficult to test things like sender verification.

It is possible to suppress relay bounces but preserve the sender address by saving the current sender in the address_data variable and reinstating it by setting the return_path to that in the transport that the router uses. This is ugly, but exists for this purpose (among others).

Then you only have to suppress bounces on the test server. This problem is inherent in delivering to two servers in parallel. If it is Exim, this is can be done with the errors_to option on your routers as above. This again defeats the purpose, because it is hardly a production configuration for testing purposes (can't test any bounce-related functionality). If the server is not Exim, you'll have to find some other way to suppress bounces.

Keep in mind, no matter what system you put in place for relaying, you will have to suppress bounces if you don't want to confuse your inbound mailers (often customers) with strange bounces on messages that were delivered, but generated a bounce on the test server.

Note that if you are really serious about testing your mail server and doing spamblocking, you'll probably do callouts. Callouts (a nice feature that Exim excels at) go through the initial delivery of a bounce message back to the sender address (but stops short of an actual delivery). This tests whether the return address can receive mail. In the event of common spam with AOL or Yahoo addresses, you stop accepting the address as soon as they close the account (or possibly never accept it if it is a faked account). Callouts are cached to a certain degree, so they are not a very bad performance hit either.

The reason I mention this is that it that effective features like this make it really difficult to block off bounces from your test server effectively. The only way I have been able to test something like this effectively is by moving the IT department (not the support desk though) mail onto a test server completely, bypassing any clever relaying. Make no mistake, a mail server in general, and a well spam-hardened server in particular, will be almost impossible to test effectively (without interfering with regular users) in parallel to your existing mail (i.e. duplic

Exim can do this quite simply. I dare say that it is the most flexible mailer in existence (Sendmail might be as flexible, but it can't be done without a PHD in m4). Assuming you want to set up a relay server that mails to both the real server and a test server (I think that was the question), I would try the following.

In an Exim configuration file, you specify a list of routers that deliver the message. At a certain point, you'll usually either use a dnslookup router or some local delivery router to either forward a message to another host or deliver it locally respectively. In your case:

• use the standard dnslookup for remote delivery
• don't do any local delivery
• use the manualroute router to deliver to the main host, set the generic router option unseen=yes
• use another manualroute router to deliver to the test host

The unseen option (detailed here in chapter 15 of the specification) allows the first router to accept the message, but still pass it on to the next router.

I have used this method to do almost the exact thing you are doing here (although it was for logging purposes rather than testing). A word of warning... Your test server may generate bounce messages. Also, your relay server (the exim server in this case) may generate bounces if the test server refuses to accept messages. You can fix the latter by setting the errors_to option to the empty string on the test router (thus indicating bounces be dropped).

Removing the bounce address this way has the undesirable effect of causing the envelope sender on the test server to always be set to the bounce address () which makes it difficult to test things like sender verification.

It is possible to suppress relay bounces but preserve the sender address by saving the current sender in the address_data variable and reinstating it by setting the return_path to that in the transport that the router uses. This is ugly, but exists for this purpose (among others).

Then you only have to suppress bounces on the test server. This problem is inherent in delivering to two servers in parallel. If it is Exim, this is can be done with the errors_to option on your routers as above. This again defeats the purpose, because it is hardly a production configuration for testing purposes (can't test any bounce-related functionality). If the server is not Exim, you'll have to find some other way to suppress bounces.

Keep in mind, no matter what system you put in place for relaying, you will have to suppress bounces if you don't want to confuse your inbound mailers (often customers) with strange bounces on messages that were delivered, but generated a bounce on the test server.

Note that if you are really serious about testing your mail server and doing spamblocking, you'll probably do callouts. Callouts (a nice feature that Exim excels at) go through the initial delivery of a bounce message back to the sender address (but stops short of an actual delivery). This tests whether the return address can receive mail. In the event of common spam with AOL or Yahoo addresses, you stop accepting the address as soon as they close the account (or possibly never accept it if it is a faked account). Callouts are cached to a certain degree, so they are not a very bad performance hit either.

The reason I mention this is that it that effective features like this make it really difficult to block off bounces from your test server effectively. The only way I have been able to test something like this effectively is by moving the IT department (not the support desk though) mail onto a test server completely, bypassing any clever relaying. Make no mistake, a mail server in general, and a well spam-hardened server in particular, will be almost impossible to test effectively (without interfering with regular users) in parallel to your existing mail (i.e. duplic

I just add a bit on that list from top of my head.
Although I think the listed app goes beyond what the so called 'average pc user' wants, but there goes...

1. Konqueror ( http://www.konqueror.org/ )

2. Email - Sylpheed ( http://sylpheed.good-day.net/ )

3. I think Evolution is more like in this place.

4. Lately "Sound Juicer" is taking more attention too

5. VideoLAN aka VLC ( http://www.videolan.org/ ) and Ogle ( http://www.dtek.chalmers.se/groups/dvd/ ) [and Goggles ( http://www.fifthplanet.net/goggles.html ) for Ogle GUI wrapper] for DVD watching.

6. There are plenty way to do this, but the typical ones could be 'Jinzora' ( http://www.jinzora.org/ ) and 'MusicPD' ( http://www.mpd.org/ ), even plain Apache does it fine too, in a way.

8. If you want easier to manage iptables wrapper, Shorewall ( http://www.shorewall.net/ ) and there are other wrappers too.

9. KOffice ( http://www.koffice.org/ ) and by individual components, Abiword ( http://www.abisource.com/ ), Gnumeric ( http://www.gnome.org/projects/gnumeric/ ), Gnucash ( http://www.gnucash.org/ )

10. Inkscape ( http://www.inkscape.org/ ) or Sodipodi ( http://www.sodipodi.com/ ) for vector graphics.

11. Miranda ( http://miranda-im.org/ ). Windows only.

13. Hmm , Samba? ( http://www.samba.org/ ), WedDAV (Look parent post), FTP (plenty ftp daemons, ex : http://www.proftpd.org/, http://vsftpd.beasts.org/ etc)

16. GPhoto ( http://www.gphoto.org/ ), EOG ( http://www.gnome.org/ ? ), GQView ( http://gqview.sourceforge.net/ ). The latters are for just viewing mainly.

20. FreeNX ( http://www.nomachine.com/ , http://freenx.berlios.de/ ) http://www.poptop.org/ ), L2TPd ( http://sourceforge.net/projects/l2tpd ), RP-L2TPd ( http://sourceforge.net/projects/rp-l2tp/ )

24. Postfix ( http://www.postfix.org/ ), Sendmail ( http://www.sendmail.org/ ), Exim ( http://www.exim.org/ ), Cyrus ( http://asg.web.cmu.edu/cyrus/imapd/ ), Xmail ( http://www.xmailserver.org/ ), qmail ( http://www.qmail.org/ )

25. Spamassassin ( http://spamassassin.apache.org/ )

26. Same as above.

27. XSane ( http://www.xsane.org/ ) for sane frontends.

30. Buzzmachines ( http://www.buzzmachines.com/ ) I could be wrong...

31. 'various GUI frontends' - X CD Roast ( http://www.xcdroast.org/ ), K3B ( http://k3b.sourceforge.net/ )

32. Don't know any opensource ones...

A good place to start is exim.org if you

1. do not want to use Postfix which runs almost perfectly for small networks in its default installation on many distributions.
2. want to run a powerfull, MANAGEABLE open-source mailserver

I strongly advise against using qmail. It is not open-source and may not be redistributed in a changed form. So you have to patch it up yourself if you want to add some features it didn't have at its latest release 1998(!). Furthermore it uses DJBs obscure daemontools which are so unlike init it hurts. It is a nightmare alone to get rid of them.

Hope this helps.

ps. Flame me, I know you will. You know who you are.

220 gate.acme.com ESMTP Sendmail; Wed, 8 Jun 2005 11:53:27 -0700 (PDT)
EHLO myhostname
250-gate.acme.com Hello [myip], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250- 8BITMIME
250-SIZE
250-ETRN
250-STARTTLS
250-DE LIVERBY
250 HELP

But I have played with a few mail servers (mostly hating it the whole way: setting up a non out-of-the-box install of Exim is like asking the University of Cambridge to kick me in the face repeatedly, every time), and there is such a setting as a smart host... Which I believe is to route your mail through their relay.

Any reason why they couldn't allow port 25 traffic, so long as it's destination is their mailserver? Then they can deal with spam on an individual basis, and even catch their own people doing it?

Once again, I'm not certain how well it works, but just a thought.

Good thing I am 16 now

Now is the time to put your nose to the grindstone. Start talking with your school's internship coordinator and start seeing about getting placed someplace where you can geek out and learn more, preferably someplace that you can use the skills you already have while learning new ones. Start hosting your own server (and not on Windows, and do it *all*, right down to hosting your own DNS. I got where I am now with my Linux experience, and extensive knowledge of bind and exim. I also dabble around with mysql and PHP, two things I need to bone up a bit on for my current role.

Being well rounded is also important. Years of Scouting

I hope this at least gives you a starting place.

Spammers do realize this. Many of the mass-mailer worms do not have any mechanism for actually doing SMTP communication....they simply dump what would be a legit SMTP session to port 25 on the remote machine. Many simple web mailer scripts (these often are exploited, too) also do this. The Exim Manual has a good description of this under the smtp_enforce_sync option. Turning this on has stopped quite a bit of bulk e-mail on my host.

There's also sa-exim which is a local scan plugin for Exim that does site wide spam filtering at SMTP time. It is quite nice.

Dave

I came across this message on Exim-users where one of the core developers flatly rejects the license, and it also indicates the Sendmail folks feel the same. Courier has also rejected it in a similar manner.

Sender ID needs rapid adoption, and it won't get off the ground with rejection from all the major FOSS MTA's.

I believe MS knows it, but they appear to fail to understand that licensing means at least as much for FOSS developers as it does for them. They said that they would update their FAQ with a promise that they will never charge for Sender ID, but miss the point that that isn't enough for developers.

I think this is extremely interesting, because it is the first time MS and the FOSS community comes together over something like this, where everyone knows that we have to get a standard up working. We're seeing a clash of worldviews, but if MS steps down now, they will have learned a valuable lesson.

I can't get to the article to check, but I was thinking exactly the same thing. I'm using Exim / Exiscan for e-mail. Messages first get scanned for viruses, then, scanned for spam content. Messages containing malware or which rate highly for spam content (10 points or above in SpamAssassin) aren't delivered - not quarantined, just logged, and bounced with a brief log message for the sender. Which, generally, is a piece of spam software or a virus, neither of which really care.

Come to think of it, I should replace those messages, just to see if anyone notices. "This message contained malware (Troj-JS-Script-A). Baby, you know that ain't right. Get with Smoove B. He shall procure for you the finest anti-virus software in all of the land."

Or something.

http://www.exim.org/

About time. I've been doing this with Exim and Exiscan for almost 2 years now. It's nice to see other MTA's begin to incorporate this functionality. Now, if everyone upgrades and takes advantage of this wonderful feature, maybe the number of false NDR's I receive due to forged senders will start to go down...

There's never been a better time to migrate from Sendmail

While listing alternatives you should check out exim which I have been using for about a year now. It may not be as simple as postfix but has a lot of nice features with really easy to read config files. Right now I use a combo exim/spamassasin/clam antivirus to keep most of the crap out of my inbox

It means that any system administrator can configure their mail transfer agent to bin any spam pretending to come from aol.com with a 100% success rate. And this goes for anyone else publishing an SPF record for your domain.

SPF is a proposed standard for a domain owner to tell mailers where mail From: that domain may originate. The domain owner publishes a DNS TXT record for their domain with (at the simplest) list of IP addresses. Participating mail transfer agents can then look this record up and make a policy decision on whether the mail is likely to be legitimate. The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.

SPF is not a wholly original idea (e.g. up "designated mailer protocol"), and certainly not the simplest implementation but the important factor is that its proponent, Meng Wong, is an excellent lobbyer and spokesperson, as well as someone who as the nous to put forward a useful protocol (he founded pobox.com). It's currently at the point where lots of implementation are being written, with the canonical version being Meng's Perl modules. Currently I'm helping to finish the C implementation which will shortly be integrated into qmail and exim.

The tipping point (I hope) will be when a domain not publishing an SPF record or publishing a globaly permissive one will be considered "obviously" untrustworthy. Combining SPF authorisation with a more traditional "From: domain blacklist" will give spammers a very very hard time indeed forging mail. But AOL publishing a record (we hope) shows the way the wind is blowing: the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.

So go on, it's dead easy, publish a record for your domain now. Tell people where your mail comes from. Look, there's even a wizard to help you.

I don't run a local MTA on my computer at work, but my Red Hat 9 workstation there has both Postfix and sendmail installed. I don't remember if sendmail was off by default or if I turned it off myself, but postfix doesn't appear in /etc/rc3.d.

Incidentally, on RH9, /usr/sbin/sendmail is a symlink to /etc/alternatives/mta, which is in turn symlinked to /usr/sbin/sendmail.sendmail, which appears to be the actual sendmail binary. Also, in addition to /usr/sbin/postfix, I also have /usr/sbin/sendmail.postfix. WTF?

Anyway. you didn't mention my preferred MTA, Exim, which is the default MTA on Debian.

Here is the reason why this doesn't affect me at work, and the reason why it doesn't affect any decent ISP. And here is the reason why it doesn't affect me on my LAN at home.

I am not in the least bit surprised that a closed-source product has problems. The only mystery to me is why anybody would pay good money after bad for a product and never be in total control of it. If you rent a house, you spend the whole of the rest of your life paying the rent and at the end of it, you have nothing to show for it. If you buy a house, you spend 25 years paying a mortgage, and then you get a piece of paper that says the house belongs to you and you don't pay anymore. If you use closed source software, you have to pay someone else for support and although you eventually get problems fixed, more or less, probably, you will still have to call The Man next time it goes T.U. If you use open source software, you can choose whether you pay for support in hard graft or in hard cash, and you get to keep everything you learned along the way.

Buy a litre of milk and you get to drink it once. Buy a cow and you get to drink all the milk you want. Easy decision, no?

Seriously, if you want to reject stuff at SMTP time rather than accepting it then processing it, try using sa-exim (a freshmeat search will turn it up) - it fits into exim and rejects as soon as it's worked out it's spam - mid-DATA if need be.

Procmail is your friend. Use it. In conjunction with SpamAssassin, you can filter it off to a folder to go send to SpamCop at your earliest convienence. While SpamCop officially discourages doing so, setting your mail server to reject based on the RBL bl.spamcop.net will save you some work (and money if you're a SpamCop member) by prohibiting mail from sites already reported by several people.

I use exim in conjunction with sa-exim to reject spam that scores high with Spamassassin, and to teergrube the luser. Since I'm the postmaster, I also have sa-exim give all the sa-exim rejected spam to my spam folder to report as well.

I have roughly 30 users. Almost all of them use my site for mail, since doing so is extremely spam hostile thanks to me, with very little inconvienence, if any, to legitimate mailers, which is the way it should be.

On an aside, I also use abuse.net's forwarding service to report hosts infected with viruses to their ISPs. I've been fairly successful, though it could be better. Roughly one third of the ISPs I contact suspend or terminate the user's account for it. I also maintain a net-lsearchable list of the last relay such infected messages go through before hitting my server. Feel free to use it for yourself, it's on my website.

That's why you should be using qmail, ya' code monkeys!

Great idea! I'll just download a package from my favorite distribution that's tuned qmail to mesh nicely with how my system is configured.

Hmm, they don't supply packages for qmail. Why not? They're not allowed to. If I take the time to make up such a package, I'm not allowed to give it to my friend.

Quoth Bernstein:

But that's a decision for the Apache maintainers, not the UNIX integrators!

Darn those pesky integrators, attempting to make their system internally consistent and trying to please their users!

I've heard great things about qmail, it's great that is available with source for no cost. But it's proprietary software, putting me at the mercy of Bernstein. If you want someone else to maintain a fork with features you desire, you're out of luck. It's fine if you're willing to accept that, but it's not acceptable to everyone. Fortunately there are other options available.

Who cares? Sendmail is obsolete.

qmail
postfix
exim

Is it perhaps time for a code rewrite in Sendmail...

IIRC 8.9 was the code rewrite.

maybe a quiet, dignified retirement?

At this point, I'd settle for a noisy drag-it-out-back-and-shoot-it.

Secure alternatives exist - Postfix, qmail. Other alternatives with better security track records and lower target profiles exist - Exim, Courier.

Time and past time to move. How many holes is it going to take?

I've worked a lot with cyrus, courier, and WU-Imap.

Wu -- Simple and easy to install, but slow and minimal features

Cyrus -- Definitly the fastest, but a pain to configure and I found that the user databases got corrupted very easily. This would result in users being able to see messages but not download them.

Courier -- Definitly my favourite, its almost as fast as cyrus, has tons of features and really scales, the customers I have using it typically have a few hundred accounts on midrange P3/IDE machines.

Setup is a bit complicated, but I have the users details stored in a mysql database, multiple virtual domains on a box, and the delivery of the messages is handled by exim, again using mysql for the delivery details. Because each message is stored in a separate file, it is easy track down and remove problem messages accross an entire domain. It also makes it pretty bullet proof.

But lots of exim's features (and ease of configuration) may tip the scales for some people over postfix, courier or sendmail.

For example, exim has the ability to block mail by referencing the DNSBL (DNS block lists) or the RBL (realtime block lists) for hosts known for spam relays. See exim's rbl howto.

Postfix is good, but it comes down to what the sysadmin believes is a good tradeoff between features and security.

There's been discussion about switching to postfix as the default for new installs however, and it may even be a done deal. A lot of arguments have been tossed about for this, however the biggie seems to be its simplicity: with something as complex as exim or sendmail, there are just more opportunities for something to go wrong. Postfix is quite enough for most users.

Exim seems to be quite popular at ISP's recently.

Or, for Exim, try the included system_filter.exim (see here for example)

Exim patched with Exiscan does that. You can bounce incoming messages based on a virus check, too. Any message is checked before Exim sends "250 Message OK" so it won't enter any local queues.

Regarding cost, a colleague outsourced her county's mail server to the regional telco altogether thus decreasing costs, increasing availability/reliability, and dratically decreasing client-side maintenance/support. Her previous situation was the the MS-Outlook + MS-Exchange problem you describe. Those were side benefits, the main reason to drop MS-Exchange was to get acceptible uptime and reduce the number of lost messages. The upfront costs of the outsourcing went from 7 to 3.5 per user per month. I've seen analyses showing $2 USD per user per month for FOSS solutions when serving 5000+ users, so 3.5 has to include a nice profit.

The client side benefited, too. Since end users were no longer locked into MS-Outlook, the support time for clients went down from several hours per week to less than an hour. That and outgoing/incoming external mail stopped disappearing.

Using Postfix, Exim or qmail seems to be best practice. In addition, these can be run on any platform, whereas MS-Exchange has the added drawback of being locked into a single platform.

From my observations at 4 sites, pretty much any MTA is worlds more stable and reliable than MS-Exchange. My previous employer tried to put the whole institution on MS-Exchange which was a nightmare. Among the main problems, I found that 15% of the incoming mails (to a legitimate address) during a two week test either just disappeared or bounced with a 'user does not exist'

Lost mail == delayed projects or lost bids.

I have not found a mail system as stable as Outlook with an Exchange server.

I have not found a mail system as unsecure, unstable and incompatible with external users as Outlook with an Exchange server.

Most common single-server mail transports can sustain ~10k-100k deliveries per hour under ideal conditions, with this delivery rate frequently saturating available bandwidth. Issues such as MX and DNS resolution become significant at these volumes. Thus, 100m mails is 1,000 server-hours of time.

Sending more mail requires multiple servers and mulitple pipes. Both of these are resources which are only available to the spamhaus at additional cost or reduced control.

The mitigating issue is that multiple drops (cramming hundreds or thousands of local deliveries to a receiving MTA at once) can reduce the total outbound time. Again, anything that reduces this capability (allowing, say, no more than 10 local deliveries on a single connection) increases the spamhaus's need for resources: servers, time, or specialized software.

See:

• Google:mail server performance messages hour
• ListManager (250k msgs/hr) Note that List MailEngine claims up to 10m messages/hr, but only 150k/hr for a single server.
• Exim FAQ claims 13k/hr max
• Intershield - 45k/hr
• qmail: 135k/day

I'm not 100% certain if I understood that correctly, but if you want all email designated to 'fnord@foo.ba' to be sent via SMTP to 128.42.42.64 (regardless of whether or not that box is a MX for 'foo.ba'), you could try to add a router like this to the top of your list of routers:

explicit_delivery:

driver = manualroute
domains = foo.ba
local_parts = fnord
transport = remote_smtp
route_list = * 128.42.42.64

Completely untested, but it just might work. :-) If you wanted a local delivery in addition to the remote delivery, try adding the 'unseen' option.

Secondly, would be nice if exim also directed user+foo@bar.com type names to user@bar.com, as sendmail does..

As someone else mentioned, 'suffix' and 'suffix_optional' is correct, in a way. It was called that in Exim 3, which is deprecated now -- upgrade and be happy. You'll -love- the new shiny ACL's. :)

Anyway, in Exim 4 it's called 'local_part_suffix' and 'local_part_suffix_optional', and it's placed in a router instead of a director (there's no such thing as directors in Exim4, which IMHO makes the configuration file a much more enjoyable read). After having configured those two, you can make ~/.forward-(suffix) files for individual handling of the various local parts.

Hope that helps! --and take care to check the excellent specification if not! ;-)

an random exim fanboy