[Mimedefang] action_drop_with_warning and refuse to sender

Kris Deugau kdeugau at vianet.ca
Mon Aug 27 18:21:59 EDT 2018

Marcus Schopen wrote:
> Am Freitag, den 24.08.2018, 10:50 -0400 schrieb Dianne Skoll:
>> I think this is a terrible idea for two reasons:
>> 1) What is the recipient supposed to do with the notification?  Most
>> recipients are not technically savvy and are more likely to panic
>> than
>> do anything else.
> That might me right in most of the cases. But if you do a "silent"
> reject, this has to be communicated very clearly to the recipient,

What's your reasoning for this?

Here's my own reasoning behind *not* notifying the recipient on flagging 
a message:  In the early 2000s I set up a filter service for the ISP I 
was working for, that initially either passed on a "disinfected" message 
or notified the recipient in the event of a virus message.  The original 
service used a commercial AV package with a milter daemon with a limited 
selection of behaviours, although I eventually switched to MIMEDefang 
for better flexibility.

That configuration lasted maybe a couple of months before the complaints 
got to be too much trouble, and we switched to either silently discard 
or reject (can't recall which now).  *Nobody* wanted to get notices 
about a blocked or deleted virus.

I can see value in having a filter system send a *summary* message 
listing "things caught in the last $timeperiod", on the *inbound* side, 
but one notice per blocked message really doesn't work well if there's 
any substantial volume of mail blocked;  it sort of defeats the point. 
And notifying arbitrary third parties who can't actually do anything to 
your filter (they don't have an account on your system, the sender does) 
just creates noise.

> as
> well as rejecting at a spamassassin score of >= 5. This is nothing you
> can decide on your own as postmaster, just because it makes sense.

"My system, my rules."  We block high-scoring outbound mail so that our 
server doesn't get permanently blacklisted, thereby blocking our 
customers' legitimate email from reaching recipients.

Notifying recipients would be almost as bad as just letting everything 
through;  the notices are so rarely useful they'd likely end up.... 
handled as spam on the *recipient's* server as well.

>> 2) Unless you do some sort of rate-limiting, a poor recipient may
>> find
>> herself swamped with emails to the effect "You almost received a
>> virus, but we cleverly stopped it!"
>> IMO, REJECT is the way to go.  In the 99.99% of cases where it was a
>> virus,
>> nobody will see the failure notification... but nobody needs to.  In
>> the
>> rare case of a false-positive, the sender will see the failure
>> notification
>> and can pursue further action.
> I agree that most detected virus mails (I use clamav) are virus mails.
> But I myself got some valid emails from Amazon, which were marked as
> "Heuristics.Phishing.Email.SpoofedDomain" and therefore those emails
> were rejected. My mimedefang-milter configuration was set to bounce,
> so I didn't know I got these false-positives. It was just luck that I
> found those emails when checking "/var/spool/MD-Quarantine/".

For that particular case, I've been running our outbound MD filter set 
to flag that specific test and tweak the SpamAssassin results instead of 
hard-blocking precisely because of FPs like you mention.  I'd strongly 
recommend doing something similar to anyone calling Clam from MD;  check 
for that specific "virus" and do some additional tests somewhere to 
verify if it's really malicious or Just Another Big Company Doing 
Something They Probably Shouldn't.

On the inbound side, where all filtering is done from custom code on 
final delivery, I turned it off in the main Clamav instance, and set up 
a secondary one with this test and a selected list of risky third-party 
signatures - but NOT the stock signatures - that's called from 
SpamAssassin and scored depending on the resulting "virus name".


More information about the MIMEDefang mailing list