evanevery said:

- Users get mail from "Bob@imaspammer.com"

- Users add "bob@imaspammer.com" (or *@imaspammer.com") to their personal QMS Blacklist

- However, SMG does not block additional messages from the specified sender

When a user blacklists a sender future email from that sender is blocked only if the exact "from" and "to" email addresses match the one being blocked.

If you look at bulk email and other spam you will see that the actual sender's email address is a long string of characters and not just "bob". Since the"from" address on new email is different from the original one, it won't be blocked.

Actually, its a little different than that.  SMG doesn't use the "From" field at all. 

I know exactly what the issue is and even filed a ticket on it.  However, I thought we got past the issue but apparently not.  Without digging too deep into the details of why the Blacklist is broken - it doesn't really matter!

- Users get an email FROM someone.

- Users want to block mail FROM that person.

- All a user see's and understands is the FROM field (and SMG doesn't use it)

Users are given a personal Blacklist they can maintain.  The only problem is doesn't work FOR the users or how the users would expect!

WHY doesn't the QMS user Blacklist (and Whitelist) use the FROM Field?  WHY should a user HAVE to be trained to parse the MIME headers if they want to blacklist some email sender?  Why doesn't the blacklist use the SAME FIELD that the user see's and understands?

evanevery said:

WHY doesn't the QMS user Blacklist (and Whitelist) use the FROM Field?  WHY should a user HAVE to be trained to parse the MIME headers if they want to blacklist some email sender?  Why doesn't the blacklist use the SAME FIELD that the user see's and understands?

Yes, those are indeed good questions.

Have you opened a case for this? What response did you get from support?

evanevery said:

WHY doesn't the QMS user Blacklist (and Whitelist) use the FROM Field?  WHY should a user HAVE to be trained to parse the MIME headers if they want to blacklist some email sender?  Why doesn't the blacklist use the SAME FIELD that the user see's and understands?

Yes, those are indeed good questions.

Have you opened a case for this? What response did you get from support?

Yes, I opened a case.  After fighting to pierce the tech support veil, the issue was finally put before the developers.  The response I got back was it was "functioning as designed".  To which I replied, then its "designed wrong".  "Functioning as designed" is a BS developers excuse which basically means "I don't want to fix it"... 

No one would ever explain why that was an appropriate design choice (as they obviously have no logical basis to defend this) and case eventually got closed.

If you give users access to a tool, then the tool should work FOR the users.  Users should not have to be trained to decode MIME/SMTP headers when all they want to do is block email FROM a specific (or wildcarded) sender.  When a user looks at an email, all they see is the FROM field.  Why not use it?  WHY NOT?

In fact, the decision that the developers chose actually causes MANY problems (besides NOT working in the interest of users).  Their decision actually makes it impossible to block email from a specific sender without ALSO blocking email from legitimate senders!

(I've written a little utility to parse the MIME headers in an email message just to extract and record the necessary data to a spreadsheet. I'm collecting all the data just to document the issues. SMG uses the MIME "Return-path:" and not the "From:" field.  Its that simple.  Sometimes they are the same but often they are not.  Not only does this NOT work in the interest of users but it also causes a couple of problems!   ;-)