LCA: Lessons from 30 years of Sendmail [LWN.net]

LCA: Lessons from 30 years of Sendmail

Posted Feb 4, 2011 3:19 UTC (Fri) by dskoll (subscriber, #1630)
In reply to: LCA: Lessons from 30 years of Sendmail by HelloWorld
Parent article: LCA: Lessons from 30 years of Sendmail

I don't mean to insult you, but this is exactly the mindset I mean.

Meh... everyone tends to like tools he/she is familiar with. That's just human nature. Maybe some Perl or Ruby fanatics will eventually write an MTA in their language...

Any decent language has a foreign function interface for calling C functions.

But... but... then you're back in dangerous territory, no?

No, they don't. C won't give you the fastest possible result, assembly will (portability is not an excuse, use a portable assembly language like LLVM assmbly)

OK, now I know you're just arguing for the sake of argument. :) That's totally ridiculous and you know it.

Anyway... go ahead. Write a UNIX MTA in something other than C or C++ and see how it fares. The proof is in the pudding.

(Log in to post comments)

LCA: Lessons from 30 years of Sendmail

Posted Feb 4, 2011 12:59 UTC (Fri) by james (subscriber, #1325) [Link]

Using qpsmtpd for traps.spamassassin.org describes how SpamAssassin had been using Postfix on a donated server for their spamtraps.

Unsurprisingly, they were getting a lot of spam on that server, and postfix was having trouble keeping up. So they switched to qpsmtpd, "a flexible smtpd daemon written in Perl" which uses "Danga Interactive / Six Aparts insanely scalable event-driven asynchronous socket class".

Justin reports: "results have been great we now have a pure-perl system handling heavy volumes without breaking a sweat, certainly compared to the previous system."

LCA: Lessons from 30 years of Sendmail

Posted Feb 4, 2011 16:07 UTC (Fri) by dskoll (subscriber, #1630) [Link]

I read that article. The problem with the Postfix solution was not Postfix, but the fact that they were filtering from a procmail-invoked Perl script. That's a huge fail.

We run our Perl spam-scanner in conjunction with Sendmail, but we use the Milter interface to keep persistent Perl scanners running. The bottleneck in this system is by far the spam-scanning; Sendmail doesn't even show up on the radar.

LCA: Lessons from 30 years of Sendmail

Posted Feb 5, 2011 1:23 UTC (Sat) by HelloWorld (guest, #56129) [Link]

Meh... everyone tends to like tools he/she is familiar with. That's just human nature.

This is another way of saying "I do it that way because I always did, but that's OK because everybody else does too.".

But... but... then you're back in dangerous territory, no?

Using a C library and writing the rest of the program in another language is still better than writing it all in C.

OK, now I know you're just arguing for the sake of argument. :) That's totally ridiculous and you know it

It's not, you just didn't understand my point. You said that MTA authors attempt to make their software as efficient as possible, which, together with the fact that most MTAs are written in C, implies that C is the language you can write the most efficient software in. But this simply isn't the case: C is just one spot among many, many, many others on the efficiency-vs.-comfort curve. More specifically, it is not on the performance maximum of that curve, since that's where assembly language is. Yet, many (most?) people seem to believe that C somehow hit the perfect spot for "systems" programming. Even if that was true in 1970, people should start getting comfortable with the idea that it's not any longer.

LCA: Lessons from 30 years of Sendmail

Posted Feb 5, 2011 1:51 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

Yet, despite C++ having been available for so long, there's still a distinct lack of widely-used operating systems written in it. Good system programmers are often tend to be the ones familiar with the kernel underlying their code, and that means having to have a good grasp of C regardless of what you'd prefer to code in. There's a natural selection pressure in favour of C even if there are arguably better choices.

(The first significant codebase I worked on was C++, and I've probably still written more Perl than I have C)

LCA: Lessons from 30 years of Sendmail

Posted Feb 5, 2011 17:10 UTC (Sat) by dskoll (subscriber, #1630) [Link]

But this simply isn't the case: C is just one spot among many, many, many others on the efficiency-vs.-comfort curve. More specifically, it is not on the performance maximum of that curve, since that's where assembly language is.

It's not a smooth curve. The transition from C to assembly involves a *huge* increase in the difficulty curve with a relatively modest increase in the efficiency curve. C is a just-high-enough/just-low-enough level language to hit a sweet spot in efficiency-vs-difficulty.

But you already know this and are just arguing for the sake of it.

LCA: Lessons from 30 years of Sendmail

Posted Feb 6, 2011 1:37 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> But you already know this and are just arguing for the sake of it.
No, I merely disagree with you. C doesn't sit in a sweet spot, as there are many, many useful features that could be added without compromising efficiency, like templates, modules, proper macros and many more. Anyway, discussing this with you is obviously pointless by now.