bbs.spamgourmet.com

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.

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,

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?

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?

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.

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.

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?

I was thinkin about adding an option to resend(), but you're right, adding a new method, e.g. forward(), would make more sense.