[Mimedefang] Questions about stream_by_recipient and problems it creates.

[Matthew Schumacher]

David F. Skoll wrote:
> Matthew Schumacher wrote:
> 
>> Here is a thought, what about declaring which users accepted and which
>> rejected in the rejection message.  So if recipient A wants everything
>> tagged and recipient B wants spam rejected, then we reject the message
>> with "Recipient B thinks this is spam (message was delivered to other
>> recipients)" then in filter_end we queue the message for recipient A.
> 
> [...]
> 
>> Do you think this will work?
> 
> In one sense, it will work.  However, in a very important sense, it will
> fail miserably.  Most senders don't have a clue how to interpret a DSN,
> even assuming their mail server preserves the text of the DSN.  You'll
> be flooded with support queries.
> 

David,

I appreciate your comments, however, I've found the opposite to be true.
 During the last 2 years we have had the helpdesk email in the DSN error
message so that people can request help with spam filtering.  This has
lead to quite a number of emails asking for help, which makes false
positives easy to troubleshoot since the helpdesk can simply open the
header and see the SA report.  In fact, I can't think of any support
request for a false positive issue that wasn't sourced from someone
reading the DSN.

Silently discarding the email will require us to have some sort of
rejected email browser or some other way for the user to know what
happened. I'm slow to implement this as our rural Alaskan users already
complain that a spam filter sensitivity, whitelist, blacklist, and allow
exe settings are already too complex.

I'll probably try the DSN thing.  Perhaps I'll report my experience back
to the list.

Thanks,
schu