The mailing list for listmasters using Sympa

[Steve Shipway <address@concealed>]

(CC:list for benefit of future archive googling)

> Brilliant - that's what the issue was alright.  I had enabled
> merge_feature by default (i.e. "merge_feature on" in sympa.conf).
...
> Because this bad message was already queued, I had to manually set 
> merge_bulkmailer to 0 in bulkmailer_table (independent of changing the 
> list configuration) to get the message to clear.

Glad that fixed it.

I've noticed problems in the past when giving invalid TT2 code to a 
merge_feature-enabled list - it can result in an empty message being 
distributed if there is any TT2 error, rather than a notification to the 
message sender.  This is the first time I've seen a complete hang of the 
thread, though.

I noticed that the offending message contained lots of C code similar to:

sprintf(s,"[%2d]",x);

The [% is the start token for TT2 code; however there is no end token, so the 
entire message was seen as hundreds of nested TT2 expansions, which seems to 
have blown the available memory or recursion limits.  It seems that TT2 (and 
Sympa's handling of the TT2 call) is not as robust as it might be...

You might like to check to see which version of TT2 you're using.  RedHat 6 
has v2.22 in RPM format, but this omits string vmethods like ucfirst etc; 
v2.24 is better (we're using it on our test server, but not under 
production).  v2.25 is currently available on CPAN, though it seems to be 
little changed.

IMHO it is probably best to disable merge_feature on all lists unless really 
required, and never enable it on a public list.

Steve


Steve Shipway
ITS Unix Services Design Lead
University of Auckland, New Zealand
Floor 1, 58 Symonds Street, Auckland
Phone: +64 (0)9 3737599 ext 86487
DDI: +64 (0)9 923 6487
Mobile: +64 (0)21 753 189
Email: address@concealed
 Please consider the environment before printing this e-mail : 
打印本邮件，将减少一棵树存活的机会

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