Re: Email::Base (ad Email::Sender)
On Wed, Jul 18, 2007 at 03:09:21PM -0500, Smith Warren - wasmit wrote: Just remember, if you ever want your module to become part of the perl core distribution, it must rely solely upon other core modules. I can't think of anything in Email:: that belongs in core, offhand: http://use.perl.org/~schwern/journal/33652 All of the syntatic sugar that Moose [and any other meta-oo class] affords can be implemented with common (although seemingly complicated) standard perl structures. OO is syntactic sugar for procedural programming. Perl is syntactic sugar for C. I am sympathetic to arguments that we should not write another Mail::Box, but I don't think we're writing a whole project's worth of ::Tiny modules, either. I don't want to reinvent the wheel if it means it falls to me to make sure it stays round. hdp.
Re: replacing the BounceParser
On Tue, Jul 17, 2007 at 06:37:29PM -0400, Ricardo SIGNES wrote:
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?
I guess it depends what your use case is. If you're trying to process
true failure DSNs, you probably don't care about autoresponders. If
you're trying to keep administrivia off of a mailing list, you probably
want to detect things like read-receipts, out-of-office replies,
temporary failure warnings and the like.
Maybe the solution is just to not call it BounceParser?
# Create a parser. Don't load any plugins automatically.
my $parser = Email::Classifier-new();
# Load the Email::Classifier::Plugin::Bounce plugin for catching
# bounce messages
$parser-add_classifier('Bounce');
# Load plugin for Out of Office replies
$parser-add_classifier('Vacation');
# and hey, this would be nice too
$parser-add_classifier('TemporaryDSN');
# Iterate over prioritized plugins and return first hit
my $result = $parser-parse( $email_abstract );
# whine about it
print I got a . $result-get_classification()
. from . $result-get_sender()
. on message originally sent by . $result-get_original_sender()
. \n;
Heck, if one wanted to be truly evil:
my $parser = Email::Classifier-(
classifiers = [ 'GPG' ],
);
my $r = $parser-parse( $email_abstract );
if( $r-is_gpg_signed() ) { # let plugins provide new methods to
# result object (inheritance? Sub::Exporter?)
if( $r-valid_signature_by('0x12345678') ) {
# Yes, we fully trust the message now
eval $email_abstract-get_body();
}
}
Cheers,
Dave
signature.asc
Description: Digital signature
Email::Abstract: big updates; test please!
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
