Slashdot Mirror

Here's what sendmail has to say about "plussed users":

http://www.sendmail.org/m4/misc_features.html
http://www.google.com/search?q=sendmail+plussed+users+site%3Abooks.google.com

This is a configuration error, not a newsworthy event.

    For sendmail, it would be a configuration directive in their sendmail.mc (or whatever theirs is:

confMAX_RCPTS_PER_MESSAGE("100") ... or a modified line in sendmail.cf:

O MaxRecipientsPerMessage=100

    In MSExchange it would be a registry change

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Max Recipients on Submit

DWORD Value 100

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...

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 best thing honestly would be for these servers to just clean their act up and handle things properly. Mail rejects should be done before the connection between the two servers closes. It should always be up to the SENDING mail server to generate a bounce rather than the receiving.

Eh, not so, unfortunately.

Sendmail has a drop-dead simple way of setting up "slave" mail servers in case the primary is down, an option that's commonly used for backup mail relaying. It's part of the official Sendmail documentation and so is very unlikely to "go away". And, when this is enabled, there is no address verification "before the connection between the two servers close[s].".

So, good luck with enforcing your ideas on how the world should work!

I have the following config in my sendmail.mc:

FEATURE(`require_rdns')dnl
FEATURE(`block_bad_helo')dnl
FEATURE(`enhdnsbl', `zen.spamhaus.org', `"Message from $&{client_addr} rejected - see http://www.spamhaus.org/query/bl?ip="$&{client_addr}', `t')dnl
FEATURE(`enhdnsbl', `bl.spamcop.net', `"Message from $&{client_addr} rejected - see http://spamcop.net/bl.shtml?"$&{client_addr}', `t')dnl
FEATURE(`dnsbl',`combined.njabl.org',`Message from $&{client_addr} rejected - see http://njabl.org/lookup?$&{client_addr}')dnl
FEATURE(`dnsbl',`list.dsbl.org',`Message from $&{client_addr} rejected - see http://www.dsbl.orgdnl/
FEATURE(`dnsbl',`dnsbl.sorbs.net',`"Message from $&{client_addr} rejected - see http://www.sorbs.net/"')dnl
FEATURE(`dnsbl',`dnsbl-1.uceprotect.net',`"Message from $&{client_addr} rejected - see http://www.uceprotect.net/"')dnl
FEATURE(`dnsbl',`dnsbl-2.uceprotect.net',`"Message from $&{client_addr} rejected - see http://www.uceprotect.net/"')dnl
FEATURE(`dnsbl',`dnsbl-3.uceprotect.net',`"Message from $&{client_addr} rejected - see http://www.uceprotect.net/"')dnl

There isn't even any problem doing a secure setup for persons roaming, in which case it's possible to set up a SMTP AUTH on a different port. I have at the same time elected to use SMTPS (SMTP over SSL), which means that any password and information sent over the net is encrypted.

Below is the code I use for listening on a secondary port (465/smtps) with AUTH and certificate handling for encryption.

DAEMON_OPTIONS(`Port=25')dnl
DAEMON_OPTIONS(`Port=465, Modifiers=as')dnl
define(`confPRIVACY_FLAGS', `noexpn novrfy authwarnings')dnl
define(`confFALLBACK_MX', `smtp.bredband.net')dnl
define(`confCACERT_PATH', `...ssl')dnl
define(`confCACERT', `...ssl/cacert.pem')dnl
define(`confSERVER_CERT', `...ssl/certs/smtp.pem')dnl
define(`confSERVER_KEY', `...ssl/certs/smtp.pem')dnl
define(`confAUTH_OPTIONS', `p,y')dnl
TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 PLAIN LOGIN')dnl
define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 PLAIN LOGIN')dnl

At least the actions I have taken discourages the spammers good enough and makes me feel reasonable safe. (there is always another leak, but you have to find it first).

it's easy to start a piece of shit GPL project - take a look at http://www.gnu.org/software/emacs/ or http://www.sendmail.org/!

There are some things you can do to protect yourself. I've been running my own mail server for over 10 years, and I have to say that it's the least of my headaches from my home server. Keeping up with spam filtering technologies is a mild pain, but SpamAssassin has gotten quite good at making that less of an issue. I do wish MX handling were smarter than it is, but you don't *have* to worry about it.

The only thing is that it ends up costing me in ISP price. Most of the net has gravitated toward the position that MTAs are not valid if they're within dynamic IP ranges, which painful though it may be to see the "network of peers" reduced to the "network of clients and servers," I had to adapt to. Sadly everyone and his brother now believes that static IP addresses are some sort of "advanced business solution," so you have to go to a small provider like Speakeasy to get decent pricing.

Hey, look! You don't know what you're talking about. M4 is a programing language (well macro processor) and coincidentally I'm not retarded.

Huh? The "Security" link on the front page of http://sendmail.org/ works fine.

• mOnOwall - firewalling
• IPCop - firewalling
• Metadot - CMS
• Apache - web server
• Bind - Name Server
• asterisk - telephony/voip
• Sendmail - cussed but stable MTA
• SpamAssassin - spam filtering
• MIME-Defang - email content filtering/manipulation
• ClamAV - Virus filtering
• Freebsd - the best OS since sliced bread (IMHO)
• Centos - Not to shabby an OS either
• ...

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.

It was released a little while ago. The design looks suspiciously like postfix and qmail. :)

Sendmail X may address many of Sendmail's orginal design problems (certainly seems more modular). Or have they blotted their copy book one too many times in most people's eyes. See http://sendmail.org/sm-X/release-smX-0.1.Beta2.0.h tml

If sendmail is so egregiously evil, how come most alternatives to sendmail are basically less functional sendmail clones?

Wietse Venema's Postfix and Eric Allman's Sendmail X are API-compatible total rewrites of sendmail. Postfix is currently stronger, but sendmail X implements pretty much the same shite as postfix, so the advantage is code maturity - right now postfix is arguably better than sendmail 8 (which is what NetBSD ditched, incidentally) and when sendmail X gets its legs it will probably be even better. Each one incorporates lessons learned from its predecessor.

Run postfix if you are starting from scratch; it's easier to learn. If you already know sendmail, or you need antique transports, run sendmail 8; it is more flexible. When sendmail X is mature, run that (run it now on your test machines). When the next evolution of MTAs arrives, with telepathic agents and antigravity packaging, run that.

Remember that the criticisms being leveled against sendmail 8 are equally valid when applied to old-school unices like NetBSD. Ancient codebase, long history of security problems, tough learning curve, etc. But *nix still has its uses (particularly the newer rewrites like linux).

• A security alert from March of 2003 in which Sendmail has been determined to contain a buffer overflow vulnerability.
• Another security alert from later that year.
• A security alert also from 2003 regarding a remote buffer overflow.
• A security alert from 2002 regarding a trojan horse horse sendmail distro.
• Some freebsd specific Sendmail alerts.
• A security alert from March of 2006 (this year) regarding a race condition that may allow remote code execution by an arbitrary user.
• A plethera of similar or smaller security concerns can easily be found.
• The most recent release of Sendmail involves things like fixing possible integer overflows & unsafe use of setjmp(3)/longjmp(3) or adding time outs.

There is Sendmail at http://www.sendmail.org/ .

Since your program basically acts after data is received and dumped in the inbox by the MTA, I don't see it as being much more effective in the fight against spam than a content filter, except for requiring less maintainance.

OTOH, if you could code it up as a proxy for desktops which hijacks connections to port 25, and filters outbound mail, it would actually be useful. Stopping the spam from being sent is a much better way to fight spam.

Considering the size, age and complexity of the sendmail code base, there can't be too many people who know which line to patch. Sendmail is ugly and unmaintainable, and needs to be rewritten from the ground up. Just ask sendmail. (The design document reminds me strongly of postfix. And no more sendmail.mc, yay!)

You better re-examine your idea of security here. For starters, your ISP that you connect your server to can easily store both sides of a conversation...it has to pass through their server *both ways* for you to communicate.

Well, no.

If you truly run your own mail server, with MX records rather than using your ISP's POP box as a store-and-forward, then it isn't going through their server. Technically ;>. The only real difference this makes is that your communications clearly fall under the Pen Register rules rather than the Wiretap rules when the authorities try to legally obtain info about your communications.

It does still go through their network. But that's a (slightly) different matter. Yes, they can still sniff the traffic both ways. This is where StartTLS comes in. If your mail server offers StartTLS, and the remote mail server is willing to try it, then everything except the EHLO of the SMTP transaction is encrypted just as HTTPS web pages are.

You can easily set up most mail servers to run "Opportunistic" StartTLS. That is to say, "Offer it, and take advantage if someone else offers it, but don't require it." For the purposes of encryption, it doesn't matter that most people will use self-signed certificates. (Yes, that kills authentication.)

You can also require StartTLS, but that would impact your ability to send and receive mail to sites not configured to do StartTLS. (But for the paranoid, it bears mentioning.)

Google quickly found a few sites for various mail transfer agent configurations:

• Postfix
• Sendmail
• Exim
• Qmail
• Exchange (no good link, and may not allow opportunistic)

In short... my mail server secures mail with anyone else who cares to do so. If you are enough to run your own server, consider caring enough to offer and take advantage of StartTLS encryption.

N.B. - If self-signed certs are a pain (and they are), look into CAcert.

Take a look at Sendmail.org and Sendmail.com - one corporate and one OSS.

All of these systems will be running sendmail.

You're high. Building a massive production email system on Sendmail 9 is slow-motion suicide. If the security holes don't get you, the terrible configuration methods and complete lack of scaleability will, nevermind the fact that Sendmail Inc is trying desperately to replace the product.

"Most managable with [...] heavy customization?" I'd laugh if I wasn't crying. And I'm crying because I used to work for a company that deployed a massively customized sendmail infrastructure -- and I was one of the poor bastards who had to maintain it. Trust me, you don't want to do this. Ever.

Yes, milter is cool. No, it's not cool enough to justify burning CPU cycles on sendmail in 2005.

Even Sendmail Inc tacitly admits that Sendmail's design is garbage: take a look at the design document for Sendmail X, and note carefully how much it resembles Postfix and Qmail. There are very good reasons for this.

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...

That is, when sendmail looks up a plussed address (for example root+foo) it does so in the following order:

* Look for an exact match. Does root+foo match root+db?
* Look for a wildcard match. Does root+* exist? If so, use that alias for root+foo.
* Look for a base match. Does the root of root+foo exist as an alias? If so, use that alias for root+foo.

• OSDL
• Sendmail
• Eclipse
• Ghostscript

Sendmail has a commercial product with a bunch of features for people who like that sort of thing.

Course their pricing is off the wall.
I couldnt believe the FUD their sales skunks were telling the windows fools in my previous job.

I convinced the company to save the $Kash and we went with the standby from sendmail.org.

Sun's sendmail as opposed to the version offered on http://sendmail.org/

lost worker productivity among end users is just one important factor in the total cost of spam.

there are a number of other important factors, including:

• more time spent administering e-mail servers: keeping MTA current (e.g. sendmail or postfix upgrades) and keeping anti-spam software up-to-date (e.g. spamassassin upgrades, some occasional score tweaking, etc)
• occasionally upgrading server hardware to keep pace with increasing spam bombardment
• time spent investigating major spam incidents and/or abuse complaints (e.g. resulting from spam sent with headers forged to look like they come from your domain)
• bandwidth and disk space used by spam

MTA, or Mail Transfer Agent, meaning sendmail or postfix, or any similar program that is supposed to deal with SMTP.

At work, I've gotten used to the necessity of people knowing each other's passwords. The one thing that would eliminate most of the need is this:

In Windows, the "Advanced" login pull-out (the one that displays the domain) should also have a second username field. With it, you could log in as one user with another user's password, provided that the second user is an administrator or has been authorized in some fashion. This would help us install software and test that it works as the appropriate user, without either (A) requiring the users to stay lurking around while we work or (B) making them give us their passwords.

If Windows and Oracle both did this, we could say to our users "never give anyone your password; there's no reason for anyone but you to ever know it" and actually mean it.

Whenever I design an authentication system, I do this. Cyrus SASL supports this idea; they call it separating authentication and authorization identifiers.

Sendmail Inc. http://www.sendmail.com/ is a commercial company that provides an open source Sender-ID (sid-milter) http://www.sendmail.net/ for Sendmail and provides Sendmail source code to the Sendmail Consortium http://www.sendmail.org/. The Sendmail Consortium maintains the open source version of Sendmail (from source code provided by Sendmail Inc.) and does not support Sendmail sid-milter. Guess which Sendmail entity (.com or .org) wins any arguments?

Sendmail's licence is a hybrid between the GPL and the BSD licences. I think it lets you get away from the patent issue though (ask a lawyer to be certain).

Apache impressed people with its English-style configuration directives that have influenced other developers to switch to such logical formats. Another example: the Postfix MTA is becoming more popular and many users say they enjoy using it because of the straightforward configuration, compared to the m4 mess of sendmail. "It has to be complicated to be powerful" is no longer an excuse.

Hell, Sendmail even predates DDoS!

There are better ways to do this. First off there's Sendmail "plus notation," also known as "user+detail" format. If you haven't heard about this you should do some research on Sendmail's website. The other method if you own your own domain, which obviously you do if your using a catch-all address, is to simply use aliases. Add your custom alias to your local aliases file, rerun newaliases, and you're set. Personally I use a little of both. I use aliases all the time. I can add an alias in a matter of seconds at any given point and time. A quick look at my current aliases file shows me aliases for dictionary.com, outdoorsuperstore.com, The Wall Street Journal, The New York Times and more. The best part about aliases is I can turn off the flow of spam by simply removing the alias. To stop the flow of spam to an address using plus notation I have to whip up a procmail recipe. I've seen more than one spammer strip the plus notation from outgoing addresses though so it isn't always going to stop the flow of spam. Not all web forms accept the plus sign as a valid email character. YMMV, no, I take that back. I can guarantee your mileage won't vary. Catch-all addresses have only one valid use: to collect spam. Plus notation will work much of the time. Aliases will work all of the time.

On sites that have a legit need for my email address like Amazon, ebay, Newegg and others I buy stuff from I use Sendmail's plus notation (also known as the user+detail format) OR an alias on one of my personal domains. I use aliases quite a bit. That way I can remove the alias and shut off the potential (or actual) flow of spam to that address. It's easier to remove an alias than it is to have Procmail filter out mail to a given plus notation address. It always amazes me who gets my alias or plus notation email address over time. For example I may notice that I'm getting penis enlargment or mortgage spam from "networkcomputing@mydomain.com." Hmm... I wonder who sold the spammer that address... Hmm....

When filling in First name Last name fields I always use Marion Morrison. Before you Google for that name try to guess who's it is (ok, a hint, was).

I also understand that it's very common to use pres@whitehouse.gov, or so I hear. Another favorite is darl@sco.com

1. ISPs (and any other business that gives a workstation a "real" IP address) need to block egress port 25. Comcast is going to be doing this soon, others should soon follow suit. This plugs the zombies.
2. IP addresses that continue to send spam will be blacklisted. With the zombies effectively out of the loop this will become easier (albeit never quite perfect).
3. SPF and other authentication schemes need to be adopted to prevent "spoofing" and so called "Joe jobs".
4. E-mail providers (including small companies) need to deploy mature e-mail systems for their users. In 1995 it was fine to accept e-mail from anyone on port 25, with no authentication and no encryption. In 2004, remote clients need to have an SSL connection available (both for sending mail and accessing inboxes), and must require authentication before accepting initial mail submission (SMTP+TLS+AUTH). Not only is this more secure, but it also addresses the issues always raised by blocking egress port 25 and deploying SPF.

Appendix:
SMTP+TLS+AUTH is not that tough, no whining. All modern mail clients support it, on all platforms. There is a little bit of work to do on the server end, but that's what you pay your ISP (or IT department) for:

• postfix
• sendmail
• exchange
• qmail

There is some merit to talking about some mission critical programs being moved to java, but of course you have to recognize that VM's are vulnerable to all sorts of hacks.

I do think that java probably is preferable as a language for avoiding buffer overflow vulnerabilities, especially for less experienced developers. It will be interesting to see how James will stack up with the notoriously holy (pun intended--damn I crack myself up) Sendmail. There ARE other examples of java in critical situations, I'm sure -- but none spring to mind.

I do constantly use java to write the shell stuff that I know someone is going to bang on -- just because I haven't seen a root exploit from a java process yet.

• Abiword - Word processor, supports .doc, .rtf, GPL.
• Open Office - Whole Office suite, including a database frontend and BASIC macro language.
• Perl - Scripting language
• Python - Scripting language
• Cygwin - UNIX emulator. Can create Windows programs, reliant on a cygwin1.dll.
• MinGW - Port of some of the UNIX utilities (BASH, gcc, vi...) to Windows.
• djgpp - UNIX emulator for DOS.
• Mozilla, Firefox, Thunderbird - Web browser, e-mail client, IRC client, lots more.
• Filezilla - FTP client.
• xchat - IRC client.
• putty, pscp, psftp and others - Telnet/SSH clients.
• Gaim - Client for IRC/Yahoo/MSN/ICQ/AIM and more.
• gzip - Compression (usually better than .zip).
• tar - Extracts/Makes tar archives.
• bzip2 - Totally ace compression (usually better than gzip).
• Info-ZIP - Support for .zip. Good free substitute for Winzip.
• 7-zip - Support for multiple compression formats.
• frhed - Hex editor
• Ext2fs - Several programs for doing Ext2 under Windows.
• Antiword - Converts documents out of the proprietary .doc format.
• MySQL - RDBMS.
• Apache - Web/Proxy server
• sendmail - Mail server
• squid - Proxy server
• freeamp - Audio player
• winlame - MP3 encoder
• cd-ex - MP3/OGG encoder?
• gimp - Very detailed graphics program.
• imagemagick - Graphic manipulation. Provides the 'convert' utility under UNIX.
• freeciv - Civilisation clone.
• gnuplot - Plotting package.
• TightVNC - A fork of VNC, with enhancements.
• RealVNC - The original VNC.
• rdesktop - Access Windows Terminal Services and Remote Desktops.
• Nmap - Well known port scanner.
• John the Ripper - Password cracker. Does NT and MD5.

Yep, that about does it!

This comment is definately worthy of an Informative, I have been saying for a long time that there should be a standard DNS record for SMTP servers to simplify blocking them from mail exchangers

There are actually two different competing standards for DNS records for indicating which source IP addreses can legitimately source email for a given domain, both were covered on Slashdot not long ago.

does anyone reading this know of other solutions (aside from write one) to block dynamic IP addresses from the mail exchangers?

I use qmail-spamthrottle, with exceptions (high limits) for just a few mailing list servers. You can even populate the cdb file from the PDL and basically restrict the entire Cox cablemodem network to sending you one message per minute if you'd like.

Sendmail 8.13 (currently in Alpha testing) offers a very simplistic version of rate-limiting by source IP address. I've heard rumors of similar enhancements to Postfix.

Too right, Sun never make good use of technology they didn't invent ! Oh, wait...

> "The Internet is powered by open source."
Like Cisco or Nortel?
No, like Sendmail, or Cisco's Open Source Initiative

>"The Internet is the carrier for open source."
It's also the carrier of porn and illegal copies of propritary software.
That doesn't transfer evil to (F)OSS merely by being transported the same way (except in the eyes of some people ... who run the country :-( ).

>"The Internet is also the platform through which open source is developed."
It is also the platform through which propritary software is developed.
(Thus associating proprietry software with pr0n and warez as you pointed out above. ;-> )I think the point being made is about the exapandability of the of (F)OSS development style.

>"It's simply going to be more secure than proprietary software."
Not nescessarily. Most insecurities are due to looming release dates. There is also a tradeoff between usability and security. Which is better? Depends on your mission.
Many (F)OSS projects lack big PR departments which have an alarming tendancy to set release dates and feature lists at early stages. And usability IS improving, with the improvements in KDE/Gnome, even though the GUI is not so essential for many computing uses.

>"Open source benefits from anti-American sentiments."
Not sure about this. I just got back from Kuait and there are literally hundreds of street vendors there selling propritary software.
But how many were selling legal copies? (F)OSS software companies are often not so hurt by illegal copying as propietry software companies would be.

>"Incentives around open source include the respect of one's peers."
Like the respect between the Reiser group and Linus? Why did it take so long to get that patch added? Those two crews showed as much respect as a couple of kids yelling "Did not! Did too!"
Surely that is an exceptional case. The job of Jobs/Wozniak/Gates is to make money for shareholders. The job of Torvalds/Stallman is to make great software (I think).

>"Open source means standing on the shoulders of giants."
Uuh, not sure what he means by this. I'm assuming he means IBM. What about Sun, MS, Adobe, and other closed source "Giants"?
That quotation of Newton's metaphor is a little confusing in this case. Newton (originator of quote) meant that he could start with previous scientist's public discoveries instead of wasting time having to rediscover them. (F)OSS developers can often start with bits of public existing code instead of wasting time having to reinvent them.

>"Servers have always been expensive and proprietary, but Linux runs on Intel."
So does Windows. And when you are buying a $10k server, $200 for Windows doesn't even figure into it.
He seems to be talking about disadvantages of Apple (and similar) here.

>"Embedded devices are making greater use of open source."
You have a winner here. But imbeded Windows and QNX are also players. This marker is not usually concerned with backwards compatibility and is very volitale in regards to the underlying kernel they choose. If x86 chips become prevalant, expect Windows to dominate.
But (F)OSS Kernels are far more easily and cheaply trimmable and tweakable than proprietry ones. e.g. GNU/Hurd will (eventually) have modules, which can be loaded across a (e.g. mobile phone) network as needed.

>"There are an increasing number of companies developing software that aren't software companies."
This has always been the case. Lots of companies need some app that custom-built. They don't really care where the source comes from. Since the app is rarely redistributed, they have no requirements to relea

we are going to have to have more overhead in a "new" SMTP protocol of some sort

SMTP has been extended to allow authentication and verification of senders. Combined with some simple firewall rules on the part of ISPs and businesses, we could have this spam problem under control. Here's what we need:

• If you have an SMTP server that external (to your network) clients need to use to send mail (ie initial mail submission), use SMTP+AUTH+SSL (how-to, how-to). Configure initial mail submission on a port other than port 25 (465 or 587).
• ISPs, businesses, free hotspots, block egress port 25 traffic! The only reasons not to are addressed by the previous item.
• Implement SPF:Sender, for your SMTP server as well as publishing the DNS records.
• Use reasonable blacklists (DNSBL). As systems start to adopt the first three points (and more and more are every day), blacklist those systems that don't. They will be the only places left people could effectively send spam from. ISPs not cutting off spammers will continue to end up on blacklists, which leads to an economic hit (see original article).

Once in place (and these are just not that tough, so no whining), the economics of spamming start to change. Spammers will find it harder to set up shop. The use of hijacked Windows workstations is eliminated through egress port 25 blocking and blacklists. Spammer friendly ISPs are blacklisted, so that no longer works. Inboxes throughout the world rejoice. The Russian mob surrenders. The world plunges into a thousand years of peace, prosperity, and happiness.

we are going to have to have more overhead in a "new" SMTP protocol of some sort

SMTP has been extended to allow authentication and verification of senders. Combined with some simple firewall rules on the part of ISPs and businesses, we could have this spam problem under control. Here's what we need:

• If you have an SMTP server that external (to your network) clients need to use to send mail (ie initial mail submission), use SMTP+AUTH+SSL (how-to, how-to). Configure initial mail submission on a port other than port 25 (465 or 587).
• ISPs, businesses, free hotspots, block egress port 25 traffic! The only reasons not to are addressed by the previous item.
• Implement SPF:Sender, for your SMTP server as well as publishing the DNS records.
• Use reasonable blacklists (DNSBL). As systems start to adopt the first three points (and more and more are every day), blacklist those systems that don't. They will be the only places left people could effectively send spam from. ISPs not cutting off spammers will continue to end up on blacklists, which leads to an economic hit (see original article).

Once in place (and these are just not that tough, so no whining), the economics of spamming start to change. Spammers will find it harder to set up shop. The use of hijacked Windows workstations is eliminated through egress port 25 blocking and blacklists. Spammer friendly ISPs are blacklisted, so that no longer works. Inboxes throughout the world rejoice. The Russian mob surrenders. The world plunges into a thousand years of peace, prosperity, and happiness.

Have your mailhost take a look at SMTP+SSL+AUTH for initial mail submission. That's how my mail server is set up (I am the admin), and we provide mail services to many customers. None have any problem, regardless of their ISP, WISP, hotel, etc. they might be using for access.

Actualy, most of the recent viruses/worms/pick-your-term have their own, built in SMTP engine. This allows the infected workstation to look up the MX records of the recipient (the next potential victim, that is), and connect directly to thier incoming SMTP server.

The responsible thing for ISPs and businesses connected to the internet is to block egress port 25 traffic. There are a number of ways to still use external SMTP servers, such as SMTP+AUTH+SSL, which idealy is configured to use a port other than 25 (465 and 587 are the most common with such a configuration).

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?

I guess this is the best this spammer could do since the sendmail patch.

This is the patch: parse8.359.2.8.