On April 22, 2003 at 15:03, David Raistrick wrote:
I've noticed something I consider a bug with <spammode>. (Great work w/
modifybodyaddresses, btw. I just wish that --editidx would apply those
changes to past messages. Or maybe a new function, --editmsgbody..)
The converted email message header and body are static once converted.
v2.6 added the new RECONVERT resource to give you the ability
reconvert existing archived messages. I.e. You can give mhonarc
the original raw mail messages of archived messages and have mhonarc
reconvert them. This is useful for preserving message numbers or
for reconverting a few messages without rebuilding an entire archive.
However, if you need to reconvert all messages, it is much more
efficient to rebuild the archive from scratch.
I notice that the $FROM$ (and just $FROMADDR$) is NOT munged when spammode
is enabled. I can forgive modifybodyaddresses for not munging this, since
it's in the <head> of the message, but I cannot see any reason why the
exact same $FROM$ variable is munged in one place but not in another.
Technically, $FROM$ is not used in the message header. MHonArc is
working directly with message header data, not resource variables.
It has not been considered if ADDRESSMODIFYCODE should also apply
to resource variables. Currently, what exists are $FROMADDRNAME$
and $FROMADDRDOMAIN$ variables allowing for archive admins to deter
address harvesters. But they do not give you the general abililty
of ADDRESSMODIFYCODE.
The whole address munging was more focused on static converted data
vs dynamic data.
I'll submit a bug report via savannah unless you folks convince me
otherwise. (I dont see any open or closed bugs regarding this)
I see this as a feature request.
This starts touching on the issue of supporting "scripting" type
components in a resource file. Currently, MHonArc template language
is declarative, with no programming constructs.
For this particular case, it possible to add an additional argument
to $FROM$ and $FROMADDR$ to denote if ADDRESSMODIFYCODE should be
applied. For example:
<MsgPgBegin>
<!doctype html public "-//W3C//DTD HTML//EN">
<html>
<head>
<META name="keywords" content="Date: $DATE$ From: $FROM(CUR;1)$">
<title>$SUBJECTNA$</title>
</head>
<body>
</MsgPgBegin>
The only problem is that this is not the cleanest solution and can
cause problems if additional future arguments will be supported for
those variables. The whole resource variable arguments support is
kind of a hack.
An alternate solution is to provide different resource variables
that have ADDRESSMODIFYCODE applied to them.
Note, you can use the callback API to implement a custom solution
your problem. See the $mhonarc::CBRcVarExpand callback.
--ewh
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-USERS
