On 07/17/2009 08:11 AM, Peter Funk wrote:

>> My point is that there are people who set up Roundup to send mail to
>> lists, and there is no reason to set such a policy inside the Roundup
>> core that breaks that.
>
> Understood.  But IMHO the default behaviour should remain as is.
> Suppressing this header should be a configurable option.

That's my point exactly: Right now this is not only 'default behavior', 
it is not configurable at all ! Taking it out of Roundup's own code, 
putting it into detectors (nosyreactor, say), is precisely what I'm 
proposing.

> Adding a global config option to the mailer class would be simple. But
> the inclusion of the bulk-header should depend on the recipient of
> the message: If you have a mailing list as nosy recipient, other
> nosy users might have auto responders installed, that suppress their
> action only if they see a Bulk header.

Those users may change their filter, as a mail coming from a Roundup 
tracker can easily be detected otherwise.

>  Unfortunately currently the
> mailer class sends a message to all recipients at once.  Making the
> presence of the header dependent on the recipient would require to
> split the nosy list in two parts. :-(

That's a good point, and one for which we have multiple open issues. It 
would be good to be able to refactor the mail handling so it becomes 
configurable. Nosy mails may be sent individually, or grouped, or...

> What about mailgw.py?  If you use a mailing list as recipient, then
> other paople might want to do the opposite and want to put a roundup
> tracker instance as recipient on a mailing list.  Currently the
> ignoring of bulk-messages in mailgw.py is also hard coded:
>
>          ...
>          # detect Precedence: Bulk, or Microsoft Outlook autoreplies
>          if (message.getheader('precedence', '') == 'bulk'
>                  or subject.lower().find("autoreply")>  0):
>              raise IgnoreBulk
>          ...

Hmm, that looks a lot more reasonable to me. But again, this may 
arguably belong into a configurable policy. But this is a different 
issue. :-)

Thanks,
		Stefan