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".
-kgd
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
