Apex Code Development You need to sign in to do that
Don't have an account?
noedskovatunity How to handle SPAM properly when working with cases?!
When you start using cases in SF you usually setup auto-response rules to automatically respond to your clients. In doing so, you are forced to setup loads of exception rules to prevent SPAM. Not only the auto-response rules have to take this into consideration but also the case assignment rules have to implement these exceptions.
As a SF administrator you feel like you're fighting a battle that simply cannot be won. Once you've implemented an exception rule for one domain 10 others have surfaced.
And, if you're really lucky, SF will go into what nearly seems like an infinite loop where loads and loads of cases are created. E.g. a case is created from a SPAM email (because no exception rule was implemented), the auto-response rules reply back, that email is bounced and returned to SF which then, for some reason, is not linked to the original case but a new case is created and the process basically starts all over again.
After briefly speaking with SF Support about this issue the answer was that they were also fighting that problem and handling it the same way (i.e. by setting up assignment rules and auto-response rules).
Is that really the best way to go about this? I find that very hard to believe and would appreciate any input you guys may have on the subject.
Cheers.
Søren Nødskov Hansen
As a SF administrator you feel like you're fighting a battle that simply cannot be won. Once you've implemented an exception rule for one domain 10 others have surfaced.
And, if you're really lucky, SF will go into what nearly seems like an infinite loop where loads and loads of cases are created. E.g. a case is created from a SPAM email (because no exception rule was implemented), the auto-response rules reply back, that email is bounced and returned to SF which then, for some reason, is not linked to the original case but a new case is created and the process basically starts all over again.
After briefly speaking with SF Support about this issue the answer was that they were also fighting that problem and handling it the same way (i.e. by setting up assignment rules and auto-response rules).
Is that really the best way to go about this? I find that very hard to believe and would appreciate any input you guys may have on the subject.
Cheers.
Søren Nødskov Hansen
There is a way to add hidden fields to your Web to Case or Web to Lead pages to block spam. Here's what's in the Help & Training on SF support.
How to resolve Web to X Spam issues?
Once an Org_ID becomes known to a 3rd party it becomes possible for that Org to submit unsolicited Leads to the Web to X servlet.
The problem can be resolved adequately by:
1. Employing standard Salesforce filtering and validation functionality.
2. Creating an extra field which is hard for SPAM bots to fill out.
Outline
======
1. Create a new field on the entity which is effected by SPAM.
The field can be hidden by:
---------------------------
a) Submitting your Web to Lead form to Salesforce from an intermediate server.
b) Using javascript to obfuscate or hide the new field making it hard for a SPAM bot to set it.
(See attached HTML file for example)
2. On your Web to Lead form set this new field with a value which distinguishes valid leads from SPAM leads (this can be an arbitrary value : IP address, document location or Salesforce picklist value for example).
3. Create a routing rule or a validation rule which filters on:
a) The value submitted in 2 above.
b) Another value which identifies the records as having been submitted from the Web to X servlet.
Such as Case Origin = Web.
(Instead of a validation rule a routing rule can be used which places all email determined to be SPAM in a particular queue from which it can be deleted)
e.g Field Validation Filtering
====================
1. Create a field of type picklist called "Checked For Spam".
2. The picklist should have one value "Yes" and the default value should be set to "Yes" on all record types.
3. Then make sure that the field is added to all page layouts and placed low on the page in a separate section so it is out of the way.
4. Create a validation rule on the relevant object as follows:
NOT(ISPICKVAL( checked_for_spam__c ,"Yes"))
5. The validation rule will result in debug messages sent to the default case user email but you can set a rule based in the validation error message to delete it.
e.g Field hiding
================
see attached HTML form:
-substitute the custom field '00N20000000idBc' with the filtering field which you create
-substitute "anyorgid" with your own org id
Hi tstrong,
Thanks for the input.
The Help & Training you refer to is intended for a Web-to-X scenario. I'm trying to solve it for Email-to-X (Email-to-Case to be exact) which is a bit different, I assume, since there are no forms involved (leaving no option for hidden fields etc.).
I find it strange no one else is battling this issue. But if that's the case then I assume I'm doing something wrong.
Again, any help would be appreciated or if someone else could just confirm or deny that they're having the same issues with Email-to-X.
Cheers.
/Søren Nødskov Hansen
Hi Soeren,
Did you ever find a solution to your issue - of course we're all battling it - and it seems incredible that there isn't a solution out there even now.
Best regards
Erik
AND(
ISNEW(),
OR(
CONTAINS(UPPER(Subject),"OUT OF OFFICE"),
CONTAINS(UPPER(Subject),"MAILBOX IS FULL"),
CONTAINS(UPPER(Subject),"UNDELIVERABLE"),
CONTAINS(UPPER(Subject),"RECALL:"),
CONTAINS(UPPER(Subject),"OUT OF THE OFFICE"),
CONTAINS(Subject,"Automatic reply:"),
CONTAINS(Subject,"Auto-Reply"),
)
)
AND(
ISNEW(),
OR(
CONTAINS(UPPER(Subject),"OUT OF OFFICE"),
CONTAINS(UPPER(Subject),"MAILBOX IS FULL"),
CONTAINS(UPPER(Subject),"UNDELIVERABLE"),
CONTAINS(UPPER(Subject),"RECALL:"),
CONTAINS(UPPER(Subject),"OUT OF THE OFFICE"),
CONTAINS(Subject,"Automatic reply:"),
CONTAINS(Subject,"Auto-Reply")
)
)