perl.pep

perl.pep http://www.nntp.perl.org/group/perl.pep/ ... Copyright 1998-2008 perl.org Wed, 20 Aug 2008 18:44:52 +0000 ask@perl.org Email::Simple::Creator CRLF handling broken (1 message) Email::Simple::Creator seems to be putting too many newlines into my emails. I can get the desired behaviour by changing the return value of _crlf() in Creator.pm. It comes from CPAN set to "\x0d\x0a", but it works better for me if it's "\x0a". I use Perl v5.8.8 and Email::Simple::Creator v1.424. I also use a Qmail as MTA. OS is Linux. Here is my test code: #!/usr/bin/perl use Email::Simple; use Email::Simple::Creator; use IO::File; my $somefh = new IO::File; $email_obj = Email::Simple->create( header => [ From => "someone@someone.com", To => 'se456@rohan.id.au', Subject => 'This is a subject' ], body => "This is the body" ); open $somefh,"|/var/qmail/bin/qmail-inject"; print $somefh $email_obj->as_string(); close $somefh; # -------------------------- Here is the result in Mozilla Thunderbird (Windows) when Creator.ph has "\x0d\x0a": > From - Sat Jul 12 19:19:14 2008 > X-Account-Key: account2 > X-UIDL: 1215861550.14312.ambassador.digitalinscription.com > X-Mozilla-Status: 0001 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: > Received: (qmail 14307 invoked by uid 501); 12 Jul 2008 11:19:10 -0000 > Message-ID: <20080712111910.14306.qmail@ambassador.digitalinscription.com> > From: someone.com@ambassador.digitalinscription.com > To: se456@rohan.id.au > Subject: This is a subject > > Date: Sat, 12 Jul 2008 19:19:10 +0800 > > > > > This is the body Here is the result in Mozilla Thunderbird (Windows) when Creator.pm has "\x0a": > From - Sat Jul 12 19:17:58 2008 > X-Account-Key: account2 > X-UIDL: 1215861477.14298.ambassador.digitalinscription.com > X-Mozilla-Status: 0001 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: > Received: (qmail 14293 invoked by uid 501); 12 Jul 2008 11:17:57 -0000 > Message-ID: <20080712111757.14292.qmail@ambassador.digitalinscription.com> > From: someone.com@ambassador.digitalinscription.com > To: se456@rohan.id.au > Subject: This is a subject > Date: Sat, 12 Jul 2008 19:17:57 +0800 > > This is the body BTW I censored some of the headers above. I also checked in Outlook Express 6. -- Rohan Carly http://www.nntp.perl.org/group/perl.pep/2008/07/msg339.html Sat, 12 Jul 2008 04:27:58 +0000 new module: Email::Address::Loose/Email::Address::JP::Mobile (1 message) Hi I'm going to upload 2 modules to CPAN. 1. Email::Address::Loose http://coderepos.org/share/browser/lang/perl/Email-Address-Loose/trunk This module provides "loose parse()" like Email::Valid::Loose. and, it has a "override Email::Adddrss::parse" option. The mobile carrier in Japan supply a RFC-invalid account address. They do not improve this specification still now. (e.g. foo..bar..@example.com) So, I think that Email::Address::Loose helps a Japanese web developer. 2. Email::Address::JP::Mobile http://coderepos.org/share/browser/lang/perl/Email-Address-JP-Mobile/trunk Japanese has a various encoding, but encoding that can be used by MUA on cellular phone of Japan is limited. e.g. SoftBank cellphone: iso-2022-jp, utf-8, variant utf-8 (Encode::JP::Mobile support as x-utf8-softbank) DoCoMo cellphone: iso-2022-jp, Shift_JIS, variant Shift_JIS (Encode::JP::Mobile support as x-sjis-docomo) Then, I wrote Email::Address::JP::Mobile that extends Email::Addrss object. Any advices and patches are welcome. # that is used only by Japanese, though. thanks -- Tomita <n.tomita@gmail.com> http://e8y.net/ http://search.cpan.org/~tomita/ http://www.nntp.perl.org/group/perl.pep/2008/06/msg337.html Sat, 28 Jun 2008 19:27:49 +0000 I hate Unicode (3 messages) (Dangitall, if 7-bit ASCII was good enough for Fidonet, it ought to be good enough for email. Kids these days.) I'm getting this when I try to retrieve $SomeEmailMimeMessage->header('subject'): Unknown encoding "X-UNKNOWN" at /usr/lib/perl/5.8/Encode.pm line 166 A fair cop, the subject line *does* go all "=?X-UNKNOWN?Q?Re=3A_" and some junk. In weird cases like this I just want to preserve it as is, so I go to Encode to see how best to tell it to ignore crazy talk. Hmm. Encode's POD sez ignoring it is default behavior already. But it also sez, it sez: "Some encodings ignore CHECK argument. For example, Encode::Unicode ignores CHECK and it always croaks on error." Well, crud. But here's the funky thing, that I'm not quite getting: it's not happening when I *create* $SomeEmailMimeMessage. I could deal with that. It's happening when I *look* at that header. Why is that, and how can I trap it (or ideally, detect it when I first load up the message)? Or should I not be handing Email::MIME something that's gone through encode('unicode', $mailstring) at all? It's mail that was improperly stored in an SQL-ASCII database, and is going into a UNICODE database, so it's a one-time conversion utility on what may well be lightly-fried data. If this is something that's never going to come up on fresh mail, I can code for the finite number of exceptions in this database. http://www.nntp.perl.org/group/perl.pep/2008/06/msg332.html Thu, 26 Jun 2008 12:38:30 +0000 bug in MIME::Entity make_singlepart (5 messages) I thought I'd cc the list since this is sort of a weird, fun bug. Sometimes, when collapsing a message into single part, the C-T is horked up. It starts as: Content-Type: multipart/related; boundary=xyzzy; type=foo ...and ends as: Content-Type: text/plain; boundary=xyzzy; type=foo Erk! Boundary? Type? What? Demonstration attached. -- rjbs http://www.nntp.perl.org/group/perl.pep/2008/06/msg330.html Thu, 26 Jun 2008 10:37:23 +0000 parse out the email body (5 messages) Hi, I want to be able to read a MIME encoded email file (Thunderbird) and have a way of returning just the VIEWABLE body part. I tried Email::Simple but I get all the MIME encoding and both the TEXT and the HTML parts. I tried Mail::Internet but then besides everything that Email::Simple gives I also get all the header data as part of the body. and I tried Email::MIME but as per the documentation all I got then was "This is a multi-part message in MIME format." I'm not sure how that is the BODY, but its not the VIEWABLE BODY that I was looking for. Any help? my $obj = Mail::Internet->new([ /\n/, $message ] ); my $body = $obj->body; print @$body,"\n"; That returned the entire email, headers and everything, so much for getting the body. my $email = Email::Simple->new($message); my $old_body = $email->body; print "Body: $old_body\n"; This is a bit better at least it removed the headers but still leaves in all the MIME and stuff. eg. ------=_NextPart_000_016D_01C8C0EF.6816A390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = Thanks. http://www.nntp.perl.org/group/perl.pep/2008/06/msg325.html Wed, 25 Jun 2008 01:43:58 +0000 ANNOUNCE: Dada Mail 3.0 Released (1 message) Thought people may be interested in this - this is the first Major (2 - > 3) release of the program since 2000. Not to say I've been lollygagging for that long or anythin' Download Dada Mail: http://dadamailproject.com/download Dada Mail is a Free Download. We suggest upgrading any version of Dada Mail created to Dada Mail 3. For a quick tour of the new features: http://dadamailproject.com/features/3_0/ :: What is Dada Mail? Dada Mail is a completely contemporary, mature and intuitive web-based e-mail list management system, which runs on most any Unix-like hosting account that can run custom CGI scripts. Dada Mail is also a conceptual art project. Dada Mail handles Closed-Loop Opt-in/Opt-out subscriptions, sending complex announce-only and/or discussion mailing list messages with an advanced, fault-tolerant mass mailing monitor, supports the archiving/ viewing/searching/resending/syndicating (rss, atom) of sent messages and doing all this and a whole lot more with style. Dada Mail can handle custom subscriber fields and you can use the information it captures for partial list sending based on a query and Dada Mail's email templating system allows you to create targeted and completely custom email messages for each and every one one of your subscribers. Dada Mail is bundled with additional plugins and extensions to extend Dada Mail's capabilities. Some of the plugins/extensions support advanced bounce handling, click-through tracking, mass mail scheduling, blog interfaces of archived messages, AJAX subscription form trickery and lots of other surprises. Dada Mail produces XHTML valid web content and sticks to best practices when creating email messages. Write Once: Distribute Everywhere. Dada Mail is free software that you're able to use, modify, share and enhance under the terms of the GNU General Public License. Dada Mail is written in Perl because we love Perl. :: The Dada Mail Demo Want to play around with the program before downloading? Try our demo: http://demo.dadamailproject.com :: Installation Instructions: http://dadamailproject.com/installation/ :: Docs: http://dadamailproject.com/support/documentation :: Change Log: http://dadamailproject.com/support/documentation-dada-3_0_0/changes.pod.html Cheers, Justin http://dadamailproject.com http://www.nntp.perl.org/group/perl.pep/2008/06/msg324.html Wed, 25 Jun 2008 01:33:06 +0000 help getting email body (4 messages) Hi, I want to be able to read a MIME encoded email file (Thunderbird) and have a way of returning just the VIEWABLE body part. I tried Email::Simple but I get all the MIME encoding and both the TEXT and the HTML parts. I tried Mail::Internet but then besides everything that Email::Simple gives I also get all the header data as part of the body. and I tried Email::MIME but as per the documentation all I got then was "This is a multi-part message in MIME format." I'm not sure how that is the BODY, but its not the VIEWABLE BODY that I was looking for. Any help? my $obj = Mail::Internet->new([ /\n/, $message ] ); my $body = $obj->body; print @$body,"\n"; That returned the entire email, headers and everything, so much for getting the body. my $email = Email::Simple->new($message); my $old_body = $email->body; print "Body: $old_body\n"; This is a bit better at least it removed the headers but still leaves in all the MIME and stuff. eg. ------=_NextPart_000_016D_01C8C0EF.6816A390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40" <http://www.w3.org/TR/REC-html40>> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = Thanks. http://www.nntp.perl.org/group/perl.pep/2008/06/msg320.html Tue, 24 Jun 2008 20:19:48 +0000 new server: some organizational questions: (2 messages) For boring reasons, I'm moving emailproject.perl.org to a new box. My plan is to just port over the existing Subversion repository and MediaWiki. If you want to demand major changes, this is the time to do it. -- rjbs http://www.nntp.perl.org/group/perl.pep/2008/06/msg319.html Tue, 24 Jun 2008 18:29:48 +0000 Problem with attachment, 1 becomes 10 (7 messages) Hi, I'm new to this list. I'm trying to write a program that can send out mails to companies where I'm interested in working. These mails are the same except that the company name is switched. My CV should be attached as a pdf-file. The problem is that I don't get one attachment, but ten! Also the message is repeated 10 times. If I change the program by uncommenting the commented line in the function load it works but then it doesn't send the correct pdf-file. The CV is 129490 bytes. How could I change this program so that there is only one attachment and no repeated messages? In the program below some long lines might have been splitted. #!/usr/bin/perl # jobapplier.pl vN/A (Buggy!) # Author: Mikael O. Bonnier, mikaelb@df.lth.se, http://www.df.lth.se/~mikaelb/ # Copyright (C) 2008 by Mikael O. Bonnier, Lund, Sweden. # License: GNU GPL v3 or later, http://www.gnu.org/licenses/gpl-3.0.txt use strict; use Email::Send; use Email::Simple::Creator; use Email::MIME::Modifier; use DBI; use MIME::Words qw/encode_mimewords/; use File::stat; my %settings = ( SMTP => 'mail.df.lth.se', PORT => 588, FROM_DOMAIN => 'cust.bredbandsbolaget.se', DB => 'jobapplier_test', DB_HOST => 'localhost', FROM => 'mikaelb@df.lth.se', SUBJECT => 'Intresseanmälan som fysiker eller programutvecklare', BODY => 'Det skulle vara intressant att jobba hos er på $cCompany.', UPLDDIR => '../Documents/LyX', FILE => 'MOB_CV.pdf', ); @ARGV == 4 or die 'Provide username and password for the SMTP and the MySQL server, respectively,' . " on the command line.\n"; @settings{qw( USER PASS DB_USER DB_PASS)} = @ARGV; my $dbh = DBI->connect( "DBI:mysql:$settings{DB}:$settings{DB_HOST}", $settings{DB_USER}, $settings{DB_PASS} ); my $q = q|select cCompany, cEmail from Contacts order by cId asc|; my $sth = $dbh->prepare($q); $sth->execute; my $as = []; while ( my $hr = $sth->fetchrow_hashref ) { push @{$as}, $hr; } $dbh->disconnect; my $mailer = Email::Send->new( { mailer => 'SMTP::TLS', mailer_args => [ Host => $settings{SMTP}, Port => $settings{PORT}, User => $settings{USER}, Password => $settings{PASS}, Hello => $settings{FROM_DOMAIN}, ] } ); for my $row (@$as) { my $body_text = $settings{BODY}; $body_text =~ s/\$cCompany/$row->{cCompany}/g; my $email = Email::Simple->create( header => [ From => $settings{FROM}, To => $row->{cEmail}, Subject => encode_mimewords( $settings{SUBJECT} ), 'Content-Type' => 'text/plain; charset="utf-8"', ], body => $body_text, ); my $body = load( $settings{UPLDDIR}, $settings{FILE} ); my $part = Email::MIME->new(''); $part->body_set($body); $part->disposition_set('attachment'); $part->name_set( $settings{FILE} ); # Both needed? $part->filename_set( $settings{FILE} ); # Both needed? $part->encoding_set('base64'); $part->content_type_set('application/octet-stream'); my @more_parts = ($part); $email = Email::MIME->new( $email->as_string ); $email->parts_add( \@more_parts ); eval { $mailer->send($email) }; die "Error sending email: $@" if $@; } sub load { my ( $upldDir, $inFile ) = @_; my $DNLDFILE; open $DNLDFILE, '<', "$upldDir/$inFile"; binmode $DNLDFILE; my $st = stat $DNLDFILE; my $content; read $DNLDFILE, $content, $st->size; close $DNLDFILE; # $content = 'ABC'; return $content; } __END__ Regards, // Mikael Bonnier ---- // Web: http://www.df.lth.se/~mikaelb/ // E-mail/MSN: mikaelb@df.lth.se // ICQ # 114635318 // Mob/SMS/MMS: +46730307498 // Phone: +4646323208 // Skype: mikael4u http://www.nntp.perl.org/group/perl.pep/2008/05/msg312.html Sun, 04 May 2008 17:50:03 +0000 Announcement: Net::Server::Mail::ESMTP::SIZE (1 message) Hi, Another announcement. Just released to CPAN Net::Server::Mail::ESMTP::SIZE. I've commented a bit more on: http://www.pplusdomain.net/cgi-bin/blosxom.cgi Cheers, Jose Luis Martinez jlmartinez@capside.com CAPSiDE http://www.nntp.perl.org/group/perl.pep/2008/04/msg311.html Wed, 30 Apr 2008 18:04:29 +0000 Announcement Test::SMTP module released (2 messages) Hi, I released a week ago Test::SMTP. This module is a helper for writing tests for SMTP servers. I basically announced it on the qpsmtpd list, but I've just found this list, so I'm reannouncing: --- More info on it on http://www.pplusdomain.net/cgi-bin/blosxom.cgi Just wanted to apport this testing framework so the quality of qpsmtp can go up, as automated tests are easier to write, plugin behaviour can be fully tested, and broken functionalities because of changes to the core can be predicted. Please give me your two cents on the module, and if it's lacking something, or would like something more on it. --- Please, don't doubt in critisizing the module. Jose Luis Martinez CAPSiDE jlmartinez@capside.com http://www.nntp.perl.org/group/perl.pep/2008/04/msg309.html Mon, 28 Apr 2008 13:16:09 +0000 validating email addresses (4 messages) Hello, I use Email::Valid to check the syntax and MX record. I'm wondering if there is any best practice for the next steps: - verify the existence of the mailbox - send an email requiring a reply Is either technique worth doing? Is there a module that helps? Or perhaps it is better to use a captcha instead/as well. Any pointers to code or discussions would be helpful. I haven't found much by searching. Thanks, Dave http://www.nntp.perl.org/group/perl.pep/2008/04/msg305.html Thu, 17 Apr 2008 02:43:22 +0000 Developer release of Email::VirusScan (3 messages) As the next step on the road to cleaning up the mimedefang.pl code, I've factored the virus scanner integration out into a separate set of modules -- Email::VirusScan. The modules are now available as a developer release on CPAN, available from http://search.cpan.org/dist/Email-VirusScan/ The virus scanning engines supported are all of those supported by MIMEDefang, with the exception of two or three that I didn't bother converting as they appeared to be entirely obsolete. In a future release of MIMEDefang, this virus scanner code will replace the current virus scanner methods in mimedefang.pl. The immediate benefit will be the removal of about 2k lines of virus scanner code in favour of loading only the necessary modules. This should save a couple hundred kb of memory per scanning slave. In the long term, being able to validate and test virus scanner plugins outside of MIMEDefang should be a big win. But first, before it gets integrated into MIMEDefang, it needs testing. The ClamAV::Clamscan and ClamAV::Daemon modules are relatively well tested, but the modules for scanners I don't have access to are almost entirely untested. I would appreciate it if anyone using one of the supported virus engines would download this code, try it out, and provide feedback. Patches and bug reports can be sent to the list or to me directly. Alternatively, if you are willing to provide me with shell access on a system with one of the supported scanners, I will run the tests and make any necessary fixes. Cheers, Dave -- Dave O'Neill <dmo@roaringpenguin.com> Roaring Penguin Software Inc. +1 (613) 231-6599 http://www.roaringpenguin.com/ For CanIt technical support, please mail: support@roaringpenguin.com http://www.nntp.perl.org/group/perl.pep/2008/04/msg302.html Thu, 10 Apr 2008 11:16:45 +0000 Announcement: Email::Builder (1 message) Hello! I'd like to announce a new stable version of the Mail-Builder module at CPAN. The module facilitates the creation of e-mail messages with attachments, inline images and html content. A short example how the module works: use Mail::Builder; my $mail = Mail::Builder->new(); $mail->from('mightypirate@meele-island.mq','Guybrush Threepwood'); $mail->to('manuel.calavera@dod.mx','Manuel Calavera'); $mail->cc->add('meche@lod.mx','Mercedes Colomar'); $mail->cc->add('glotis@dod.mx'); # To,CC and BCC fields (as well as attachments and images) are handled as list objects. There are several utility methods to work with these lists (add new item, remove item, serialize, find, ...) $mail->subject('Party at Sam\'s place'); # The module has accessors for subject lines, priority, language, sender organisation, charset, ... $mail->htmltext('<h1>Party invitation</h1> ... <img src="cid:logo"/> '); # Mail-Builder automatically converts HTML code to plaintext with pseudo markup if you don't provide it yourself $mail->attachment->add('direction_samandmax.pdf'); # Mail-Builder tries to guess the correct mime type if you don't provide it yourself. $mail->image->add('logo.gif'); print $mail->stringify; Mail-Builder uses modules like Email::MessageID, MIME::Tools and MIME::Types and works well with Email::Send. I'd be glad about hearing feedback from you. Cheers Maros http://www.nntp.perl.org/group/perl.pep/2008/02/msg296.html Fri, 22 Feb 2008 06:22:19 +0000 Email::Classifier (13 messages) Hi! I have looked at Mail::DeliveryStatus::BounceParser and I needed to use it in combination with Mail::IMAPClient and IMAP::BodyStructure. The MD::BounceParser seemed to bee a bit disorganized and had seems to have the assumption that you only would want to use it for finding out email-addresses to remove from send-lists. I was looking for something to get a lot of information from any email message, for the purpose of updating a CRM database. For that, it would be interesting to analyze vacation messages, attached v cards and more. I also want to catch all automated emails and do the right thing with them, in updating the CRM database, or mark an entry for followup. Therefore, it should catch anything that doesn't have to be manually handled by a human. The rest of the email should be sorted into the right "Request Tracker" queue. I'm using IMAP because I think that it's more fault tolerant. If a process dies or misbehaves, you can still find the original messages on the IMAP server, using a regular IMAP client. And since the Emails are administrated, in relationship with customer and project information, through a web interface, I think it's important to NOT download all those big attachments that are sent around all the time. All the email handling can be done without having to download, read into memory, or parse the parts of the message not relevant for sorting. I looked around a bit, and found some commonly used terms in regard of email bounce handling. I think it would be nice to introduce the classification of a bounce message in the categories of hard soft transient Depending of what you want to do, you will treat these cases differently. A hard bounce is a response that the mailbox no longer exist. A soft bounce is a mailbox over quota or some other thing that may not be a permanent condition, but could be. A transient bounce is just a status report and not a failure. But I still want to catch those transient error messages. They should certainly not go into the request queue, but they should still be parsed and used to update the status of the original email and receiving user. This can be done then there is a custom built web interface for the email handling. Anyway... I have set up Email::Classifier. I just took all the code of MD::BounceParser and converted it. It uses modules that loads on demand. Most of the code ended up in the Email::Classifier::Bounce module, that still needs a lot of cleaning up. The Email::Classifier::Bounce module, in turn, loads it's own plugin modules for handing different types of bounces. For now, I created Email::Classifier::Bounce::AOL_Senderblock. A lot of MD::Bounceparser code has been cleaned up, corrected and simplified. But there are bits not yet converted. Still, it passes all the original tests from MD::Bounceparser And here is the package: http://jonas.liljegren.org/perl/dist/Email-Classifier-0.01.tar.gz -- / Jonas - http://paranormal.se/Jonas_Liljegren.html http://www.nntp.perl.org/group/perl.pep/2008/02/msg288.html Sun, 17 Feb 2008 16:50:58 +0000 IMAP and message modification (2 messages) ! Email:: directly but the third step in my quest. I've read (most of) the IMAP RFCs and searched and looked at many of the CPAN modules that deal with IMAP but I'm having no success finding what I'm looking for. I'm probably using the wrong terminology. Is is possible to have an IMAP client modify or add a header to a message on the server? This is part of a reporting system and once a message has been reported I don't want it to be reported again. Currently I have direct access to the files on the (MS Windows) mail server and use Mail::Box and friends but appear to be running into into share or network issues. I'd like to make this reporting a little more generic and IMAP access seems like the way to go. May not help network issues but it should future proof if the email software vendor decides to change their file format. So I'll start here as I've been using several Email modules to test IMAP access to collect and report messages. Is the something in the IMAP protocol to modify message headers? Is it accessible via any of the Email modules? Thanks, Rod -- http://www.nntp.perl.org/group/perl.pep/2008/01/msg286.html Mon, 14 Jan 2008 14:08:47 +0000 Email::Corpus building (1 message) To build a corpus distribution, you'll use Module::Install::EmailCorpus. It will cause 'make' to build an SQLite database out of the contents of ./corpus (see below) and will cause that file ot be installed to the package's sharedir. ./corpus will contain one directory per message, each of which will contain a "message" file and a "meta" file. The "meta" file will contain a single YAML document with a sequence of data about the message. Every message will have a guid. (Module::Install::EmailCorpus will, I hope, provide a 'make guidify' to add guids where needed, and will refuse to 'make dist' if not every message has one.) A sample meta file might be: --- guid: 3F2504E0-4F89-11D3-9A0C-0305E82C3301 tags: - mime - crlf:lf - 8bit Email::Corpus::Magic: magic: 1 moon: full The meaning of package-named mapping entries are left up to the owner of the namespace to define, by convention. -- rjbs http://www.nntp.perl.org/group/perl.pep/2008/01/msg285.html Fri, 11 Jan 2008 15:45:56 +0000 Email::Corpus (1 message) Two emails. First, a sample of what I think it will look like: use Email::Corpus; use Test::More; use Hypthetical::DKIM::Tester qw(check_dkim); my $collection = Email::Corpus->search({ package => [ -Core, -DKIM ], name => $name, tags => [ qw(mime tnef) ], filter => sub { exists $_->meta->{dkim} }, }); plan tests => $collection->count; while (my $email = $collection->next) { my ($pkg, $guid) = map { $email->$_ } qw(package guid); is( check_dkim($email->abstract), $email->meta->{dkim}, "expected dkim result on $guid in $pkg", ); } -- rjbs http://www.nntp.perl.org/group/perl.pep/2008/01/msg284.html Fri, 11 Jan 2008 15:35:49 +0000 (non-)progress on Email::Base and Email::Sender (1 message) I'm tired of trying to fix hard-to-fix issues in Email::Send, and tired of saying, "Yeah yeah, Email::Sender someday soon blah blah." So, I'm doing a bit more work on it. Here are my current thoughts: Email::Base is good enough for now. All it does is provide ->throw, which is enough. Someday, I imagine there will be more to it. The big thing it doesn't do that we talked about is a generic constructor and attributes. This isn't a big thing, but it's starting to mildly irritate me as I work on Email::Sender. I don't want to just "bless $arg => $class", and I don't want to say, "all guts are available to all subclasses" or "stick your subclass's guts in $self->{__PACKAGE__}. These all suck. Also, I've refactored "args for the Sender" from "envelope data." Given a mail with a "prec" send-time option, this is still correct: $sender->send($email, { to => $rcpt, from => $sender, prec => 'bulk' }); ...but it is turned into: $sender->send_email( $email, { to => $rcpt, from => $sender }, { prec => 'bulk' }, ); Now, you end up writing: sub send_email { my ($self, $email, $env, $arg) = @_; ... } Blech. What I really want is something we've long talked about internally at work, and something that DaveO and I talked about once or twice at YAPC: messages with attached envelopes. Email + Envelope = Delivery. The you say: $sender->send($email, { to => $rcpt, from => $sender, prec => 'bulk' }); ...and it becomes: $sender->send($delivery, { prec => 'bulk' }); If you already have a Delivery ready to go, you pass it to the $sender->send to begin with. The way I see it, a Delivery does the Email and Envelope roles. It has-a Email and has-a Envelope, and delegates the roles to them. This (plus the pair of fuzzy antler headgear I received for Christmas) is making me start to decide that I'm going to say "screw it" and use Moose. If Email::Sender is a Moose object, it becomes very simple to deal with the attribute issues. I also think (but cannot yet prove) that it will make Email::Sender::Wrapper trivial to do away with, letting Email::Sender::Failable operate directly on concrete Sender classes. I will start work on this in the next week, and it should be very easy. If you have objections, voice them now. My only concern at the moment is that I want the Email role to be easy to grow in the future. I'll spill my guts on some of that now: I want method naming to be uniform across all of these classes, and I think it may have to be set/get. Here is why: headers. It is very convenient to say: $email->header($header_name); This is also convenient: $email->header($header_name => $value); This starts to get weird: $email->header($header_name => $value, $value2); This sucks: $email->header($header_name => undef); I'm also not crazy about "well you use set to set it to anything except for nothing, which requires delete." I could be convinced, though. There's always "setting multiple values requires an array ref, and [] clears." I don't know, I welcome thoughts on the matter. There will be a EmailHeader role, I think. I'm not sure how it will work yet, either. I will probably steal or at least think about stealing from Mail::Box, which does some cool stuff with how bodies and headers interact. Ok, this message is now officially too long. I look forward to hearing your thoughts. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/12/msg282.html Sun, 30 Dec 2007 11:50:21 +0000 pep and 5.005 (1 message) I was mildly surprised when I saw Michael Schwern's recent announcement that he would no longer be supporting 5.005. I was happy to see it, though, because my plan has been to drop 5.005 support, with perl 5.010 coming out. This will mean, at the very least, that 'warnings' and 'our' will no longer be taboo. I'm not going to go out of my way to break things, but as modules get worked on, I will no longer shy away from breaking compatibility with perls more than seven years old. Email::Date::Format, today's new module, requires 5.006. In a few days, MIME::Lite will require it (to drop Email::Date) and I'm sure more will follow. That's all -- I hope everyone's upgraded sometime in the last seven years. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/11/msg279.html Fri, 30 Nov 2007 19:06:00 +0000 How to update (header added) a message via IMAP (1 message) I'm (re)writing a script to do reports on email caught by SPAM filters that isn't really SPAM to the user. This script reads the folder/mailbox then sends a message with a list of the messages. Sender( From: ), Subject, Date, Size to the user. The current (and not working) version was broken when the mail server software provider (protecting the guilty) made some changes to the way the messages are stored. I can no longer mount the share and access the messages raw. So the low hanging fruit seemed to be to use IMAP. Currently I'm getting pretty good results using Net::IMAP::Simple and Email::Simple. For simple reporting and clearing out user defined _old_ messages it is great. The problem comes with a variation where already reported messages should not be _reported_ again. Much searching, reading, head scratching, and a few curses later I'm still kind of confused/lost. I think I just need to extend Net::IMAP::Simple to have a store method. (STORE is already being used to mark a message as Deleted.) Where the confusion creeps in is can I just modify the message object and not use any flags? Using the Net::IMAP::Simple example code; add in $es->set_header( 'MY-Header', $value ); $imap->store( $i ); TIA, Rod -- http://www.nntp.perl.org/group/perl.pep/2007/11/msg278.html Tue, 27 Nov 2007 14:42:28 +0000 new Email::Abstract! (1 message) At long last (and about 3 months past due, says my OmniFocus) I have released a new stable release of Email::Abstract. This release should be significantly saner, with better facilities for a plugin to declare when it will work and when it should be ignored. Email::Abstract is likely to be the email representation passed around in Email::Sender, which should be the next thing to get some attention. Please let me know if you have any problems or concerns about it. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/11/msg277.html Fri, 16 Nov 2007 16:14:47 +0000 the big todo list, posted (1 message) http://emailproject.perl.org/wiki/Big_Todo_List I've dumped my previous mail on this topic to the wiki, in response to the occasional, "What can I do?" mails and privmsgs. So far, these haven't led to much, but... well, a fellow can hope. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/09/msg273.html Mon, 24 Sep 2007 18:26:19 +0000 Email::Store is dead! Long live Email::Store! (38 messages) I've been working on cobbling together a modern mailing list manager written in Perl (Saddlebags), because I find it absolutely unacceptable that things like the dbic list are running on mailman. As a part of this, the subject of storing emails in databases came up. Obviously, we turned to Email::Store. Of course, those of you who've looked at E::S know that it was written in the CDBI days, and is in fact rather tightly woven together with CDBI. Saddlebags is a primarily DBIC project, and I'd rather not bring in a module, for new code, that would have to use other new code's compat layers. I mentioned this offhand to mst, who mentioned it to other people, namely one Brian Cassidy on #dbix-class. Discussion moved to #email and with rjbs' advice, we have the very beginnings of Email::Archive. Right now things are at the general planning stage. I was discussing things with Brian Cassidy on #dbix-class and then #email; right now the basic plan is to put something together that has a data store abstraction, so someone can say "dbic sucks, I want $THIS_ORM instead" and be able to write some code that DTRT. We also discussed Email::Store::Entity, and decided it's a good idea, but that we want something more basic for now, with the plan of extending it in the future. We've got a (mostly empty for the moment) repo at http://www.coitusmentis.info/repos/email-archive/ , hosted on my home cable connection; will see how things go with that. There were a few more things discussed that I'll put in an irclog.txt file in the repo. Anyone interested in contributing can privmsg me an htpasswd line (SHA1 preferably) on IRC (nick apeiron, I'm on magnet, freenode, efnet), or you can Jabber me at apeiron@coitusmentis.info . http://www.nntp.perl.org/group/perl.pep/2007/09/msg238.html Fri, 14 Sep 2007 14:06:07 +0000 Messages won't import into MySQL (7 messages) I've got a simple script that is called from Sendmail (smrsh) : while (<>) { $message .= $_; } Email::Store::Mail->store($message); Most messages import just fine, but I'm running into more and more messages that don't make it. Sendmail complains with the following : dsn=5.3.0, stat=unknown mailer error 255 The message content gets inserted into the 'mail' table, but the message ID never makes it into the 'mail_date' table. Unfortunately I use the mail_date table to sort messages by date. If I run the script at the command line (i.e. cat msg.txt | script.pl), the script exits with a status 0 and no errors. Is there a way I can turn up some debugging within the module to find out what is happening? Regards, Chris http://www.nntp.perl.org/group/perl.pep/2007/08/msg231.html Fri, 03 Aug 2007 16:26:39 +0000 MIME-Lite in pep svn (1 message) As those of you on pep-checkins saw (sorry for the huge noise), MIME-Lite is now in the PEP subversion repository. I've made a new dev release with zero code changes. I'm not a fan of MIME-Lite, as it's fairly buggy and not all that lite. I'm not really interested in making it the best MIME generator around (though feel free to do that), but I would like to reduce its bugginess, since a lot of things use it. As those of you on pep-bugs know (sorry for the brief outage; my bug aggregator script is lame), there are about 120 bugs against email-related modules. 31 of those (that is: 25%) are filed against MIME::Lite. Testing so that 3.020 can be released would be great. Commits to fix bugs would be great. Be great! -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg230.html Sun, 29 Jul 2007 06:53:56 +0000 base exceptions (1 message) Right now, Email::Sender uses -Sender::Failure, and two subclasses of that. The only core exception (beyond the root class) that I can imagine is Unimplemented. Thoughts? -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg229.html Sat, 28 Jul 2007 14:26:04 +0000 Email::Sender updated to use Email::Base (4 messages) So, now Email::Sender isa Email::Base, and uses ->throw. I'm not 100% comfortable with the current Sender behavior. I've changed it a few times, but here's the rough outline: a sending with a sender seems to have three possible outcomes: 1. everything worked! 2. it worked, but not for every recipient or destination 3. it didn't work at all These are currently handled like this: 1. return true with "return $self->success" 2. throw an Email::Exception::Sender::PartialFailure there's a ->failures field that's a hashref, { $dest => $reason } 2. throw an Email::Exception::Sender::FailureFailure That means that you must always eval the ->send call and check for both partial and total failure, if you want to be handle all three cases. So, first of all: any immediate and personal reactions? Here are some of mine: How many people are going to shoot themselves in the foot by re-sending to all recipients after a PartialFailure? How many would shoot themselves in the foot by not noticing failed destinations if partial failure was treated as a form of success? I think the current behavior is righter, and no likelier to trick users into messing up. Do we need to have a built-in distinction between temporary and permanent failure? What are the $reason data? Strings? If so, how do we represent a mixture of temporary and permanent failures? (Is this possible? I am not going to check the RFCs at this second, but during SMTP, can the remote respond with 4xx's to some RCPT commands and 5xx's to others? I don't see why not.) Exceptions may make suitable values. It makes a multiplexing Sender easy to write, anyway. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg219.html Mon, 23 Jul 2007 21:23:47 +0000 Email::Base 0.000 (7 messages) Everyone following along with the svn checkins? If so, this won't be news. I've added a super-rough first draft at Email::Base. All it does is require Email::Exception and provide a ->throw method. It works like this: $object->throw($exception_moniker => $arg); The moniker is either '::Foo' to get Email::Exception::Foo or 'Bar::Baz' to get just that. I don't think I like this, but it's where I started. The exact opposite might be better. $arg is either a string, which is used as the error param to the exception, or a hashref, which is used as the entire set of params. A "thrower" param is always added, referring to the object on which throw was called. Email::Exception has only one field in the base class: thrower. Next email: Email::Sender. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg218.html Mon, 23 Jul 2007 21:14:36 +0000 more Mail::Box interop (1 message) Awesome! I mentioned, at YAPC, wanting to get more interoperability between Mail::Box and Email::*. As of this morning's release of Mail-Box, there are native conversions from Email::Simple and Email::Abstract, and there is a native conversion to Email::Simple. They're crude now, but they'll get better. This should make it easier to delay loading Mail::Box until needed, for example. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg217.html Thu, 19 Jul 2007 05:39:44 +0000 Email::Abstract: big updates; test please! (1 message) So, I spent a few hours today writing more comprehensive tests for Email::Abstract. It started when Mark Overmeer noted that he thought there was a bug in the way Mail::Message objects' newlines were handled. I had a look at the tests for Email::Abstract and basically found that there were a huge number of bugs not exposed by the lousy testing. I've tried to fix them all, and I've gotten 100% test coverage, with much more assertive tests. Here are some of the most important bugs I've addressed: * newlines were lost in the bodies of Mail::Message and Mail::Internet objs * headers were not unfolded from Mail::Internet and MIME::Entity objects * the means of determining the adapter classes were not consistent I'm a little worried about some of the changes, especially my forcible unfolding of headers for Mail::Header objects. Then again, I believe things are correct NOW and it's hard to imagine anyone relied on this BEFORE. I want to use Email::Abstract in Email::Sender, so getting this right is important. I want to make sure the existing behavior is good before I add anything else -- and I will definitely add a stream_to (print_to?) method in a release soon. So, testing, patches, and / or review appreciated. It's in svn and on the CPAN. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg215.html Wed, 18 Jul 2007 19:58:49 +0000 Email::Base (ad Email::Sender) (8 messages) I am eager to get Email::Sender ready for use. The prototype that I use at work is one of the most useful pieces of code in our internal toolkit, I think. It makes all sorts of email-related testing much simpler. Toward that, I've been doing some of the simple stuff required to get Email-Sender in shape, and now that much of the simple stuff is done, I'm going to start writing (stealing) more tests. That's not enough, though. For those of you who saw my talk on PEP at YAPC::NA, you know that one of my biggest dislikes about Email:: is the way that its modules *utterly* fail to display signs of design for organic interoperation. (Today's amusing nit: Email::Abstract doesn't use Email::Simple's method names for common operations.) When we spoke about solving this problem at YAPC, we talked about a small set of common behaviors for new Email:: modules. These would form Email::Base, the name of which has been used to mock the idea of Email:: being overly complex. To that, I say, "whatever." We, the current custodians of that code, don't want to turn it into a giant monolith. In fact, I think it's safe to say that Email::Simple won't take on the Base behavior at all, both to stay as small as it is and because it would require too much reworking. That said, I think Email::Base is a good idea. It can certainly be seen as step one in the PEP Plugin System, which should help make things easier to deal with. At YAPC, the basic idea was that Base would need to include two kinds of things: exceptions and attributes. I think exceptions are simple: Exception::Class is very popular, very good, and fairly lightweight. It works, I believe, on 5.005. Its prereqs are Scalar::Util and Devel::StackTrace (both of which we'd probably need anyway) and Class::Data::Inheritable, which doesn't strike me as a big worry. Possibly the cheapest option for attributes is Class::Accessor, but I think it's too simple. I think it's important that we have a system that makes you really notice when you're violating encapsulation. A lot of Email:: bugs have come about because of a cavalier attitude toward doing things like $email->{head}{names} = $whatever. Once that's in Email::Foo, you can't change the internals of Email::Simple without trauma. I'm not sure what we really want, and I am eager to hear ideas. I would like to keep things fairly simple. Here's a simple idea whose merits and flaws I have not deeply considered, yet (it just popped in there): Objects are hashes in the form { namespace => $guts, ... }. Guts are namespace specific. The objects' classes also have a mapping of attributes to providing namespaces. When you say $obj->attr('foo') it does something to get it from the namespace that owns 'foo'. When two plugins attempt to claim authority over the same attribute, an exception is raised, at compile time if possible. Ok, I know this was a little wordy, but I'm eager to get this ball rolling, so I'm just going to send it. Replies anticipated eagerly. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg204.html Tue, 17 Jul 2007 15:39:48 +0000 replacing the BounceParser (5 messages) I'm not sure how many of you have used "the BounceParser." We use it extensively at work, and speak of it only in hushed tones -- or, if we're sure it can't hear us, we proclaim its wickedness loudly, dreaming of a day when we can be free of it. In the meantime, though, we suffer through its horrible reign of terror. Mail::DeliveryStatus::BounceParser sucks. If you don't already know this, here is a primer on what to hate: * MDSBP->new($input) either returns a BounceParser object or false * the BounceParser object represents a bounce, not a parser * and that's why you can call it as ->parse, now, too * hey, it's 400 lines long, so maybe it deserves two names * if it returns false, you still might not have a bounce * falsity means "we're sure it's not a bounce" * an object means "it might be a bounce, but check ->is_bounce" * a true result from is_bounce means we're sure it IS a bounce * an ideal bounce is an RFC1892 message * other messages are s///d to look more like RFC1892 before parsing * a bounce has many reports * you can get report data with, for example, $bounce->addresses * but don't try $report->addresses, that doesn't work * reports have std_reason fields, explaining WHY the message bounced * one of these is standard reasons is "no_problemo" * not one of them is "spam" or "blacklisted" * go look at the source After all that, it just doesn't work very well, either. I want a good bounce parser for two main reasons: 1. Recognize bouncing mailing list subscribers so they can be booted. 2. Recognize bounces that say that my MXes are being blocked so I can address the situation. I'm not sure what this system needs to look like, but from 1,000 feet up, the BounceParser isn't totally wrong. my $bounce = $parser->parse($email_abstract); my $remote = $bounce->bounced_by; my $local = $bounce->originally_sent_by; my @reports = $bounce->reports; # may be () my $reason = $report->bounce_reason; # one of a fixed list my @addrs = $report->bounced_to; I don't see any reason for this to notice autoresponders at all. If we can tell they're not bounces, there's no reason to report them, is there? The parse method probably does something like: for my $plugin (@prioritized_list) { return $plugin->parse($message) if $plugin->can_parse($message); } return; Have I been twisted and blinded by The BounceParser? Is there a significantly better way to design this? I have a few million bounce messages sitting in an archive, just waiting to become test cases. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg203.html Tue, 17 Jul 2007 15:39:47 +0000 pep-checkins is operational again (1 message) About three months ago, we moved pep.pobox.com (which hosts emailproject.pobox.com) to a new server. A few things broke for a few hours, but svnnotify hasn't been working since then. I "fixed" it a few times, but never bothered checking that it was fixed, since I viewed the commit list as unimportant. Since I want people to be able to see WTF is going on, though, I've realized that the commit list is actually very important. It's been fixed as of this morning. To join pep-checkins, visit http://listbox.com/subscribe/?list_id=4142 -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg202.html Tue, 17 Jul 2007 05:56:30 +0000 things you can do (1 message) I've gotten a few "What can *I* do?" emails lately, so here's a recap. These are all things that should be do-able without having to learn anything really esoteric, make any design decisions, or worry about breaking things too much: Dists desperately in need of more tests (roughly in order of urgency): * Email-MIME, Email-MIME-Modifier, Email-MIME-Creator * Email-Address - there are some cases in which it still seems to hang * Email-Filter * Email-MIME-Attachment-Stripper * Email-LocalDelivery - it used to fail to report some class of errors * Email-Sender * Email-Simple, Email-Simple-Creator * Email-Thread * Mail-Audit Determine minimum version: * all dists should get a t/perl-minver.t like Email-Simple has * the minimum version Perl::MinimumVersion suggests should be documented * ...and tested to ensure that it's right * ...and corrected if it is not Wikimastering: * just dump ideas and other thoughts onto the wiki! Miscellaneous other tasks: * port any changes to the Mail::Audit delivery routines to Mail::LocalD * ...and then make Mail::Audit use that * update Email::Valid to use Email::Address for RFC2822 address checks Then, here are some more technically-involved tasks: * the Email::Abstract enhancements listed here: http://emailproject.perl.org/wiki/Email::Abstract * improve Email::Address to require no preprocessing of whitespace * improve Email::Address to handle address groups (at least the empty one) * make Email::MessageID not isa Email::Address * make Email::MessageID use Sys::Hostname::Long if available -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg201.html Mon, 16 Jul 2007 04:47:21 +0000 simpler than simple, the newest e-mail module (1 message) For those of you who read my journal, I apologize for the duplication. For the rest of you, I apologize for the content. http://use.perl.org/~rjbs/journal/33806 -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg200.html Mon, 16 Jul 2007 04:32:37 +0000 Email::Simple 2.0 immanent (2 messages) I've re-privatized some of the extra API I had added to ::Header in order to get a release out while still waffling a bit about how much interface to add to Email-Simple itself. The current trunk of Email-Simple is, I think, ready to be released as Email::Simple 2.000. This is not some magic 2.000 all new API or anything. It's just the version after 1.999. Please have a look, give it a go, and let me know if there's any reason to hesitate. I plan to release this week. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/07/msg198.html Tue, 03 Jul 2007 15:09:45 +0000 notes from YAPC (1 message) YAPC is done. I gave a talk on handling email with Perl, and I think it went fairly well. We had a get-together after the talk and spoke about what we need to do in the future. I think that also went well. I'm going to start dumping out some of the results from all of that over the next few days, and I hope we can start building some momentum. Here's a dump from my OmniFocus for PEP tasks. Some of them are stupid and only for my notes, some may provide some reminders to people who were (or weren't) there about things we'd like to start talking about or working on. Anyway, I'm on a bus and I think I'd like to try to get a few more disconnected tasks done before I arrive at the office. More soon! build db of known email headers fix all copyright notices standardize dist layouts add MinimumVersion tests to * Email-Simple-Header finalize api for 2.0 Email-Corpus design api basic implementation plan Mail-LocalDelivery actually use it in Mail::Audit (or E::LD or E::Sr) improve email sending tested Email-Sender Mail::Message::Coerce::Email colon / semi typo in Mail::Mailer docs Email::Base BounceParser 2.0 Email::Metadata Email::KB Email::Return (Zion) -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/06/msg197.html Fri, 29 Jun 2007 08:06:14 +0000 Email::Sender in Subversion (1 message) It's been festering in my ~/tmp for too long, half ported from Work Code, so I've put it in Subversion, hoping that either I'll feel more compelled to get it release-worthy or someone else will. Heck, maybe someone will just have some snide remarks. It would be nice to get this more demonstrable by YAPC. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/06/msg196.html Mon, 18 Jun 2007 19:39:36 +0000 toward Email::Simple 2.000 (1 message) First: In case you're subscribed, note that the pep-checkins is currently busted. I haven't even looked into it, yet. We moved PEP svn from a standalone machine to a Solaris zone recently, and I probably broke something stupid. I bring this up because I know that it means none of you have probably seen the Email::Simple checkins I made yesterday. I'm trying to get ready to release Email::Simple 2.000. It's going to be a great release, I think. I'm not trying to do the crazy "not-backwards-compatible changes at major version number!" thing. Instead, I'm trying to document and standardize more of the interface. My mantra for the 2.x series of Email::Simple is "better interface standardization." I want it to do roughly the same amount of stuff, with roughly the same performance. I just want it to be clearer how one can subclass Email::Simple, and I want to refactor, document, and improve the usability of the core features of Email::Simple. (This will probably include a rewrite of the Email::Simple<->Data::Message relationship.) Here's a summary of things I checked in last night: * better documentation for the Email::Simple::Header object * provide a means to request a different header class * public interface for header folding * documented how options are passed to Email::Simple constructor * add options to as_string, namely options to alter header folding * add methods that return default values of various options * some performance improvements These changes are mostly here to make it easier to subclass Email::Simple's behavior. In almost every case, I want the answer to "how do I change Email::Simple's" behavior to be "subclass" or (later) "use a plugin." Since some features are really very fundamental core features, though, they seemed like a good place to demonstrate my intentions. I'm going to release this as a _x release, soon. Please let me know, now or then, if you have any thoughts. -- rjbs http://www.nntp.perl.org/group/perl.pep/2007/05/msg190.html Wed, 30 May 2007 06:19:05 +0000