Re: Email::Store is dead! Long live Email::Store!
On Dec 19, 2007, at 3:36 AM, Ask Bjoern Hansen wrote: Did anything happen with rewriting Email::Store and/or Saddlebags? My last write a mailing list manager was an attempt at porting the parts of ezmlm I don't like to Perl, but I couldn't find a good place between stick with how it works and redo everything to make it nice to work with. (Like all half-assed MLMs, it does run a few lists, of course). You know, I could really use some help with Dada Mail - the last time this thread was active, my message I sent telling people about it was never posted. Anyways, the next alpha release of Dada Mail is looking pretty killer. If anyone is interested in helping with development, let me know what your pet project may be. Dada Mail is on its 8th year of development and is quite mature. It's userbase is in the tens of thousands. It's not a Mailman replacement (nor is it trying to be), but it does support discussion lists, archiving and can be installed by anyone who can tackle something like phpBB. It's not the tool for everything, but it's a good tool for lots of things. One of the projects I'd really love help on is getting a proper, make, make test, make install distribution and having it hosted on CPAN. Right now, I've just been working on the test suite, which has about 5,000 tests already. I'm personally not a comp sci guy - I graduated with an art degree, but I've managed to do quite a heap of work already. A lot of the code isn't up to the pep spec, but a lot of the code was written before pep's recommended CPAN modules existed. Another project may be to get it working with those modules - for example, replacing the MIME-Tools stuff with other things. One of the main goals of Dada Mail is to have it installed without needing any XS perl modules, so people who do not have CPAN (or don't know how to use) or a compiler can install it. Anyways, the homepage for it is here: http://mojo.skazat.com There's a discussion list about it here: http://mojo.skazat.com/cgi-bin/dada/mail.cgi/list/dadadev/ Sourceforge: http://sourceforge.net/projects/mojomail And the CVS: http://mojomail.cvs.sourceforge.net/mojomail/dada_mail_stable/ Development is getting pretty lonely, esp. since the codebase is getting so large - it's getting hard for me to be the only person hacking away at it. Anyways, just throwing that out there. I don't mean to take over the thread, but if anyone has any questions about the project, I'll be happy to answer them personally, -- Justin Simoni http://justinsimoni.com :: Art Portfolio http://skazat.com :: Sketchbook On Dec 19, 2007, at 3:36 AM, Ask Bjoern Hansen wrote: Christopher Nehren wrote: 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. Did anything happen with rewriting Email::Store and/or Saddlebags? My last write a mailing list manager was an attempt at porting the parts of ezmlm I don't like to Perl, but I couldn't find a good place between stick with how it works and redo everything to make it nice to work with. (Like all half-assed MLMs, it does run a few lists, of course). - ask
Re: Email-ARF (abuse reporting format)
There exists an ARF-producing Perl module, MIME::ARF, but it's not on the CPAN and only produces reports. Today I wrote an ARF-reading module, Email::ARF::Report, and uploaded it. It's a prototype, and if you deal with ARF, please let me know if you think it's ready to go to production. Here is the announcement I sent to the ARF list: http://mipassoc.org/pipermail/abuse-feedback-report/ 2007q1/000109.html Wow, This is all very interesting. I'm going to put this on the TODO list of my app to integrate ARF support into its bounce handler. I'll play with it a little and let everyone know if I come across anything of interest. Justin On Mar 20, 2007, at 8:39 PM, Ricardo SIGNES wrote: AOL lets you say, Look, I want to be a nice guy. If you get complaints about mail from me, please let me know and I'll look into it. They send these report in a format called ARF. http://www.mipassoc.org/arf/ Well, actually, they use two formats, but one is old and lame and is being replaced by ARF. There exists an ARF-producing Perl module, MIME::ARF, but it's not on the CPAN and only produces reports. Today I wrote an ARF-reading module, Email::ARF::Report, and uploaded it. It's a prototype, and if you deal with ARF, please let me know if you think it's ready to go to production. Here is the announcement I sent to the ARF list: http://mipassoc.org/pipermail/abuse-feedback-report/ 2007q1/000109.html I may or may not produce an Email::FeedbackReport::AOL to parse their old report format. It's pretty lousy, so I'm not sure it's worth it; there isn't much information to glean from it. -- rjbs
Re: Mail::DeliveryStatus::BounceParser - qmail support?
On Sep 25, 2006, at 12:50 AM, William Yardley wrote:
As you state below, Qmail's bounces are strange. Not only do they not
generate RFC compliant DSNs, but I believe there are a lot of third
party additions to qmail which make things work differently (out of
box
Qmail, IIRC, always does accept-then-reject).
Oh, wonderful ;)
I have done some work recently on fixing up some old regexes and
ripping
out some old code - it is very possible that in the process, I have
created new cases where MBP doesn't process a message correctly. I
believe there is at least 1 qmail test case in there (yup -
corpus/qmail.unknown.msg).
Is this in a repository? I'm looking at 1.515 in CPAN and it doesn't
have Qmail anything.
I think the standard qmail (sorry it didn't work out) user unknown
bounce should be parsed properly by MBP.
The only thing I can get back from M::DS::BP is a, user_unknown
message via $report-get('std_reason');
My homebrew system attempts to delve a little further. Here's some of
the headers it attempts to get:
Email: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Status: 5.x.y
Action:
Diagnostic-Code: Remote host said: 550 unknown user [EMAIL PROTECTED]
Guessed_MTA: Qmail
As you can see, most all of these are made up! Status is completely
made up, but attempts to map the Diagnostic Code to the Status. The,
Guessed_MTA is another spoofed header, but could come in handy.
But from just grokking this a bit further, you could also get the,
M::DS::BP-ish, smtp_code. The Qmail bounces, however strange are
fairly well documented. The above report was taken from this snippet
of the bounced message (plus some other headers, etc):
[snip]
Hi. This is the qmail-send program at mail.example.com.
I'm afraid I wasn't able to deliver your message to the following
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
[EMAIL PROTECTED]:
64.19.170.37 does not like recipient.
Remote host said: 550 unknown user [EMAIL PROTECTED]
Giving up on 64.19.170.37.
[/snip]
Sorry about giving just a snippet - it'll take me a little while to
sanitize the entire bounce completely for testing consumption.
If this type of grokking seems sufficient, I'll be happy to hack away
at the current code, provide some tests, etc. It's pretty messy, even
in my standards :)
If it sounds interesting to you, I may just provide you with an
entirely new version of the module, with the same API, for giggles
(but I may just start with the Qmail stuff)
Cheers and thanks for the feedback,
Justin Simoni
--
:: is an eccentric artist, living and working in Denver, Colorado
:: URL: http://justinsimoni.com
:: Mailing List - http://justinsimoni.com/mailing_list.html
On Sep 25, 2006, at 12:50 AM, William Yardley wrote:
On Sun, Sep 24, 2006 at 08:44:13PM -0600, Justin Simoni wrote:
[ I've been doing a lot of work recently on MBP ]
On my testing, it doesn't seem that the module really understand
Qmail generated bounces, although the docs do state that it does.
As you state below, Qmail's bounces are strange. Not only do they not
generate RFC compliant DSNs, but I believe there are a lot of third
party additions to qmail which make things work differently (out of
box
Qmail, IIRC, always does accept-then-reject).
I have done some work recently on fixing up some old regexes and
ripping
out some old code - it is very possible that in the process, I have
created new cases where MBP doesn't process a message correctly. I
believe there is at least 1 qmail test case in there (yup -
corpus/qmail.unknown.msg). See below, but yes
- if you have examples of stuff that isn't parsed correctly, please
submit examples and / or patches. If you have information on the
version(s) of qmail involved and any third party additions / patches,
please let me know about those too.
I think the standard qmail (sorry it didn't work out) user unknown
bounce should be parsed properly by MBP.
Looking in the code itself, it seems as if there is no preprocessor
for qmail, although others are listed, ala:
67: my @Preprocessors = qw(
68: p_ms
69: p_ims
70: p_compuserve
71: p_aol_senderblock
72: p_novell_groupwise_5_2
73: p_plain_smtp_transcript
74: p_xdelivery_status
75: );
First of all, MBP is definitely a strange beast. Neither rjbs nor I
wrote it originally. We've been working on building up a corpus of
test
emails, and some example cases for problems that come up. The goal is
hopefully to work on a new and improved mail parser (which hopefully
will handle more than just bounces).
Not all the work happens in the preprocessors. These just rewrite the
message internally into a format that the original author found easier
to parse with the module.
but! is there any interest for me to port over my time-tested code
into the style that's used in M::DS::BP? I'll be happy to provide
either a tweaked version of the module
