I am trying to find out what is the meaning of the flag TO_NO_BRKTS_HTML_IMG in SpamAssassin.
The provided description for it says:
To: lacks brackets and HTML and one image
As far as I understand it means the mail message is in HTML format and contains only one image, but what does "To: lacks brackets" mean?
Also ran into this problem and digged in the source code of spamassassin and found this:
meta __TO_NO_BRKTS_HTML_IMG __TO_NO_ARROWS_R && !__TO_UNDISCLOSED && HTML_MESSAGE && __ONE_IMG
meta TO_NO_BRKTS_HTML_IMG __TO_NO_BRKTS_HTML_IMG && !__FM_TO_ALL_NUMS && !__FROM_FULL_NAME && !__HAS_THREAD_INDEX && !__DKIM_EXISTS && !__HAS_SENDER && !__THREADED && !__LONGLINE
describe TO_NO_BRKTS_HTML_IMG To: lacks brackets and HTML and one image
score TO_NO_BRKTS_HTML_IMG 2.000 # limit
tflags TO_NO_BRKTS_HTML_IMG publish
So, a single image in a email and a missing name in the to field seems to trigger this. To be more concrete, this happens, when:
The recipient does not contain < and > (__TO_NO_ARROWS_R)
The recipient is undisclosed (__TO_UNDISCLOSED)
The email contains html (HTML_MESSAGE)
The email contains exactly one image (__ONE_IMG)
The sender (from) does not only contain numbers (__FM_TO_ALL_NUMS)
The recipient (to) does not contain a name (eg. foo#bar.de <foo bar>) (__FROM_FULL_NAME)
Dont know what this is for, the comment in the sourcecode itself says # Explain later. ;) (__HAS_THREAD_INDEX)
No DKIM signature exists (__DKIM_EXISTS)
No Sender-header is given (__HAS_SENDER)
Is not part of an conversation (?) (__THREADED)
Line length does not exceed 998 characters regarding to RFC 5322 (__LONGLINE)
"To: lacks brakets" means that the To: header value has no ending >
To: <destination#domain.com> Doesn't trigger the rule
To: destination#domain.com Does trigger the rule
You can get more information about Internet Message Format here
Related
I'm trying to find out how to remove non-whitelisted attachments (by mime type) (f.e. zip, exe, ...)
and append a message about the removed attachments.
I found this: https://superuser.com/a/1502589
And it worked to add a message to the subject.
But I cannot find out how to add a message to the body.
My plan was to use a regex on the attachment mime types and allow f.e.
text/* and application/json etc.
But I cannot find a single example how to change the body.
I'm using mailcow and sieve script (which I'm both new to).
Or is there a better way to "sanitize" emails before the get put into the inbox?
EDIT (2023-02-07) : I found this today:
Extension foreverypart.
Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure
https://www.rfc-editor.org/rfc/rfc5703.html \
The "replace" command is defined to allow a MIME part to be replaced
with the text supplied in the command.
Exactly what I try to do.
Now I need to find out how to install the extension and try it out.
I'm trying to filter messages with header Return-Path contains string '#example.eu'.
I added to /etc/mail/spamassasin/local.cf this lines:
My first attempt:
header LOCAL_DEMONSTRATION_ALL Return-Path =~ /example\.eu/i
score LOCAL_DEMONSTRATION_ALL 10.0
My second attempt:
header LOCAL_DEMONSTRATION_ALL ALL =~ /Return-Path.*example.eu>/i
score LOCAL_DEMONSTRATION_ALL 10.0
Another filters work, but this above doesn't. I checked my regex is Ok.
What's wrong? Thanks.
The Return-Path header contains the Envelope Sender and is typically added to the email when it is delivered to the recipient's mailbox, i.e. it is not present as a visible header while the email is in transit.
The Envelope Sender is passed in the SMTP dialog using the MAIL FROM command and can most often be used in SpamAssassin rules, but depending on exactly how your SpamAssassin is being called the actual details may vary.
SpamAssassin has a pseudo-header EnvelopeFrom that it tries to populate with the envelope sender using some heuristics (or you can tell SpamAssassin how it should be populated using the envelope_sender_header configuration option). For most setups a rule like this should work:
header LOCAL_DEMONSTRATION_ALL EnvelopeFrom =~ /example\.eu/i
score LOCAL_DEMONSTRATION_ALL 10.0
I'm trying to add my email address in Store Email Address, But it is saying "Invalid email address "admin#mydomain"."
Note that my tld is uncommon.
I think that is the reason for the error message.
I can add .com email address easily btw.
Is there any way to add the email?
Thank you.
in validation.js you have
['validate-email', 'Please enter a valid email address. For example johndoe#domain.com.', function (v) {
return Validation.get('IsEmpty').test(v) || /^([a-z0-9,!\#\$%&'\*\+\/=\?\^_`\{\|\}~-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z0-9,!\#\$%&'\*\+\/=\?\^_`\{\|\}~-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*#([a-z0-9-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z0-9-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*\.(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]){2,})$/i.test(v)
}],
You will have to play with this regular expression.
if you look into this expression you will find a . jsut remove every thing excluding ] from . till end and should solve.
I had the same issue, but your suggestions were misleading.
The error message comes up not from this java script, but app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Email/Address.php
The error is generated from lib/Zend/Validate/EmailAddress.php, because it calls hostname verification from Hostname.php in the same directory.
There you can find in row nr. 117 an array called $_validTlds
there put your domain ('works' or in my case 'wien'), take care alphabetical order, and quotes and commas. save and try again,
it will work. Good luck.
I am currently extending an e-mail system with an autoresponse feature. In a dark past, I've seen some awesome mail loops, and I'm now trying to avoid such a thing from happening to me.
I've looked at how other tools ('mailbot', 'vacation') are doing this, grepped my own mail archive for suspicious mail headers, but I wonder if there is something else I can add.
My process at this point:
Refuse if sender address is invalid (this should get rid of messages with <> sender)
Refuse if sender address matches one of the following:
'^root#',
'^hostmaster#',
'^postmaster#',
'^nobody#',
'^www#',
'-request#'
Refuse if one of these headers (after whitespace normalization and lowercasing) is present:
'^precedence: junk$',
'^precedence: bulk$',
'^precedence: list$',
'^list-id:',
'^content-type: multipart/report$',
'^x-autogenerated: reply$',
'^auto-submit: yes$',
'^subject: auto-response$'
Refuse if sender address was already seen by the autoresponder in the recent past.
Refuse if the sender address is my own address :)
Accept and send autoresponse, prepending Auto-response: to the subject, setting headers Precedence: bulk and Auto-Submit: yes to hopefully prevent some remote mailer from propagating the autoresponse any further.
Is there anything I'm missing?
In my research so far I've come up with these rules.
Treat inbound message as autogenerated, ignore it and blacklist the sender if...
Return-Path header is <> or missing/invalid
Auto-Submitted header is present with any value other than "no"
X-Auto-Response-Suppress header is present
In-Reply-To header is missing
Note: If I'm reading RFC3834 correctly, your own programs SHOULD set this, but so far it seems some autoresponders omit this (freshdesk.com)
When sending outbound messages, be sure to...
Set the Auto-Submitted: auto-generated header (or auto-replied as appropriate)
Set your SMTP MAIL FROM: command with the null address <>
Note some delivery services including Amazon SES will set their own value here, so this may not be feasible
Check the recipient against the blacklist built up by the inbound side and abort sending to known autoresponders
Consider sending not more than 1 message per unit time (long like 24 hours) to a given recipient
Notes on other answers and points
I think ignoring Precedence: list messages will cause false positives, at least for my app's configuration
I believe the OP's "auto-submit" rule is a typo and the official header is Auto-Submitted
References
RFC3834
This SO question about Precedence header has several good answers
Wikipedia Email Loop Article
desk.com article
Comments welcome and I'll update this answer as this is a good question and I'd like to see an authoritative answer created.
Update 2014-05-22
To find if an inbound message is an "out-of-office" or other automatic reply, we use that procedure:
First, Find if header "In-Reply-To" is present. If not, that is an auto-reply.
Else, check if 1 of these header is present:
X-Auto-Response-Suppress (any value)
Precedence (value contains bulk, or junk or list)
X-Webmin-Autoreply (value 1)
X-Autogenerated (value Reply)
X-AutoReply (value YES)
Include a phrase like "This is an automatically-generated response" in the body somewhere. If your message body is HTML (not plain text) you can use a style to make it not visible.
Check for this phrase before responding. If it exists, odds are good it's an automated response.
My software is working with incoming e-mail from the one and only particular sender (let it be SantaClaus#hetnet.nl). According to RFC-2616 section 14 "From" header
MAY be used for logging purposes and
as a means for identifying the source of invalid or unwanted
requests.
That's exactly what I needed, so I wrote a code, which ignores all the messages where "From" field doesn't equal SantaClaus#hetnet.nl. It worked good, but one day things changed, and now all the messages form Santa Claus contains a different string in "From" field (exactly <SantaClaus#hetnet.nl>).
I already fixed my code, but I just wonder, is this header legal? Because the same RFC-2616 section 14 says:
The address SHOULD be machine-usable,
as defined by "mailbox" in RFC 822 [9]
as updated by RFC 1123 [8]:
From = "From" ":" mailbox
An example is:
From: webmaster#w3.org
Note the absense of angle brackets. But at the same time, many e-mail messages I receive on my Gmail account has something like this in the "From" field: "Santa Claus" <santaclaus#hetnet.nl>
RFC-822 allows email addresses to be specified either by a pure email-style address, called an "addr-spec" (e.g., name#host.domain); or by using a nickname ("phrase") with the email-style address (the "addr-spec") enclosed in angle brackets (Foo Bar <foobar#host.domain>). Your sender has gone from the first format to the second format, although here the nickname part seems to be empty.
By the way, RFC-2616 is for HTTP; you're looking at the definition of an optional, and (I imagine) rarely-used, From: header in the HTTP protocol. That doesn't seem to have any direct relevance on email formats.