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?

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!   ;-)

evanevery I agree with you completely.

I've been is this situation before. To cover my bases I've opened a case and created an idea.

You may want to explain the issue here (in great detail) and garner support from the rest of the community.

I already tried that (Search for "Blacklist not working as Expected") and now I'm onto it again (as I personally suffer from lots of holiday SPAM not getting caught by SMG).

Here's the gist of it.  I'll try to make it short...  Return-path: vs From:

1.  Users see the "From:" field in their email message.  Thats what they see = Thats what should be used.  (...and that should be the End of the Story)

2.  But SMG uses the "Return-path:" field (relatively invisible to the untrained user)

3.  If you make your blacklist entry based on the "Return-path:" field it will work.  (Look at your "Message Source" in GW to find this)

BUT HERE ARE THE FUNCTIONAL PROBLEMS WITH THAT:

1.  The casual user isn't normally exposed to that field (and they shouldn't NEED to be)

2.  Additionally many spammers use a mailing service.  The "From" field reflects the spammers email address but the "Return-path" reflects the mailing service.  ...and if you set up your blacklist based on the "Return-path" as (SMG requires), you will end up blocking an entire mailing service.  ...and many of those same mailing services ALSO send out legit email!

Users can't block on the FROM field (SMG doesn't support it).They MUST block on the RETURN-PATH field, and if they do so, they will ALSO block ALL email from legitimate senders who also use the same mailing service!

You want an example? (I found this out the hard way - but its beautifully ironic!)

I wanted to block the following sender (FROM): jwright@firstncc.com

...but i needed to use the Return-path: jwright=firstncc.com__1j3e6p4jq3aeucj5.ljt0f636uly7f1nk@mj5kbaq7muzsqyox.f9zdz.3-x2beau.usa554.bnc.salesforce.com

so I wildcarded the address to: *.salesforce.com"

(as it does absolutely no good to block the entire specific source addresses from a mailer as the mailer uses a unique message/recipient string to track replies to each individual message.  You will simply never see that specific Return-Path field ever used again.)

Anyway, guess who also uses "salesforce.com"?  MICROFOCUS TECH SUPPORT   ...and I noticed this when I stopped receiving replies from MF in reply to this very tech support case!

So, I can't block email from that sender using the Blacklist.  Period.  Because it also blocks legit senders who also use the same mailing service.  I have no choice.  The SMG Blacklist simply doesn't use the FROM field.

If only SMG would work as expected, then it would work as expected.  Its that simple!

Right now I'm just gathering data from emails I wish I could block, including specific Return-path data for spammers and which legit senders also use those services.

I also get a lot of spam with a return path of "*@amazonses.com" but I obviously can't block that email as the amazon mailer is also used by a lot of legit users.

If only the SMG blacklist would use the FROM field (as should be expected)...

So, here is an example of several different messages which a user would like to blacklist.  I have provided both the "FROM" field (which the user would like to block) and the "RETURN-PATH" (which is what the SMG devs have decided to require):

.

.

In these recently received messages, the user would like to Blacklist "*@innovaturebro.com" but can't (cause the SMG Blacklist doesn't use the "FROM" field).  The user would have to Blacklist "*@amazonses.com" but would then also end up blocking legit email from the Amazon mailer (like NVidia):

From: event@innovaturebpox.com
Return-Path: 0100018bf234585-00bc1100-9e35-43e8-b500-3d678ce4441b-000000@amazonses.com

From: event@innovaturebpox.com
Return-Path: 0100018bfc81253-c2ff0126-35bd-4d8e-9206-2eb2381be3ae-000000@amazonses.com

From: event@innovaturebpox.com
Return-Path: 0100018c2088039-18f52084-580e-4767-84a1-5378e96e024c-000000@amazonses.com

From: event@innovaturebpox.com
Return-Path: 0100018c20900ef-0f933220-08b2-4e9c-a348-0447dc90cc42-000000@amazonses.com

From: event@innovaturebpox.com
Return-Path: 0100018c164dc50-fd8ceab6-7b89-45c0-a765-dec7ee2c22cb-000000@amazonses.com

.

.

Here's another where the user would like to block "*@hubiq.co" but can't...

From: hello@hubiqx.co
Return-Path: 0100018c26b389f-95cb4037-20c9-421e-be47-2157f71c350e-000000@amazonses.com

From: hello@hubiqx.co
Return-Path: 0100018c2947349-752f7b36-01ce-44b1-ab7e-3ae111e4ec7d-000000@amazonses.com

From: hello@hubiqx.co
Return-Path: 0100018cb45ee52-9b88c13a-aacf-4fad-8e66-25eb07a90a7a-000000@amazonses.com

From: hello@hubiqx.co
Return-Path: 0100018c3092a27-cdae53b3-7979-435c-811a-1d2914c78a7b-000000@amazonses.com

From: hello@hubiqx.co
Return-Path: 010001c35995805-9eab1c32-05ea-456b-a841-e7d1cb25516a-000000@amazonses.com

.

.

Here's a couple more "Amazonses" emails that the user would like to block but can't...

From: pmosenson@nusparkconsultingx.com
Return-Path: 0100018c19ca0d8-e2722256-e2b0-4855-891b-78e12bfc5f72-000000@amazonses.com

From: sadie.butler@ideawarex.us
Return-Path: 010f018c229283f-1e6baa38-9a64-42a5-b536-2513e9b7f27e-000000@us-east-2.amazonses.com

.

.

Here is a similar situation where the user would like to block some sender's, but Blacklisting some variation of the "Return-path" (salesforce.com) would also end up blocking email from the MICROFOCUS TECH SUPPORT MAILER!

From: matt.harris@leadsroomx.co
Return-Path: matt.harris=leadsroomx.co__0-zdt8jldpoxecdq.bbcikz0hcwapjgr8@w9t1u38yzi7mde0m.a8m0dx.hs-1qu2pmas.na236.bnc.salesforce.com

From: jwright@firstnccx.com
Return-Path: jwright=firstnccx.com__1j3e6p4jq3aeucj5.ljt0f636uly7f1nk@mj5kbaq7muzsqyox.f9zdz.3-x2beau.usa554.bnc.salesforce.com

.

.

As a summary, of the 55 emails we recently identified (email we would LIKE to block):

- 31 of the 55 messages used a RETURN-PATH which was different than the FROM field.  (IOW:  Casual users simply would have absolutely no success in blocking 56% of these messages)

- 16 of the 55 messages use a mailer (in the RETURN-PATH) that, if blocked, would also block other legit email.  (IOW: Even users who understand how to obtain and use the RETURN-PATH field are not able to block these 29% emails cause it would block other legit email messages which use the same mailing service.)

If only we could use the FROM field!  Plain and Simple...

Address information from the MIME message is not used in the black/white listing functionality.  We are working on an enhancement that will allow inclusion of this information for the near future.