The issues are: 1. What is the cost or risk of a false positive?
2. What is the cost/risk of a false negative 3. What are the probabilities for each. Using a spam folder rather than rejection increases the risk of losing legitimate e-mail with no notice. It also increases the risk that someone will open a malware message, falsely believing it to be erroneously in the junk folder. On the flip side, rejecting suspect spam has the risk that the sendeer's e-mail software is broken and fails to notify hime of the 5xx response. Most of us receive legitimate e-mail from previously unknown legitimate senders. Using, e.g., a DNSBL to flag tainted sources and generating an appropriate 5xx can have a much lower risk than a spam folder or silently dropping. It all comes down to what has the lowest cost/risk in a given environment; any action, including inaction, will have costs and risks. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of CM Poncelet <ponce...@bcs.org.uk> Sent: Thursday, September 24, 2020 4:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Caution: "Hacked" email caused the distribution of a potentially harmful attachment The whitelist is created step-by-step by the end-user, as message filters, by checking through the trash folder and recognizing which received emails are *not* SPAM/scam. It's a "learning curve." Phony emails that conform to the rules (as in from spoofed senders' email IDs) should be reported to Spamcop and, with some adequate reasoning (as in "if not this *and* also that etc."), can then be trapped and dropped in the trash folder. For what my experience of anti-spam software is worth, I have regularly received spam/scam emails whose headers contained something like "Spamassassin score 4.7, 5.0 required" and which were thus allowed through as legitimate emails even though they were not. Perhaps RACF does it better than ACF2 now. But in the 80's only ACF2 blocked everything unless an explicit rule allowed it - which is why security conscious companies chose ACF2 instead of RACF (in those days.) I would still choose ACF2 or TSS over RACF. But thanks anyway for the 'update' ;-) On 24/09/2020 12:40, R.S. wrote: > W dniu 24.09.2020 o 03:10, CM Poncelet pisze: >> All software filters are fundamentally flawed, because they presume to >> recognize and 'understand' what is or not SPAM - which is logically >> impossible. The only reliable filter is the hardware one, which assumes >> by default that every received email is SPAM *unless* a message filter >> rule says it is legitimate. That is how ACF2 enforced security - by >> denying any access to a resource unless an ACF rule permitted it. > > How do you create whitelist? > What if phony email conform the rules? > > No, spam-nospam decision is "fuzzy logic". Commercial filters may use > some input from provider, something like virus definition. There are > some popular spam (or malicious msg) messages with some characteristics. > > BTW: RACF does it better than ACF2 - while it is possible to deny by > default, usually the decision is left to resource owner, who knows > better what to do. ;-) > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
