[imp] newbie: How to make proper spam settings

[Jens-Uwe Mozdzen]

Hi Michael, Chuck, *,

Quoting Michael M Slusarz <slusarz at horde.org>
> Quoting Jens-Uwe Mozdzen <jmozdzen at nde.ag>:
>
>> Hi Michael,
>>
>> Zitat von imp-request at lists.horde.org:
>>
>>> Your original configuration didn't contain a spam action, either
>>> sending via e-mail or reporting via a program.  That's why nothing
>>> happened.  You obviously can't mark a message as spam unless some
>>> system actually processes the spam report.
>>
>> Yes, but that's totally out of the scope of both Horde and this
>> discussion: There is a spam action wanted by the user - moving the
>> message to the declared spam folder. Unless the admin sets
>> "$conf['spam']['reporting'] = true;", the user won't have any ui
>> option of marking the message as spam.
>
> This logic is incorrect.  A user's primary goal when marking spam is
> to cause it to be analyzed by some system so that an identical message
> (or a message like it) is blocked in the future.

I mostly agree - and in our case that's a back-end system sitting in  
some remote shelf and picking up messages via IMAP from specific spam  
folders...

Obviously we're not the only ones with such a way of handling it (and  
I know a few other companies as well):

Quoting Chuck Hagenbuch <chuck at horde.org>
> I have a shared spam folder set up; any message moved there gets
> scanned by a central SpamAssassin program. So I disagree that this is
> equivalent to a delete action - what the user means is report spam,
> and they shouldn't necessarily have to worry about which folder, doing
> the move/delete, etc.
>
> -chuck

Quoting Michael M Slusarz <slusarz at horde.org>
> Defaulting spam reporting to simply moving a message to another
> mailbox is nothing more than a "delete" action.  Which we already have.

I full-heartedly disagree. In addition to the case described above,  
another use(r) case is "to move messages out of sight" and to handle  
them later. As you might know it is legally risky in i.e. Germany to  
completely filter out spam messages - corporate solutions typically  
avoid this by moved suspected spam messages to a dedicated,  
user-accessible folder, to keep suspected spam out of the inbox.  
Which, by the way, is the purpose behind IMP's user-land configurated  
spam handling: If it's marked as spam (i.e. externally), get it out of  
sight.

> Quoting Jens-Uwe Mozdzen <jmozdzen at nde.ag>:
>> Unless you change your mind and follow my proposal, I opt for
>> warning the admin that you believe the configuration contains an
>> error - neither email address nor external action set. That way the
>> admin will notice and can work around this design limit.
>
> If you want to suggest additional text to put into conf.xml, that
> would be appreciated.  However, we are not going to add code that
> checks for this and throws an error everytime a spam message is
> reported.  That is totally unneeded overhead.

I fully agree - it's the former I was after. Currently I'm not  
experienced enough with the conf.xml syntax to know how to implement  
this, so I cannot just propose a patch. Can you point me at either a  
conf.xml section where such handling (issue a warning under certain  
conditions) was implemented or at a helpful piece of documentation? Or  
should I just open a RFE?

Quoting Michael M Slusarz <slusarz at horde.org>, responding to Chuck  
Hagenbuch <chuck at horde.org>
> But you had to do something proactively outside of the setup of Horde
> to get this to work.  So you have verified that this setup does,
> indeed, work and that you want to use it.
>
> If an admin is comfortable with providing a feature that admittedly
> does NO spam reporting by default, that should be their decision and
> they can configure to do this.  But this in no way should be the
> default.  And that's what the OP was asking for.

I should work on my language skills ;) - I tried to mention in my  
earlier message that there's an external system acting on the contents  
of the user spam folders. Obviously, I wasn't clear enough.

I'm fine with the config.xml warning though - being knowledgeable  
enough to set up such a system allows to recognize that a "no-op  
program" (/bin/true) would fit in fine. Without that warning, it just  
took some time to put together the pieces...

Regards,
Jens
-- 
Jens-U. Mozdzen                         voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG      fax     : +49-40-559 51 77
Postfach 61 03 15                       mobile  : +49-179-4 98 21 98
D-22423 Hamburg                         e-mail  : jmozdzen at nde.ag

         Vorsitzende des Aufsichtsrates: Angelika Mozdzen
           Sitz und Registergericht: Hamburg, HRB 90934
                   Vorstand: Jens-U. Mozdzen
                    USt-IdNr. DE 814 013 983