Developers of Sympa

[Jeff Abbott <address@concealed>]

Folks,

As I talked about a couple of weeks ago, we plan on using Sympa for  
the distributing of messages to admins from several automated  
systems, some of which appropriately report themselves as being from  
mailer-daemon@host-in-question.  This was causing problems as Sympa  
filters several such addresses and drops the messages.  While I like  
this behavior for most of our lists -- it prevents the owners from  
seeing alarming messages they don't understand and whining at us  
about them -- this simply wouldn't work for our "system contact  
address" lists as we don't want any mail to be rejected or dropped on  
the off chance that it may be useful.

I brought this up a little while back and Serge (I believe it was)  
said that pulling the regex into a configuration value would be fine,  
so I've worked up a patch to do just that; it's attached.  I tested  
it and it applies cleanly to the latest CVS update.  Please let me  
know if you need me to do anything like file it in the bug tracker or  
whatnot.

This patch adds an additional value added to sympa.conf:   
loop_prevention_regex.  It defaults to the old value of:

  ^(mailer-daemon|sympa|listserv|majordomo|smartlist|mailman| 
$conf_email)(\@|$)

Variables in there will be expanded provided they're available at the  
time the regex is examined, which I believe may be limited to  
$conf_email and $conf_host.  Messages from addresses matching this  
regex will be dropped.  The default behavior shouldn't change  
anything for existing sites, and I'm hoping that this will make it  
into 5.2.  To accomplish our goal of having most lists not get  
messages from these addresses but still allowing some to do so, we've  
set our loop_prevention_regex value to "" and are doing the following  
in most lists' send scenarios:

  match([sender], /^(mailer-daemon|listserv|majordomo|smartlist| 
mailman|[conf->email])(\@|$)/) smtp,smime,md5 -> reject,quiet

On the lists where we want to receive those messages then we simply  
use a scenario which doesn't include that directive.

Please let me know what you think, or if anyone needs anything else  
from me on this.

Thanks,
Jeff

Attachment: loop-prevention.patch
Description: Binary data

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