[sup] Editing names before they're indexed

[Michael Parks]

Me again - thanks for the previous help on that indexing thing. Hooks are
definitely the way to go!

I've got another issue which I think i've tracked down the reason for. I
currently get my work email (hosted on an Exchange server) via Davmail,
which provides the IMAP port I use with offlineimap which pulls into sup.

Not at all confusing, right?

Horrible exchange server -> Davmail -> Offlineimap -> Sup

What's happening is somewhere along the line, the header lines containing
the from/to/cc/etc addresses are getting mangled. I'm not sure where in the
chain this is happening, but it manifests in the headers as random
applications of newline characters. What this means is that Sup sees
people's names as something like, for my name, 'Michael"'.

Here's one of the crocked headers (don't worry, these names are all bogus):

To: : "Lockman, Xavier" <***@company.com>, #Engineering
<***@company.com>, "Medhurst, Louisa"
<***@company.com>, "Koss, Lucius"
<***@company.com>, "Mufeeda-Nazari, Judi"
<***@company.com>, "Tranter, Lilian"
<***@company.com>, "Kingsmill, Jeremy"
<***@company.com>, "Rowan,
Mary" <***@company.com>, "Abdullahi, Abraham"
<***@company.com>, "McMinn,
Matthew" <***@company.com>


In this case, Mary Rowan and Matthew McMinn's names would be indexed as
'Mary"' and 'Matthew"', with their last names being lost entirely.

What i'd like to be able to do is play with the message header before it's
processed and broken down into its component people. I've got a regex which
I can use with String#split to rewrite the names into a more sane format
(and by "more sane", I mean "with newlines after each name<email> pair").

However, it looks like all of Sup's hooks take effect after this processing
has already been completed.

Is there a supported way to tweak the incoming messages before they're
processed?

[Ruthard Baudach]

Again I'm afraid this is not a sup problem, but a RMail related one.

As far as I was able to decifer the source code of sup, sup never sees
the raw email data, but uses RMail to read the sources, building a
Redwood::Message object wrapping a RMail::Message object.

Thus I see the following possibilities to solve this problem

a) fix the chain "Horrible exchange server -> Davmail -> Offlineimap"
b) file a bug with RMail (I'm not shure -- did the sup team took
responsibility for RMail a few years ago?)
c) create a script reformatting the emails in your local maildir and
call this from the before-poll hook
d) If you got a working solution to parse these crippeled address lines,
contribute it to RMail

Ruthard Baudach

Post by Michael Parks
Me again - thanks for the previous help on that indexing thing. Hooks are
definitely the way to go!
I've got another issue which I think i've tracked down the reason for. I
currently get my work email (hosted on an Exchange server) via Davmail,
which provides the IMAP port I use with offlineimap which pulls into sup.
Not at all confusing, right?
Horrible exchange server -> Davmail -> Offlineimap -> Sup
What's happening is somewhere along the line, the header lines containing
the from/to/cc/etc addresses are getting mangled. I'm not sure where in the
chain this is happening, but it manifests in the headers as random
applications of newline characters. What this means is that Sup sees
people's names as something like, for my name, 'Michael"'.
In this case, Mary Rowan and Matthew McMinn's names would be indexed as
'Mary"' and 'Matthew"', with their last names being lost entirely.
What i'd like to be able to do is play with the message header before it's
processed and broken down into its component people. I've got a regex which
I can use with String#split to rewrite the names into a more sane format
(and by "more sane", I mean "with newlines after each name<email> pair").
However, it looks like all of Sup's hooks take effect after this processing
has already been completed.
Is there a supported way to tweak the incoming messages before they're
processed?

--

Emails bitte verschlÃŒsseln und signieren.
Meine PGP-Id: 0xAC5AC6C2