Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

kungfuftr (5129)

  (email not shown publicly)

Um... I'm Scott apparently... FreeBSD, Perl, Mozilla and hopefully some xlib.

Journal of kungfuftr (5129)

Thursday December 23, 2004
07:00 AM

Perl Email Project?

[ #22428 ]

I've been taking a great intrest of late in the Perl Email Project due to the fact that I'm rather paranoid in terms of my MTA setup and I've also done a few things for a mates company using a few of the modules from PEP. However, getting my MTA to work in a fashion that I want is becoming tedious and the size of my exim config keeps growing and growing. While exim is very nice and very configurable, the string expansion doesn't really allow for very strange configuration like I want. I know there's direct perl abilities, but it's still within the constraints of string expansion. So, I'm currently working on the following options.


Very simple module, basically, while Email::Simple deals with E-mails and their contents in an effective manner, it doesn't deal with information from the E-mail from SMTP time. So basically, it's just another simple wrapper that has lots of information about an e-mail and how it has been sent, and you can pull an Email::Simple object out of it as well as Email::Address objects (i think). This will come in very useful for the next module...

Email::Pipeline / Email::AMP

Rightio... more complex one this. The concept is that an Email::Envelope will get dropped into a pipe and each segment along the pipe will study the object and decide if it wants to perform actions on it. It can then drop out of the pipe with some other information such as rejection scores, quarantine, etc. The idea will be to make the system extremely flexible and pluggable.

So, this is funky and gives a lot of flexibility, probably more so than Email::Filter, however there's one big problem with using Email::(Pipeline/AMP) as a .procmail/.qmail style script. The MTA will still need to accept the whole e-mail including DATA before it can ever reach the pipeline script... which sucks, cos i want to save on my bandwidth... so..

Perl MTA

YES! I'm crazy, i want to write an ESMTP server just for use with my pipeline stuff. There's good reason for this though, and it's this... it's far more flexible than an MTA written in C!

Since there are no current prototypes, I'm going to blame Marty Pauley as I'm going to be going from a test first development approach. So, I promise that all of these modules will have a through testsuite and be extremely well documented. I will also be passing the distributions off to simon wistow and casey west before uploading to PAUSE, so that I can check that documentation and API suits the style of the PEP.

One last thing, I wish to thank my employer for giving their support for me to work on this project, though not on work time... =0/

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Check out qpsmtpd.
    • I've already seen it, unfortunately it wouldn't give the flexibility needed for each stage that the mail goes through for use with the pipeline. (ie: ACL,DATA,ROUTE,TRANSPORT,DELIVERY, etc.)

      -Scott McWhirter- | -kungfuftr-
      "JAWK - Just Another Whiny Kid"
  • Check out POEST. Also, the somewhat ancient Net::SMTP::Server. Also, Net::Server::Mail.
    • I have looked at all the perl SMTP server possibilities, but none of them have the flexibility i'd need. None of them have callbacks or hooks for doing things at certain times of the process loop. I'm not trying to reinvent the wheel here... it's just that this particular wheel has a few spokes missing.

      -Scott McWhirter- | -kungfuftr-
      "JAWK - Just Another Whiny Kid"