The mailing list for listmasters using Sympa

[Steve Shipway <address@concealed>]

Here’s an unusual problem (Sympa 6.1.23) that someone may have encountered in the past.

 

I have a list set up with MailMerge enabled.  I know it works, because I have a few test emails I can send via the list and they merge correctly.  Some of them are pretty complex, but it all works fine.  This would seem to validate that the list is configured correctly.

 

I have another test email, that appears pretty much the same as the others – in fact, I cut-and-pasted much of the merge code into it.

 

When I send THIS email via the list (using Outlook 2010), nothing appears to change in it at all – it is as if the mailmerge just did not happen, or the personalisation flag was set to ‘no’.

 

The message I am sending is not S/MIME signed or encrypted (in fact my send scenario prevents this), and I have re-entered some TT2 codes at the start in case for some reason the other codes were polluted by embedded HTML or something.  Still, nothing merges, and no errors in the log.

 

Why is this happening?  I have a suspicion that Outlook may be sending the message in TNEF format, which might break things, but I have the ‘convert to HTML’ option set in Outlook, and in any case it gets delivered OK.  Will Sympa expand out TNEF correctly?  Is there a way to track and fix this that anyone knows of?

 

Analysis of the non-working received message (after merging) shows that it is MIME format, with this structure:

 

Multipart/mixed

    Multipart/alternative

        Text/plain (this part IS being merged!)

        Text/html (this part is NOT being merged) Content-Type: text/html; charset="us-ascii"

Img/jpg

 

Strangely, the text/plain part IS being merged, but is not displayed by the mail reader because the reader prefers the text/html in the multipart/alternative.    So, why would part of the message be omitted from the merge process?

 

The working merge has the same structure, except that it has two Img/jpg parts at the end.  Both the text/plain AND the text/html are merged successfully.  Both text/html sections have the same encoding and charset.

 

As far as I can tell from the code, the possible reasons for NOT merging a section would be :

-          Nonstandard encoding.  Both sections are quoted-printable , so this is OK (Content-Transfer-Encoding: quoted-printable )

-          Multipart/signed or multipart/encrypted.  Neither part is this, so this is OK

-          Sub-part merge failed – this returns undef, so it was not this.

-          Effective type multipart but it has no subparts – not this.

-          Empty body – There’s definitely something there, so not this

-          $bodyhandle->is_encoded – not sure what this means.

-          All other tests return undef, so it cannot have been them

 

The only option I can see is the is_encoded test, but why would this be set for one mail and not the other?

 

Any help or suggestions appreciated…

 

Steve

 

 

Steve Shipway

University of Auckland

UNIX Systems Design Team Lead

address@concealed

+64 (9) 3737 599 ext 86487

(GNU Terry Pratchett)

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature