Modify our code or modify Mail::Audit?

Discussion re sg development. You don't have to be a developer.

Modify our code or modify Mail::Audit?

Postby SysKoll » Mon Oct 20, 2003 6:42 pm

If I remember correctly, we decided to use Mail::Audit because of parsing problems in the spameater.pl code. But now we see other unexpected parsing problems in Mail::Audit.

So what should we do? Amit, Josh, what's the reasoning for using Mail::Audit? What's the advantage compared to reworking the spameater code?

We really need to evaluate the benefits of using Mail::Audit since we're headed towards butchering it.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby josh » Tue Oct 21, 2003 3:37 pm

We had hoped to wrap the sg code in some standardization and at some point make a graceful entry to CPAN with everything. Amit researched it and found that Mail::Audit is about the most widely used set of libraries -- spamassassin uses it, for example. All info we've seen since then has tended to confirm this (I think).

Beyond that, my code is generally ugly, but my "parsing" code is really ugly. It happens to be more effective than M::A within our current list of problem scenarios only because I made it even uglier to handle the one-off situation we ran into with About.com

Another impetus was to use SMTP to connect straight to a mailserver to resend the mail instead of invoking command-line sendmail. I do have some socket code lying around that we could have used, but again here, I think we're going for standardization.


One approach to this would be to modularize the code to the point where we could plug in the parsing and sending functions and use the home-grown code or the M::A code via configuration. Doing that without "putting on weight" could be a challenge, though.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Inventory the M::A problems to fix

Postby SysKoll » Tue Oct 21, 2003 4:03 pm

Josh,

You make a good point about why using M::A is a good idea.

Now let's make a list of problems we have with M::A and need to be fixed before we can use it for SG.

Perusing previous messages, I see:
    * Multi-line header fields not parsed correctly, resulting in blank Subject fields
    * Received fields wiped off by resend() method


That ought to be fixable. Anything else?
Last edited by SysKoll on Tue Oct 21, 2003 4:10 pm, edited 1 time in total.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Volunteers?

Postby SysKoll » Tue Oct 21, 2003 4:09 pm

And, more importantly, who wants to take the jobs? Two tasks here:
    * Contact the Mail::Internet developers about a patch
    * Coding the fix

Any taker?
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby maratheamit » Tue Oct 21, 2003 5:36 pm

I can take on the task. But don't expect a quick turnaround since I am going to be busy the next couple of weeks at work. That may not be a bad thing: Josh wanted to roll out a throttling release before we start to use CVS to make all code changes.
maratheamit
 
Posts: 82
Joined: Fri Aug 29, 2003 2:35 pm

Coding the fix

Postby SysKoll » Tue Oct 21, 2003 7:19 pm

Amit,

Please contact the Mail::Internet author and ask him if he'd accept a patch. If not, we'll have to deliver the modified Mail::Internet module with the SG code.

I will attempt to code the fix, at least the Received fix, with an added option, which by default is compatible with t the current behavior of removing the Received headers.

I haven't looked at the multiple-line problem yet. Input welcome.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby josh » Thu Oct 23, 2003 2:48 am

I can take on the task. But don't expect a quick turnaround since I am going to be busy the next couple of weeks at work.


you won't hear a peep out of me, with the rate I've been working :) We're talking about probably adding a new method (other than ->resend()) right?
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Adding a method

Postby SysKoll » Thu Oct 23, 2003 3:54 am

I was thinkin about adding an option to resend(), but you're right, adding a new method, e.g. forward(), would make more sense.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm


Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest

cron