Slashdot Mirror

I had the same problems. The server was bombarded with spam and couldn't process its normal mail. I fixed it by installing qpsmtpd http://smtpd.develooper.com/ , a fully programmable Perl smtp daemon that can function as a front end for qmail or postfix.

I needed some fancy logic, because I use mailing lists with dynamic addresses that have to be refused /accepted intelligently. Qpsmtp does that well.

If you need a real flexible smtp daemon, and can program in perl, I would recommend qpsmtd. Give it a try, you can create your own plugins (to handle spam or whatever you need) so easily you won't believe it.

Take a look at qpsmtpd:

http://smtpd.develooper.com/

Perl's performance for CGI is bad without some sort way of increasing its speed. The major options for this are:
- Apache and mod_perl - This can work transparently, but if you look at it funny, it breaks.

Agreed... hate it.

- FastCGI - which isn't transparent by any stretch of the imagination.

I'll take your word on this one -- I've never used it.

- SpeedyCGI - Same problem as FastCGI.

Have to disagree with you on this. As long as your code is already use strict compliant, you shouldn't have to make any changes at all to get things running under SpeedyCGI. I've used it in quite a number of locations, both in a CGI context and for regular sysadmin and mail server duties, without any sort of mind-bending issues (except for if I was doing heavy shell file descriptor magic, since it moves things around when doing its pipe). Strongly recommended.

- PPerl - which isn't necessarily written for use in CGI.

True. See above. PPerl is an interesting choice if you *do* in fact need to do some heavy shell file descriptor magic (see http://smtpd.develooper.com/). I've kept with SpeedyCGI for other reasons though.

- Rolling a custom http server using HTTP::Daemon or Socket. Which is a really bad idea.

Not if you enjoy pain. =)

It may seem bizarre to you, but apache.org's mail servers already run on an SMTPD that runs in the apache2 process. It's called Qpsmtpd.

qpsmtpd
http://smtpd.develooper.com/

Replying to myself...

So reading the full disclosure they used 4 quad xeons. That's 16 CPUs. Compared to apache.org's 2.

So using a pure perl SMTPD you can have this kind of throughput (~1m mails per day per CPU) with spam and virus filtering enabled.

No, I am not impressed with this benchmark.

I didn't even know there was a SPECmail, but this figure doesn't seem too outstanding to me.

Firstly I assume this is just a raw delivery setup - no spam or virus filtering. You'd be amazed how much of a difference this makes to any real world setup.

Secondly, apache.org does over 2 million mails a day on a dual 2.4Ghz Xeon using an SMTP server written in Perl. And that's with full anti-virus (clamav) and lots of different anti-spam measures including SpamAssassin (which is known to be slow - I know because I used to be one of the developers).

I also know of commercial setups doing over 50m (legit, well - mostly) mails a day. Using an SMTP Server designed with performance in mind. Perhaps they should submit for SPECmail ;-)

So 30 million doesn't seem terribly amazing to me. Perhaps Communigate Pro isn't a very fast mail server.

Differences between the two lists and more topics about our project are described on the SURBL site. If anyone has a question or comment about SURBL you can write to me directly at jeffc at surbl dot org, or much better ask the growing SURBL community on our discussion list. The separate announcement list is a good way to keep up with news about the project. Archives of the lists are available on the list site.

Folks who have tried SURBL have generally been pleased with the results, and we expect to improve the ~60% spam detection rate and lower the already low (<0.1%) false positive rate further in the next version of the data engine behind sc.surbl.org. As has been previously mentioned, Devin Carraway has written an MTA use of SURBL domain data to check message body URIs in his qpsmtpd plugin called uribl. This is the first MTA use for SURBL that I've heard of, though I don't necessarily claim to have heard of all uses of SURBL so far. Some other folks are thinking about implementing a sendmail milter for which will probably use sc.surbl.org since they are also a major ISP source of SpamCop's data.

Since I probably won't be posting here too often, I'd like to thank some of the people who have been quietly very supportive and responsible for the success of this effort so far including Eric Kolve, Justin Mason, Daniel Quinlan, Raymond Dijkxhoorn, Julian Haight, Kelsey Cummings and others who already know how greatly they have helped to make SURBL possible.

One thing we could use some help with now are more BIND-compatible secondary DNS servers and rsynced rbldnsd servers. Please see the SURBL site for details, and lend a hand if you can. DNS traffic may get kind of heavy when SA 3.0 comes out since it has SURBL support in URIDNSBL (URIBL), so we definitely need some help with name service.

While I'm not totally sold on the idea, it seemed to have enough promise to be worth trying. So here's a plugin to qpsmtpd, a replacement smtpd for qmail (it also delivers to postfix, IIRC). Implements most of the basic suggestions in SURBL's proposal.

(I'd like to be able to slap a bell and yell "first implementation!" in a childish slashdot fashion, but I'd be surprised if this really was the first, since it's easy to do a simple implementation and parallels similar DNSBLs in some respects.)

qmail is quite modular. If you really need your smtpd to do spam filtering, you can always replace qmail-smtpd with qpsmtpd, and plug it into spam assassin. Legendary qmail reliability/security/etc, except with the smtpd part written in... perl. Ok, maybe it sounds crazy, but I think it's still better than send*cough*remoteroot*cough*mail.

Personally, I run qmail (with the standard smtpd, not that perl one) on the mail server, and postfix on the mac laptop. Works for me. ;; nonyn

Yup, code reviews are fraught with pitfalls.

Here's another scenario: you write a class, it gets reviewed by someone and they suggest you use a Factory pattern. You rewrite it to use Factory, and then it gets reviewed by someone else and they say "why are you adding in that Factory pattern? that just makes it more complicated to use - you're over abstracting!". Both reviewers are right in a way... it all depends on how the class is being used.

There's a nice discussion of alternatives to code reviews here.

tom

[Disclaimer: I work in AV]

If cost is even slightly an issue, I can recommend using qpsmtpd and clamav. The clamav team are pretty fast at adding new virus signatures to their database, and they catch most of the common viruses out there. I've written a qpsmtpd plugin for clamav which you can find here.

I can't honestly recommend Sophos for gateway scanning. They are better on the desktop. If you can I would go for NAI who have the best gateway scanning of the commercially available scanners (according to our live tests).

Alternatively, if a 100% guarantee appeals to you, the company I work for, MessageLabs will give you a 100% guarantee against letting through an email virus. We'll also do spam scanning for you. Yes, I'm biased.

no calling conventions yet for subroutines. There is no hope of offering mixed language support unless they do this.

no conversion opcodes for various builtin types (float, char, short, int)

non-perl languages expected to provide additional support in the form of C code libraries for their opcodes. This would nix any hope of having a single standard universal virtual machine.

no way to call out to C code

no equivalent of Java's jar file or CLR's assemblies for parrot library distribution

way too many registers: their register based VM (32 int registers, 32 double registers, 32 string registers, 32 PMC registers plus various stacks) requires a sophisticated compiler to do proper register allocation and needlessly complicates their VM.

no consideration of threads in their design. How will they handle synchronization, for example?

The points above are not coding issues, but issues of design. It seems that Parrot is too hung up on making the VM efficient and are not seeing the bigger picture - to get the features in place first so that high-level languages can work. Or perhaps they should simply concentrate on getting Perl6 to work first. They need more focus. The project tries to be all things to all people, but ends up satisfiying no one.

Yeah I don't think it's a troll as it seems to be coming from reliable sources. Apparently his family sent an email to the faculty at cs.utexas.edu which has been forwarded around. I would imagine it would show up in the news within a day. Here's a link to the email, on the perl5-porters list.

Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.

That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:

• maco sx@perl.org archive
• perl5-porters@perl.org
• fink -devel@lists.sourceforge.net

This is caused by fink setting PERL5LIB to /sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.

At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.

The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.

I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.

Thank you!

Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.

That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:

• maco sx@perl.org archive
• perl5-porters@perl.org
• fink -devel@lists.sourceforge.net

This is caused by fink setting PERL5LIB to /sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.

At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.

The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.

I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.

Thank you!

Thank you for your post. First, I'd like to say that I hoping you are who you claim to be. The fact that you're posting as an AC, and that google doesn't know about you, and that you're not listed as a fink developer at the fink project member list, and that no reference of you exists at the fink-devel archive gives me pause. Appologies if my skepticism turns out to be unwarranted. For the sake of this response, I will assume that you are not trolling and are who you claim to be.

That being the case, I'm afraid you've been misled by the comment that you initially responded to. That comment was posted by someone who extracted out a small section of a report that I sent to various mailing lists last night. The comment to which you responded has effectively deprived you of the relevant context surrounding the issue. My full report can be found at the archives for the three lists I sent it to:

• maco sx@perl.org archive
• perl5-porters@perl.org
• fink -devel@lists.sourceforge.net

This is caused by fink setting PERL5LIB to /sw/lib/perl5 which contains one or more compiled XS modules. Since perl 5.8.0 is not binary compatible with any prior perl release all XS modules will have to be recompiled in order to not experience the show-stopping dyld issue.

At this moment in time there have been several replies. One was a reply from Max Horn, a senior developer at fink. And, another reply was a reply from Michael Schwern, quality assurance manager for perl. Both acknowledge this as an issue and further outline the cause of this as well as possible permanent solutions.

The steps outlined in the 'RESOLUTION' section of the report are sane and well tested. They do indeed correct the issue that the report details, and should absolutely not cause any peripheral problems.

I'd like to request that if you further reply, please also do so on one of the three lists mentioned above so we can keep everyone in the loop.

Thank you!

If you could write and use a Perl 6 program right now, maybe he'd include a chapter on it in his book.

heh.

If you want to validate perl 6 code, you might want to check out:

http://archive.develooper.com/perl6-language%40per l.org/msg10223.html

--
ralph

Check out the Mac OSX Perl board at:

Here and specifically Here

This has been discussed on Permonks

You can also read the discussion that led to this here

tstock

jbennetto, your little friends are wrong. They have been affected by the skepticism of a skeptical age. They do not believe except they see. They think that nothing can be which is not comprehensible by their little minds. All minds, jbennetto, whether they be men's or children's, are little. In this great universe of ours, man is a mere insect, an ant, in his intellect as compared with the boundless world about him, as measured by the intelligence capable of grasping the whole of truth and knowledge.
Whatever, I thought it was funny.

• It predates "modern" Unix shells by a decade and Unix itself by at least 5 years.
• BASIC used $ to indicate string variables (LET A$="HELLO") and the lack of a type indicator to mean a number.

Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.

Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?

• IV (integer)
• NV (floating-point)
• STRING (encoding-independent string)
• PMC (Parrot Magic Cookie)

Vtable Datatypes

The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say

inc P1

to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.

PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.

[ read more ]

• Apocalypse 2
  • Built-in Data Types
  • Variables
  • Properties
• Exegesis 2

• Apocalype 1
• Apocalypse 2
• Exegesis 2
• Apocalypse 3
• Exegesis 3
• Apocalypse 4

• perl6-language at perl.org
• perl6-internals at perl.org

It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.

It's a well known fact, even among Perl advocates, that the vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean code in Perl, but the language certainly doesn't encourage it.

Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today. But what I'm really looking forward to is Parrot, i.e. the virtual machine for Perl 6 and, I hope, also for Python, Ruby, Tcl and maybe few other good languages. It's a VM and a low-level assembly language for that VM - the language, to which Perl 6 (and hopefully other high-level languages) will be compiled to (as a layer between Perl and the VM bytecode) like C is compiled to machine-specific Assembbler (between C and the machine code). See the examples of Parrot use and read Parrot: Some Assembly Required to see what it is. Also the perl6-internals at perl.org mailing list archives is a good place to start. I'd love to see Perl and Python playing nice together, thanks to Parrot. It'd be really cool if I could write a program in Perl with someone who writes his part in Python, and another one writing in Ruby. I would just use their classes and objects, they would just use mine as well, without worrying about the language of our implementation. Parrot can be the answer here. Would it be the end of language flame wars? I do hope so.

I won't give them a dime until they put more effort into being a bit nicer to people who need help.

Personally, I've found them to be extremely helpful and a great resource. I've also seen them be downright nasty and arrogant towards people they perceive to be less than "elite".

I know there's been some effort to do that in the past, however it seems to have died out from a public image point of view.

/prakash

I won't give them a dime until they put more effort into being a bit nicer to people who need help.

Personally, I've found them to be extremely helpful and a great resource. I've also seen them be downright nasty and arrogant towards people they perceive to be less than "elite".

I know there's been some effort to do that in the past, however it seems to have died out from a public image point of view.

/prakash

Anyone who wanders into the use of Perl for bioinformatics ought to consider the ultimate plunge into the use of Perl for neuroscientific Artificial Intelligence. Since v.t.y. Mentifex here has been coding the AI Brain-Mind in JavaScript for tutorial purposes and also in Forth for Intelligent Mind Roboinformatics, the switch-over to Perl is advancing so slowly that I must first promulgate some candidate AI module proposals for inclusion among the object-oriented Perl 5 Module List.

The Comprehensive Perl Archive Network (CPAN) contains some not-yet-implemented, suggested AI module namespaces for those who read the Beginning Perl book reviewed here on SlashDot and who may then wish to do some really exciting, wave-of-the-future Perl neuroscience theory and practice work.

• it jeopardy quoted by default, and there was no way to override this setting
• it posted as HTML by default, and the only thing you could configure was which font you want to use, not "whether or not there is a defined font in the first place"

Etc. I tried to fight this by cutting & pasting my messages so that they'd be top-quoted -- The Way The Good Lord Intended -- but it was much too much of a pain in the ass, and being the only one in the company doing it just made me look funny. Likewise my selection of a monospace font -- it was like tilting at windmills.

Yes, it's sad that not everyone has been brought into the culture in such a way that old netiquette would be honored, but that's just how it works when a subculture gets promoted to the mainstream. Yes, Microsoft could have made it easier to configure Outlook -- and to be fair, Outlook Express *is* a nice email client on the Mac (I just wasn't allowed to use it), and newer versions than this one ('98?) might be more flexible) -- and there's really no defence for their wholesale scuttling of all but their way of quoting messages. But what's done is done: as long as I can keep using Pine or Mutt, and read most of the mail coming to me, I'm not going to lose any sleep over it. Times have moved on...

If you're interested in Parrot, get the version from cvs, and get on the mailing list. There's a hell of a lot of interesting and cool stuff thats gone in since 0.0.3, not least of which is JIT on a few platforms (linux among them). Just check out the mailing list for details.

Oh, and if you run an unusual system, then get in contact with the parrot team! They need more exotic systems to get parrot building on!/p

without dan perl 6 just won't be the same.

There's been work to get similar things for the kernel, as well.

I'd personally be a little scared of testing kernel functions, but I've tested a lot of so-called "untestable" things lately. It's worth doing.

On the other hand, we are also told:

Did you notice that cunning $a == $b != NaN test in operator:EQ? This lovely Perl 6 idiom solves the problem of numerical comparisons between non-numeric strings.

which may be cunning, except of course with wow neat multiway comparisons it is equivalent to ($a == $b) && ($b != NaN), which doesn't do the advertised job.

Actually, it does, as Damian pointed out to me when I asked about it earlier today.

On the other hand, we are also told:

Did you notice that cunning $a == $b != NaN test in operator:EQ? This lovely Perl 6 idiom solves the problem of numerical comparisons between non-numeric strings.

which may be cunning, except of course with wow neat multiway comparisons it is equivalent to ($a == $b) && ($b != NaN), which doesn't do the advertised job.

Actually, it does, as Damian pointed out to me when I asked about it earlier today.

Well I suppose now somebody is going to have to update the Quantum modules so they use this stuff :)

if (any(@value) is very useful, but the inclusion into Perl 6 is (AFAIK) currently under RFC . The thought of quantum Perl on a quantum computer makes me feel all tingley...

-- Dooferlad