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.
Email::EnvelopeVery 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::AMPRightio... 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 MTAYES! 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/
Re:Perl Mail Server
kungfuftr on 2004-12-23T15:10:52
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.)
Re:Perl Mail Server
ask on 2005-01-02T14:17:20
How so? What are you missing?Re:Perl Mail Server
kungfuftr on 2005-01-02T16:33:46
mainly callback mechanisms, hard to explain without code to show... i'll show you at a latter point. But just trust me on this one.
Re:Perl Mail Server
kungfuftr on 2004-12-23T17:00:01
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.
