Re: ditching the wiki
On Fri, Dec 04, 2009 at 06:41:34PM -0500, Ricardo Signes wrote: The wiki isn't used. Unless someone objects strongly, I am going to get rid of it and replace it with a few static pages. Sounds good to me. Cheers, Dave
Re: bug in MIME::Entity make_singlepart
On Fri, Jun 27, 2008 at 11:37:56AM -0400, Ricardo SIGNES wrote: I think that it's documented, so it should keep working. If nobody has asked for it to throw an error, it either isn't coming up or it's coming up and people accept it. I'd suggest adding an error-generating branch (with a different method name or an arg) or just removing the entire Content-* header set (since there is no content!) but I wouldn't need to use it, and who knows if anyone else would. Ok, MIME::Entity now nukes all content-* when converting an empty multipart to a singlepart. Adding optional error-throwing is probably too much effort for such a bizzare edgecase anyway. The fix is in 5.427, which is currently winding its way through PAUSE. Cheers, Dave -- Dave O'Neill [EMAIL PROTECTED]Roaring Penguin Software Inc. +1 (613) 231-6599http://www.roaringpenguin.com/ For CanIt technical support, please mail: [EMAIL PROTECTED]
Re: bug in MIME::Entity make_singlepart
On Thu, Jun 26, 2008 at 01:37:09PM -0400, Ricardo SIGNES wrote: 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? So, there are two possible fixes. One, nuke all those extra attributes from Content-Type before setting it to text/plain. Simple to do, and doesn't appear to break anything else. Two, have make_singlepart() return an error (or preferably, die... but MIME-tools doesn't really do exceptions) if you try to collapse a zero-part multipart into a single part. Also simple to implement, but would break documented behaviour. The docs for make_singlepart say Also crunches 0-part multiparts into singleparts, so the first option is probably the safest for backwards compatibility. However, it does seem nonsensical to convert an empty multipart/* part into a text/plain. Is this a case that's frequently encountered? If not, maybe it's OK to change that behavior. Thoughts? Dave
Re: [Mimedefang] Developer release of Email::VirusScan
On Fri, Apr 11, 2008 at 08:47:13AM +0200, Steffen Kaiser wrote: you have included the Frisk F-Prot demon protocol of demon v4. I recently posted the code for demon v6, which is totally different from the previous one. Oops. I must have split off the Email::VirusScan code before your patch made it in to MIMEDefang. I'll fix that today. Cheers, Dave -- Dave O'Neill [EMAIL PROTECTED]Roaring Penguin Software Inc. +1 (613) 231-6599http://www.roaringpenguin.com/ For CanIt technical support, please mail: [EMAIL PROTECTED]
Developer release of Email::VirusScan
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 [EMAIL PROTECTED]Roaring Penguin Software Inc. +1 (613) 231-6599http://www.roaringpenguin.com/ For CanIt technical support, please mail: [EMAIL PROTECTED]
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
