On Wed, Jun 08, 2005 at 08:56:15AM +0200, Sven Riedel wrote:
> I'll have to see if the plugin mechanisms allow the passing
> back of changed mail content somehow.
Not in as much as you would have to directly manipulate the internal message
structure. The parsing bits are wholy separate from the
> I suspect that you could do this as a plugin, but I also
> suspect you would
> have to take ugly liberties with the internal data storage in SA. For
> instance, I suspect (but do not know) that plugins are
> probably not supposed
> to modify the mail text.
Well, the modification would not be
> Would this make sense? Can this be included into spamassassin, or
> are the current internals structured in way that makes the introduction
> of such plugins hard/impossible?
The concept of normalization has been discussed under various names over
time. My personal impression is nobody really k
> Or one could do like Theo, and strip all HTML content from
> the emails. :)
Or do that. I'd love to do that. But unfortunately, some users
actually like html mails. No accounting for taste :)
> The problem with the normalization, is like anything else.
> One mans ham,
> anothers spam. Repetit
>-Original Message-
>From: Sven Riedel [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, June 07, 2005 8:58 AM
>To: users@spamassassin.apache.org
>Subject: Would a normalization plugin make sense?
>
>
>Hi,
>since a lot of spam nowadays tries to get past the filters
>
Hi,
since a lot of spam nowadays tries to get past the filters
by multiplying random letters, wouldn't it make sense to
introduce normalization plugins to spamassassin?
These would run over the mail once before the actual scanning
starts, and perform transformations on the decoded mail body.
Some
