Actually I am trying to write one rule in local.cf spamassassin.
What I need is to block all Viagra emails.
As you know in these emails they write Viagra,VIAGRA,VIAGRA(c) sometimes in the Subject field, sometimes in the Name field, sometime it is the body of the message.
Can you please tell me what will be rule exactly to stop all these emails?
Well, you can try these kind of simple rules:
header VIAGRA_SUBJECT Subject =~ /viagra/i
header VIAGRA_FROM From =~ /viagra/i
meta VIAGRA_HEADER VIAGRA_FROM && VIAGRA_SUBJECT
score VIAGRA_HEADER 10.0
describe VIAGRA_HEADER Block Mails with Viagra in subject
body VIAGRA_BODY /viagra/i
score VIAGRA_BODY 10.0
describe VIAGRA_BODY Block Mails with Viagra in body
I have two more to add:
body LOCAL_OBFU_VIAGRA /(?:\b[vu]|\B(?:\\\/|\xCE\xBD))[\W_]{0,3}(?:[il1:\|\*\xCC-\xCF\xEC-\xEF\xA6]|\xC4[\xA8-\xB0]|\xC4\xBA|\xC4\xBC|\xC4\xBE|\xC5\x80|\xC5\x82|\xC7[\x8F-\x90]|\xD0[\x86-\x87]|\xD1[\x96-\x97]|\xCE\x8A|\xCE\x90|\xCE\x99|\xCE\xAA|\xCE\xAF|\xCE\xB9|\xCF\x8A)[\W_]{0,3}(?:[a4\*\#\xC0-\xC5\xAA\xE0-\xE5]|\/\\|\xC4[\x80-\x85]|\xC7[\x8D-\x8E]|\xC7[\xBA-\xBB]|\xCE\x86|\xCE\x91|\xCE\x94|\xCE\x9B|\xCE\xAC|\xCE\xB1|\xD0\x90|\xD0\xB0)[\W_]{0,3}(?:[g6]|\xC4[\x9C-\xA3]])[\W_]{0,3}(?:[r\xAE]|\xC5[\x94-\x99]|\xD1\x93)[\W_]{0,3}(?:[a4]\b|(?:[\*\#\xC0-\xC5\xAA\xE0-\xE5]|\/\\|\xC4[\x80-\x85]|\xC7[\x8D-\x8E]|\xC7[\xBA-\xBB]|\xCE\x86|\xCE\x91|\xCE\x94|\xCE\x9B|\xCE\xAC|\xCE\xB1|\xD0\x90|\xD0\xB0)\B)/i
score LOCAL_OBFU_VIAGRA 1.8
describe LOCAL_OBFU_VIAGRA Obfuscated 'VIAGRA' in body
The rule above will block obfuscated "Viagra" in the body of the message. The following rule does the same sort of thing but with special characters spelled out:
describe MANGLED_VIAGRA mangled viagra
body MANGLED_VIAGRA /(?!viagra)v{1,3}(?:[_\W]{0,5}|[viagra])[iÌÍÎÏìíîï\|1l\!](?:[_\W]{0,5}|[viagra])[aÀÁÂÃÄÅàáâãäå4\#](?:[_\W]{0,5}|[viagra])g(?:[_\W]{0,5}|[viagra])r(?:[_\W]{0,5}|[viagra])[aÀÁÂÃÄÅàáâãäå4\#]/i
score MANGLED_VIAGRA 2.5
Related
I was trying to use SSML syntax while filling out the Alexa blueprint skill form but then I got an error. Is there a way the form can support SSML?
Entry:
<amazon:effect name="whispered">I am not a real human.</amazon:effect>.
Error:
Special characters are not supported. However, Alexa can speak special characters ( # # $ % _ + = | ; ), if enclosed in single quotes ( '#' ).
Sorry, but (currently) you can only use PlainText in blueprint based skills, because (as you mentioned the error message) the special characters needed for an XML based syntax are not supported by the form.
Just an additional hint to your SSML text, if you want to use it in a regular skill:
As a XML based syntax it needs embracing speak tag and no outside/final dot.
<speak><amazon:effect name="whispered">I am not a real human.</amazon:effect></speak>
https://developer.amazon.com/en-US/docs/alexa/custom-skills/speech-synthesis-markup-language-ssml-reference.html
I would like to block some kind of emails using angular ng-pattern
The emails below should not be valid
info#anything.com
admin#anything.com
help#anything.com
sales#anything.com
The regex below worked
^((?!info)(?!admin)(?!help)(?!sales)[a-zA-Z0-9._%+-])+#[a-zA-Z0-9.-]+\.[a-zA-Z]{1,63}$
But not as I expected because I wold like to allow i.e
information#anything.com
How can I block the info#, admin#, help#, sales#?
Thanks
You may join the lookaheads into 1 and add # after the values to ensure you match the user part up to # (as a whole):
/^(?!(?:info|admin|help|sales)#)[a-zA-Z0-9._%+-]+#[a-zA-Z0-9.-]+\.[a-zA-Z]{1,63}$/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See the regex demo
The (?!(?:info|admin|help|sales)#) negative lookahead fails the match if, after the start of a string (^), there is info# or admin# or help#, or sales#.
I am passing a JSON array object in the HTTP POST as
[{"level":"INFO","data": "Test 1"},{"level":"INFO","data": "Test 2"}]
This message is seen as 1 object/log message in SumoLogic. How can I tell SumoLogic to consider each JSON object as an independent object and show 2 log messages instead of one?
I believe this can't be done with the json operator. But, have a look at the docs for the "parse regex" operator. There's an option called "multi" which creates a new message for each match of the regex. In your case, something like this might do the trick:
parse regex "\{?<fieldname>.*?\}" multi
I didn't try this in the product itself, but here is Regex101 link to play with the regex.
I believe the actual answer to this is to not send your logs as an array. Instead include each json object in your body with a '\n' at the end for Sumo to consider these as individual log messages.
{"level":"INFO","data": "Test 1"}\n
{"level":"INFO","data": "Test 2"}\n
I'm running into a problem with the __ function, and I'm not sure whether it's a bug in Cake (3.2.8), Aura\Intl, or my code. I've tried the same thing in Cake 1.3, and it works as I expect it to, but it's possible that my expectations are simply that way because that's how it worked in 1.3. :-)
When I am building my menus, I use things like __('Teams'), but I also have pages that use things like __n('Team', 'Teams', count($player->teams)). The i18n shell extracts these into the default.pot separately, so when I translate it to French, it's like this:
msgid "Teams"
msgstr "Équipe"
msgid "Team"
msgid_plural "Teams"
msgstr[0] "Équipe"
msgstr[1] "Équipes"
If I call __('Team'), I correctly get 'Équipe' returned, and if I call __n('Team', 'Teams', $x), I correctly get 'Équipe' or 'Équipes' returned, depending on the value of $x. But if I call __('Teams') I get back
Array
(
[0] => Équipe
[1] => Équipes
)
This is the case even if I eliminate the msgid "Teams" section, leaving only the plural definition.
In Cake 1.3, __('Teams') would simply return 'Équipes'. (Don't know what it might do in 2.x, as I skipped over that entirely.) So, whose bug is this?
You have two Teams message IDs. The problem is that the CakePHP message file parser stores the messages in a key => value fashion, where the message ID is used as the key, resulting in the Teams messages for msgid_plural to override the Teams message from the preceding msgid.
https://github.com/cakephp/cakephp/blob/3.2.8/src/I18n/Parser/PoFileParser.php#L149
https://github.com/cakephp/cakephp/blob/3.2.8/src/I18n/Parser/PoFileParser.php#L172
https://github.com/cakephp/cakephp/blob/3.2.8/src/I18n/Parser/MoFileParser.php#L137-L140
Since gettext seems to be able to handle this, I'd say that it's at least a missing feature (which might be intentional), however it might even be a bug, I can't tell for sure (but I'd tend towards bug). For clarification, open an issue over at GitHub.
To (temporarily) workaround this issue you could use contexts.
Duplicate message definition
This is problematic:
msgid "Teams" <- same string
msgstr "Équipe"
msgid "Team"
msgid_plural "Teams" <- same string
The first means you have or are expecting to have __('Teams') in the application code, which expects to return a string.
The second scenario is going to create ambiguous data when the po file is parsed. The class responsible for converting po files to the array format is the PoFileParser, which contains these lines:
$messages[$singular] = $translation; // <- a string
...
$messages[$key] = $plurals; // <- an array
Where $messages is the array used to lookup translations, indexed by the translation key.
So, the reason for the observed behavior is because this code:
__('Teams');
is going to look for $messages['Teams']
This code:
__n('Team', 'Teams', 2);
is going to look for $messages['Teams'][<index>], and the $messages array is going to contain the parsed data from the plural translation only, which overwrote the "singular" version of the string as it was earlier in the file.
The code-level solution is to ensure that all msgid and msgid_plural keys are unique (since they are essentially, the same thing).
Bad translation definition
You may well find at some point in the future that translations like __('Teams') are very problematic, depending on how that loose word is being used, they are an indicator of bad translation definitions.
To give an example, CakePHP used to have translations of this form in baked output:
...
sprintf(__('Invalid %s', true), 'Team');
...
Which was later changed to:
__('Invalid Team', true)
Because the translation of Invalid %s can change depending on what %s is - so can the translation of %s.
I'm trying to store email addresses in Salesforce.com from another service that allows invalid email addresses to be specified. If one of those bad invalid email addresses is sent to Salesforce.com via their Web Services API, Salesforce.com will prevent the record from saving with an INVALID_EMAIL_ADDRESS error code.
I can't find any documentation on how to disable validation on Email fields, so it looks like I'll need to validate them in my integration and pull out those that fail. Does anyone know the validation process Salesforce.com uses to determine if an email address is valid? All I have right now is a Regex, but I'd like it to match Salesforce.com's process.
EDIT: For reference, here is my Regex (I'm using C#/.NET):
^(\w|[!#$%'*+-/=?^_`\{\}~.&])+#\w+([-.]\w+)*\.\w+([-.]\w+)*([,;]\s*\w+([-+.]\w+)*#\w+([-.]\w+)*\.\w+([-.]\w+)*)*$
Summary: we're using the following .NET RegEx:
const string SFEmailRegExPattern = #"^[A-Z0-9._%-]+#[A-Z0-9.-]+\.[A-Z]{2,4}$";
If you can believe SF's own documentation then:
For the local part of the email address we accept the following characters. The local part is anything before the # sign.
abcdefg.hijklmnopqrstuvwxyz!#$%&'*/=?^_+-`{|}~0123456789
Note: The character dot . is supported; provided that it is not the first or last character in the local-part
For the domain part of the email address we accept. The domain part is anything after the # in an email address:
0-9 and A-Z and a-z and dash -
A couple of people have coded this up as a Java regex as:
String pat = '[a-zA-Z0-9\\.\\!\\#\\$\\%\\&\\*\\/\\=\\?\\^\\_\\+\\-\\`\\{\\|\\}\\~\'._%+-]+#[a-zA-Z0-9\\-.-]+\\.[a-zA-Z]+';
although to me this looks like it fails to reject an email that starts with a "." so isn't perfect.
I don't know how salesforce.com is validating email addresses, but since you are using .NET I'd suggest you to consider an email validation component like our EmailVerify.NET, which is 100% compliant with the current IETF standards (RFC 1123, RFC 2821, RFC 2822, RFC 3490, RFC 3696, RFC 4291, RFC 5321, RFC 5322 and RFC 5336) and does not suffer from ReDoS: if needed, it even checks the DNS records of the email domain under test, its SMTP availability, validates the related mailbox and can even tell if the target mail exchanger is a catch-all or if it is a disposable/free email address provider.
I don't know what salesforce.com uses (and I don't think there's any way for you to find out), but \b[A-Z0-9._%+-]+#[A-Z0-9.-]+\.[A-Z]{2,4}\b from here is a commmon one and should work for most of the cases.
I've looked previously and not been able to find a definitive answer on exactly which rules SFDC applies to the native "Email" field type. The quickest path to success that I would suggest would be this:
in your initial data integration from the external application, map the email field that you describe into a new (non-email, just text 255) custom field in SFDC.
if this is a one-time dataload, run a separate process that, for every row in SFDC with this custom field populated, attempts to copy the contents of this custom field to the native email field. If any row fails with the email validation error, you just skip it. Then you can decide what to do with the non-compliant addresses.
if this is an ongoing integration, it may be better to do something like attempt to insert new rows one-at-a-time via WS API, and if the email validation exception is thrown, you catch it and either insert the record without an email address, store the bad email in a different field (like a custom field called "non-compliant email address"), or skip the row altogether (if bad emails == bad record).
Hope that helps.
Apex has native Pattern and Matcher classes, based on java.
You can validate your email addresses in Apex code, using your RegEx expression as a string
String emailPattern = {your regex expression);
Boolean validEmail = pattern.match(emailPattern, emailAddress);
You can't definitely create common regex for salesforce email, due to inconsistency of their own requirements.
The one rule is about to give possibilities to put IP address after the local part. Example -> email#123.123.123.123.
The second is about do not allow digits in top-level domain.
For example: test#test.com1
So, they are mutually excluded.
But as I understood the email address with IP after the local part is more important and commonly used comparing with numbers in top-level domain.
Here is some examples of valid/invalid emails for salesforce.
Valid:
a#ua.fm
email#domain.com
firstname.lastname#domain.com
email#subdomain.domain.com
firstname+lastname#domain.com
email#123.123.123.123
1234567890#domain.com
email#domain-one.com
_______#domain.com
email#domain.name
email#buyacar.co.uk
ail#github.dennis.co.uk
email#news.i.ua
firstname-lastname#domain.com
Alexka1!+1123klsn&*^%$%$#^^^#a3432.4s.c4p.uk
frw...??//||/wt'f`fe#wfwfg-----wfwef.mm
a..#test.jp
abcdefg.hijklmnopqrstuvwxyz!#$%&'*/=?^_+-`{|}~0123456789#acme-inc.com
Invalid:
aasd#sdfжжж.rf
plainaddress
##%^%#$##$##.com
#domain.com
email.domain.com
email#domain#domain.com
.email#domain.com
あいうえお#domain.com
email#domain.com (Joe Smith)
email#domain
email#domain..com
email#domain.com.e
email#domain.com.33
As result of above, the final regex is:
/^(?!\.)(([^<>()\[\]\\a-zA-Z0-9.,;:\s#"]*(\.[^<>()\[\]\\.,;:\s#"]+)*)|(".+"))[a-zA-Z0-9.!#$%&'‘*+\/=?^_{|}~-]+#[\w.-?]+.[A-Za-z]*(?
Here is a regular expression based on this help page + a lot of experimenting in Salesforce:
^(?=(?:\([^)]*\))*[^()]+[^#]*#)(?!(?:\([^)]*\))*\.)(?:(?:[\w!#$%&'*+-/=?^`{|}~]|\([\w!#$%&'*+-/=?^`{|}~]*\))+|"(?:[\w!#$%&'*+-/=?^`{|}~]|\([\w!#$%&'*+-/=?^`{|}~]*\))*")#(?:\([A-Za-z0-9-]*\))*(?:(?:[A-Za-z0-9]+|[A-Za-z0-9]+(?:\([A-Za-z0-9-]*\))*-(?:\([A-Za-z0-9-]*\))*[A-Za-z0-9]+)(?:\([A-Za-z0-9-]*\))*)(?:\.(?:\([A-Za-z0-9-]*\))*(?:(?:[A-Za-z0-9]+|[A-Za-z0-9]+(?:\([A-Za-z0-9-]*\))*-(?:\([A-Za-z0-9-]*\))*[A-Za-z0-9]+)(?:\([A-Za-z0-9-]*\))*))+$
See this Demo. It gives the same validation result as Salesforce for all the values I could think of testing - copied below - any counter examples are welcome...
************* VALID *************
a#a.a
-#a.a
a#1.a
a#a-a.a
a#a.a-a
!#$%&'*+-/=?^_`{|}~#test.jp
a..a#test.jp
a..#test.jp
"a"#test.jp
""#test.jp
(comment)(comment)a(comment)(comment)(comment)#(comment)a.a
(comment)(comment)a.(comment)(comment)(comment)#(comment)a.a
(comment)(comment)a(comment).(comment)(comment)#(comment)a.a
a#(comment)a(comment)-(comment)a(comment).a
john.doe#(-comment)example.com
john.doe#example.com(comment-)
()a#test.jp
(a)a#test.jp
a(a)#test.jp
a#(a)test.jp
a#test.jp(a)
simple#example.com
very.common#example.com
disposable.style.email.with+symbol#example.com
other.email-with-hyphen#example.com
fully-qualified-domain#example.com
user.name+tag+sorting#example.com
x#example.com
example-indeed#strange-example.com
test/test#test.com
example#s.example
"john..doe"#example.org
mailhost!username#example.org
user%example.com#example.org
user-#example.org
1#1234567890123456789012345678901234567890123456789012345678901234.1.2.3.4.5.6.7
************* INVALID *************
a#a
a#a.
a#-a.a
a#a-.a
a#a.a-
a#a.-a
a;a#test.jp
.a#test.jp
";"#test.jp
"#"#test.jp
"a#test.jp
a"#test.jp
a""#test.jp
""a#test.jp
()#test.jp
)(a#test.jp
(a)#test.jp
(a#test.jp
(())a#test.jp
(comment)(comment).(comment)a(comment)(comment)#(comment)a.a
john.doe#(comment).com
a#(comment)a(comment)-(comment)(comment).a
Αθήνα#email.com
admin#mailserver1
" "#example.org
"very.(),:;<>[]\".VERY.\"very#\\ \"very\".unusual"#strange.example.com
postmaster#[123.123.123.123]
postmaster#[IPv6:2001:0db8:85a3:0000:0000:8a2e:0370:7334]