Re: spamasssassin vs mimedefang scores
On 22 Feb 2018, at 4:15, saqariden wrote: Hello guys, i'm using mimedefang with spamassasin, when I test an email with the command "spamassain -t file.eml", I got results like this: Dails de l'analyse du message: (-5.8 points, 3.0 requis) -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [70.38.112.54 listed in list.dnswl.org] -1.9 BAYES_00 BODY: L'algorithme Bayien a alula probabilitde spam entre 0 et 1% [score: 0.] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.3 TO_EQ_FM_DOM_SPF_FAIL To domain == From domain and external SPF failed However, the SA check which was done trough mimedefang, seems like giving other scores, how can i test an email to get these scores, and saw the difference. Typically mimedefang runs as its own special user (e.g. 'defang') which may be configured to block normal interactive use or even simple 'su' use by root. This means that if you run 'spamassassin -t' in an interactive shell, you use the user_prefs, AWL/TxRep and BayesDB for the user running that shell, not the special user. This is particularly problematic for 'learning' ham and spam for the BayesDB, because it is easy to end up either training into a DB that is entirely separate from the system-wide one used by mimedefang OR working with the system-wide DBs in ways that change ownership of them so that mimedefang can't use them. My solution for this is to use sudo and these shell aliases: satest='sudo -H -u defang spamassassin -t ' lham='sudo -H -u defang sa-learn --ham --progress ' lspam='sudo -H -u defang sa-learn --spam --progress ' blspam='sudo -H -u defang spamassassin --add-to-blacklist ' reportspam='sudo -H -u defang spamassassin -r -t '
Re: Custom Rulesets
Thanks David. I haven't done many of them yet. Very useful. On Thu, Feb 22, 2018 at 7:31 PM, David Jones wrote: > On 02/21/2018 11:48 PM, Rajkiran Rajkumar wrote: > >> Thank you Kevin and @lbutlr for the response. Checking out KAM ruleset >> now. We are not using Postfix for mail server, but I will check out how to >> achieve postscreen's functionality using JAMES(which we use). >> >> > See this thread for more suggestions: > > https://www.mail-archive.com/users@spamassassin.apache.org/msg99953.html > > -- > David Jones >
Re: ENCRYPTED_MESSAGE rule
On 2018-02-22 (17:39 MST), RW wrote: > > Is it genuinely encrypted though? I'm wondering if it's just base64 > encoded, and possibly signed. application/pkcs7-mime is S/MIME -- Vi Veri Veniversum Vivus Vici
Re: Custom rule don't match without empty line before the string!
On 2018-02-22 (07:54 MST), saqariden wrote: > > I have the following SA rule which is supposed to block base64 encoded mails: Wow. You are going to block a lot of legitimate email that way. > bodyEN_BASE64_B/(Content-Transfer-Encoding: > base64\sContent-Type: text\/(plain|html); charset="?utf-8"?)|(Content-Type: > text\/(plain|html); charset="?utf-8"?\sContent-Transfer-Encoding: base64)/i you need to be looking at the mime headers, not simply scanning the plaintext body. In fact, Don't think the plaintext body is even available to spam assassin rules, so those lines will never match as you have them. Heck, don't know if the encoding type is available at all to SA because... well, why would it. How a message is encoded is not a spam indicator. You can do this with other tools in your MTA (postfix) or you LDA (procmail), but it's a very bad idea. My personal account has 1,770 base64 encoded messages out of 90,111. I know I would not be happy to have missed those 1,770 message. -- We are born naked, wet and hungry; then it's all downhill.
Re: ENCRYPTED_MESSAGE rule
On Thu, 22 Feb 2018 17:40:56 -0600 David Jones wrote: > Sometimes the passing of time with new spam techniques from software > changes (i.e. Office 365 now auto handling of encrypted email) can > allow this to be abused and need changing. I am just trying to bring > this up in case others may be seeing the same thing in their logs and > not noticed it yet. Is it genuinely encrypted though? I'm wondering if it's just base64 encoded, and possibly signed.
Re: ENCRYPTED_MESSAGE rule
On Thu, 22 Feb 2018, David Jones wrote: On 02/22/2018 04:40 PM, John Hardin wrote: On Thu, 22 Feb 2018, David Jones wrote: On 02/22/2018 03:49 PM, John Hardin wrote: On Thu, 22 Feb 2018, David Jones wrote: My SA filters just received 45 unsolicited junk emails from Office 365 that hit ENCRYPTED_MESSAGE which subtracted a point. Looking at 72_active.cf, the description for this rule is: "Message is encrypted, not likely to be spam" The body of the email was a MIME attachment of application/pkcs7-mime so SA didn't have access to it for body content rules. I am seriously thinking about changing the score on this rule locally to 1.0 or 2.0 to add points if SA can't do any body checks. I'd recommend against that. It would be better to do offsetting scores in a meta rule... Good idea. Outlook and Outlook Web was able to display the email automatically. This may be a new feature that we are about to see more often to hide spam from SA. It also hit BAYES_00 (not much can be done to change that), DCC_CHECK, PYZOR_CHECK, and FSL_BULK_SIG to score 2.88. ...e.g. ENCRYPTED_MESSAGE && (DCC_CHECK || PYZOR_CHECK || FSL_BULK_SIG) as bulk encrypted mail seems unlikely ...or possibly ENCRYPTED_MESSAGE && FREEMAIL_FROM This is not hitting FREEMAIL* rules but I have started treating anything coming from Google and Office 365 with local meta rules like this: header __RCVD_GOOGLE Received =~ /\.google\.com \[/ Is that accurately freemail? Wouldn't that also hit Google corporate emails? header __RCVD_OFFICE365 Received =~ /\.outbound\.protection\.outlook\.com \[/ You might want to drop that in your sandbox so that it gets published... meta __RCVD_FREEMAIL (__RCVD_GOOGLE || __RCVD_OFFICE365) meta ENA_FREEMAIL (FREEMAIL_FROM || FREEMAIL_REPLYTO || FREEMAIL_FORGED_REPLYTO || __RCVD_FREEMAIL) meta ENA_FREEMAIL_ENCRYPTED_MESSAGE ENCRYPTED_MESSAGE && ENA_FREEMAIL score ENA_FREEMAIL_ENCRYPTED_MESSAGE 3.0 That above would end up being a net score of +2.0 for freemail sources of email. That sounds a lot safer. The rule *was* added with a negative score for a specific reason, after all... Sure. The description doesn't sound like a very solid reason to assume that most encrypted email is ham when we can't do any body checks. :) I that description was primarily from an assumption that spammers wouldn't be encrypting email as that would probably *reduce* the likelihood it would get viewed. But that may be changing. It's also there to somewhat offset FPs due to unexpected matches in the encrypted gibberish. Sometimes the passing of time with new spam techniques from software changes (i.e. Office 365 now auto handling of encrypted email) can allow this to be abused and need changing. Exactly. I'd be open to adding !__RCVD_OFFICE365 to ENCRYPTED_MESSAGE if they are making it *that* easy to abuse. I am just trying to bring this up in case others may be seeing the same thing in their logs and not noticed it yet. I will put it in my sandbox and see how it goes. Thanks I was just referring to the OFFICE365 subrule, as there isn't one like that yet - hotmail, sure, outlook, sure, but not office365. We should have added that back when O365 started up. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...have you noticed how the people sniveling over Trump are the same people slobbering over Fidel? They accuse Trump of wanting to put gays and minorities in camps, then post paeans to a guy who did just that. -- Toastrider @ TSM --- Today: George Washington's 286th Birthday
Re: ENCRYPTED_MESSAGE rule
On 02/22/2018 04:40 PM, John Hardin wrote: On Thu, 22 Feb 2018, David Jones wrote: On 02/22/2018 03:49 PM, John Hardin wrote: On Thu, 22 Feb 2018, David Jones wrote: My SA filters just received 45 unsolicited junk emails from Office 365 that hit ENCRYPTED_MESSAGE which subtracted a point. Looking at 72_active.cf, the description for this rule is: "Message is encrypted, not likely to be spam" The body of the email was a MIME attachment of application/pkcs7-mime so SA didn't have access to it for body content rules. I am seriously thinking about changing the score on this rule locally to 1.0 or 2.0 to add points if SA can't do any body checks. I'd recommend against that. It would be better to do offsetting scores in a meta rule... Good idea. Outlook and Outlook Web was able to display the email automatically. This may be a new feature that we are about to see more often to hide spam from SA. It also hit BAYES_00 (not much can be done to change that), DCC_CHECK, PYZOR_CHECK, and FSL_BULK_SIG to score 2.88. ...e.g. ENCRYPTED_MESSAGE && (DCC_CHECK || PYZOR_CHECK || FSL_BULK_SIG) as bulk encrypted mail seems unlikely ...or possibly ENCRYPTED_MESSAGE && FREEMAIL_FROM This is not hitting FREEMAIL* rules but I have started treating anything coming from Google and Office 365 with local meta rules like this: header __RCVD_GOOGLE Received =~ /\.google\.com \[/ Is that accurately freemail? Wouldn't that also hit Google corporate emails? header __RCVD_OFFICE365 Received =~ /\.outbound\.protection\.outlook\.com \[/ You might want to drop that in your sandbox so that it gets published... meta __RCVD_FREEMAIL (__RCVD_GOOGLE || __RCVD_OFFICE365) meta ENA_FREEMAIL (FREEMAIL_FROM || FREEMAIL_REPLYTO || FREEMAIL_FORGED_REPLYTO || __RCVD_FREEMAIL) meta ENA_FREEMAIL_ENCRYPTED_MESSAGE ENCRYPTED_MESSAGE && ENA_FREEMAIL score ENA_FREEMAIL_ENCRYPTED_MESSAGE 3.0 That above would end up being a net score of +2.0 for freemail sources of email. That sounds a lot safer. The rule *was* added with a negative score for a specific reason, after all... Sure. The description doesn't sound like a very solid reason to assume that most encrypted email is ham when we can't do any body checks. :) Sometimes the passing of time with new spam techniques from software changes (i.e. Office 365 now auto handling of encrypted email) can allow this to be abused and need changing. I am just trying to bring this up in case others may be seeing the same thing in their logs and not noticed it yet. I will put it in my sandbox and see how it goes. Thanks -- David Jones
Re: ENCRYPTED_MESSAGE rule
On Thu, 22 Feb 2018, David Jones wrote: On 02/22/2018 03:49 PM, John Hardin wrote: On Thu, 22 Feb 2018, David Jones wrote: My SA filters just received 45 unsolicited junk emails from Office 365 that hit ENCRYPTED_MESSAGE which subtracted a point. Looking at 72_active.cf, the description for this rule is: "Message is encrypted, not likely to be spam" The body of the email was a MIME attachment of application/pkcs7-mime so SA didn't have access to it for body content rules. I am seriously thinking about changing the score on this rule locally to 1.0 or 2.0 to add points if SA can't do any body checks. I'd recommend against that. It would be better to do offsetting scores in a meta rule... Good idea. Outlook and Outlook Web was able to display the email automatically. This may be a new feature that we are about to see more often to hide spam from SA. It also hit BAYES_00 (not much can be done to change that), DCC_CHECK, PYZOR_CHECK, and FSL_BULK_SIG to score 2.88. ...e.g. ENCRYPTED_MESSAGE && (DCC_CHECK || PYZOR_CHECK || FSL_BULK_SIG) as bulk encrypted mail seems unlikely ...or possibly ENCRYPTED_MESSAGE && FREEMAIL_FROM This is not hitting FREEMAIL* rules but I have started treating anything coming from Google and Office 365 with local meta rules like this: header __RCVD_GOOGLEReceived =~ /\.google\.com \[/ Is that accurately freemail? Wouldn't that also hit Google corporate emails? header __RCVD_OFFICE365 Received =~ /\.outbound\.protection\.outlook\.com \[/ You might want to drop that in your sandbox so that it gets published... meta __RCVD_FREEMAIL (__RCVD_GOOGLE || __RCVD_OFFICE365) meta ENA_FREEMAIL (FREEMAIL_FROM || FREEMAIL_REPLYTO || FREEMAIL_FORGED_REPLYTO || __RCVD_FREEMAIL) meta ENA_FREEMAIL_ENCRYPTED_MESSAGE ENCRYPTED_MESSAGE && ENA_FREEMAIL score ENA_FREEMAIL_ENCRYPTED_MESSAGE 3.0 That above would end up being a net score of +2.0 for freemail sources of email. That sounds a lot safer. The rule *was* added with a negative score for a specific reason, after all... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Vista is at best mildly annoying and at worst makes you want to rush to Redmond, Wash. and rip somebody's liver out. -- Forbes --- Today: George Washington's 286th Birthday
Re: ENCRYPTED_MESSAGE rule
On 02/22/2018 03:49 PM, John Hardin wrote: On Thu, 22 Feb 2018, David Jones wrote: My SA filters just received 45 unsolicited junk emails from Office 365 that hit ENCRYPTED_MESSAGE which subtracted a point. Looking at 72_active.cf, the description for this rule is: "Message is encrypted, not likely to be spam" The body of the email was a MIME attachment of application/pkcs7-mime so SA didn't have access to it for body content rules. I am seriously thinking about changing the score on this rule locally to 1.0 or 2.0 to add points if SA can't do any body checks. I'd recommend against that. It would be better to do offsetting scores in a meta rule... Good idea. Outlook and Outlook Web was able to display the email automatically. This may be a new feature that we are about to see more often to hide spam from SA. It also hit BAYES_00 (not much can be done to change that), DCC_CHECK, PYZOR_CHECK, and FSL_BULK_SIG to score 2.88. ...e.g. ENCRYPTED_MESSAGE && (DCC_CHECK || PYZOR_CHECK || FSL_BULK_SIG) as bulk encrypted mail seems unlikely ...or possibly ENCRYPTED_MESSAGE && FREEMAIL_FROM This is not hitting FREEMAIL* rules but I have started treating anything coming from Google and Office 365 with local meta rules like this: header __RCVD_GOOGLEReceived =~ /\.google\.com \[/ header __RCVD_OFFICE365 Received =~ /\.outbound\.protection\.outlook\.com \[/ meta __RCVD_FREEMAIL (__RCVD_GOOGLE || __RCVD_OFFICE365) meta ENA_FREEMAIL (FREEMAIL_FROM || FREEMAIL_REPLYTO || FREEMAIL_FORGED_REPLYTO || __RCVD_FREEMAIL) meta ENA_FREEMAIL_ENCRYPTED_MESSAGE ENCRYPTED_MESSAGE && ENA_FREEMAIL score ENA_FREEMAIL_ENCRYPTED_MESSAGE 3.0 That above would end up being a net score of +2.0 for freemail sources of email. -- David Jones
Re: ENCRYPTED_MESSAGE rule
On Thu, 22 Feb 2018, David Jones wrote: My SA filters just received 45 unsolicited junk emails from Office 365 that hit ENCRYPTED_MESSAGE which subtracted a point. Looking at 72_active.cf, the description for this rule is: "Message is encrypted, not likely to be spam" The body of the email was a MIME attachment of application/pkcs7-mime so SA didn't have access to it for body content rules. I am seriously thinking about changing the score on this rule locally to 1.0 or 2.0 to add points if SA can't do any body checks. I'd recommend against that. It would be better to do offsetting scores in a meta rule... Outlook and Outlook Web was able to display the email automatically. This may be a new feature that we are about to see more often to hide spam from SA. It also hit BAYES_00 (not much can be done to change that), DCC_CHECK, PYZOR_CHECK, and FSL_BULK_SIG to score 2.88. ...e.g. ENCRYPTED_MESSAGE && (DCC_CHECK || PYZOR_CHECK || FSL_BULK_SIG) as bulk encrypted mail seems unlikely ...or possibly ENCRYPTED_MESSAGE && FREEMAIL_FROM -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Christian martyrs don't explode. -- Marisol --- Today: George Washington's 286th Birthday
ENCRYPTED_MESSAGE rule
My SA filters just received 45 unsolicited junk emails from Office 365 that hit ENCRYPTED_MESSAGE which subtracted a point. Looking at 72_active.cf, the description for this rule is: "Message is encrypted, not likely to be spam" The body of the email was a MIME attachment of application/pkcs7-mime so SA didn't have access to it for body content rules. I am seriously thinking about changing the score on this rule locally to 1.0 or 2.0 to add points if SA can't do any body checks. Outlook and Outlook Web was able to display the email automatically. This may be a new feature that we are about to see more often to hide spam from SA. It also hit BAYES_00 (not much can be done to change that), DCC_CHECK, PYZOR_CHECK, and FSL_BULK_SIG to score 2.88. I reported this to SpamCop/Office 365 and blocked the sending domain. Seems like more and more junk is coming out of Office 365 every week. The majority of new/zero-hour spam that I am not able to block with SA is now coming from O365. -- David Jones
Re: Custom rule don't match without empty line before the string!
On Thu, 22 Feb 2018 10:35:48 -0600 (CST)
David B Funk wrote:
> On Thu, 22 Feb 2018, RW wrote:
>
> > On Thu, 22 Feb 2018 15:54:45 +0100
> > saqariden wrote:
> >
> >> Hello guys,
> >>
> >> I have the following SA rule which is supposed to block base64
> >> encoded mails:
> >
> > This may be dangerous. If someone doesn't wish to use 8bit text
> > then base64 encoding of UTF-8 is a sensible choice; QP is very
> > inefficient unless the text is almost completely ASCII.
> >
> >
> >> bodyEN_BASE64_B/(Content-Transfer-Encoding:
> >> base64\sContent-Type: text\/(plain|html);
> >> charset="?utf-8"?)|(mimeheader: text\/(plain|html);
> >> charset="?utf-8"?\sContent-Transfer-Encoding: base64)/i
> >> describe EN_BASE64_BTEXT OR HTML B64 ENCODED
> >> score EN_BASE64_B5
> >>
> >> this is the mail that i want to stop:
> >>
> >>
> >> the rule don't match for this mail, but it match when i had an
> >> empty line like this:
> >> ..
> >> How can i do to match the both, with the empty line and without
> >> it?
> >
> > body rules check only the text that's visible in a mail client
> > (including the subject text). This rule only works at all if you
> > make the mime unparsable.
> >
> > For mime you need "full" instead of "body". You then need an
> > explicit \n between lines.
>
> I agree with RW about the risk of FPs from that approach,
> particularly if you have international correspondents.
>
> However if you really want to do that, you need to use the
> "mimeheader" kind of rule. It works like a regular message 'header'
> type of rule but processes mime headers within the message contents.
>
> For example, to catch messages with a particular mime attachment file
> name I have a rule:
>
> mimeheader L_BANK_PHISH1Content-Disposition =~ m!attachment;
> filename="[\w\s\d._-]{1,30}verification\.html?"$!i
mimeheader rules wont work in this case because you need to
check both Content-Type and Content-Transfer-Encoding in the same mime
section.
Re: Custom rule don't match without empty line before the string!
On Thu, 22 Feb 2018, RW wrote:
On Thu, 22 Feb 2018 15:54:45 +0100
saqariden wrote:
Hello guys,
I have the following SA rule which is supposed to block base64
encoded mails:
This may be dangerous. If someone doesn't wish to use 8bit text then
base64 encoding of UTF-8 is a sensible choice; QP is very inefficient
unless the text is almost completely ASCII.
bodyEN_BASE64_B/(Content-Transfer-Encoding:
base64\sContent-Type: text\/(plain|html);
charset="?utf-8"?)|(Content-Type: text\/(plain|html);
charset="?utf-8"?\sContent-Transfer-Encoding: base64)/i
describe EN_BASE64_BTEXT OR HTML B64 ENCODED
score EN_BASE64_B5
this is the mail that i want to stop:
the rule don't match for this mail, but it match when i had an empty
line like this:
..
How can i do to match the both, with the empty line and without it?
body rules check only the text that's visible in a mail client
(including the subject text). This rule only works at all if you make
the mime unparsable.
For mime you need "full" instead of "body". You then need an
explicit \n between lines.
I agree with RW about the risk of FPs from that approach, particularly if you
have international correspondents.
However if you really want to do that, you need to use the "mimeheader" kind of
rule. It works like a regular message 'header' type of rule but processes mime
headers within the message contents.
For example, to catch messages with a particular mime attachment file name I
have a rule:
mimeheader L_BANK_PHISH1Content-Disposition =~ m!attachment;
filename="[\w\s\d._-]{1,30}verification\.html?"$!i
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Custom rule don't match without empty line before the string!
On Thu, 22 Feb 2018 15:54:45 +0100 saqariden wrote: > Hello guys, > > I have the following SA rule which is supposed to block base64 > encoded mails: This may be dangerous. If someone doesn't wish to use 8bit text then base64 encoding of UTF-8 is a sensible choice; QP is very inefficient unless the text is almost completely ASCII. > bodyEN_BASE64_B/(Content-Transfer-Encoding: > base64\sContent-Type: text\/(plain|html); > charset="?utf-8"?)|(Content-Type: text\/(plain|html); > charset="?utf-8"?\sContent-Transfer-Encoding: base64)/i > describe EN_BASE64_BTEXT OR HTML B64 ENCODED > score EN_BASE64_B5 > > this is the mail that i want to stop: > > > the rule don't match for this mail, but it match when i had an empty > line like this: >.. > How can i do to match the both, with the empty line and without it? body rules check only the text that's visible in a mail client (including the subject text). This rule only works at all if you make the mime unparsable. For mime you need "full" instead of "body". You then need an explicit \n between lines.
Re: Junk mixed in with ham on whitelists
On 02/22/18 15:56, David Jones wrote:
> On 02/22/2018 08:52 AM, Benny Pedersen wrote:
>> Giovanni Bechis skrev den 2018-02-22 15:39:
>>
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if !$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain will do,
# also any signing key size will do
} else {
$result = $self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
>>>
>>> $self->_check_dkim_signed_by already checks for miminal key bits
>>
>> elsif part is correct ?
>>
>> i read code as any key bits can make valid dkim
>
> That is also my finding based on:
>
> https://pastebin.com/mjvB0MKg
>
> which hit DKIM_VALID with a 768-bit key.
>
It doesn't for me:
-
X-Spam-Checker-Version: SpamAssassin 3.4.2-pre3-r1823175 (2018-02-05) on
bigio.paclan.it
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=5.0 tests=DKIM_SIGNED,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID
autolearn=no
autolearn_force=no version=3.4.2-pre3-r1823175
X-Spam-ASN: AS46606 69.89.16.0/20
X-Spam-Report:
* -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
* [69.89.18.3 listed in wl.mailspike.net]
* -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no
* trust
* [69.89.18.3 listed in list.dnswl.org]
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Spam-Relay-Country: US ** US
-
SpamAssassin version 3.4.2-pre3-r1823175
running on Perl version 5.24.3
with Mail-DKIM-0.40 and Net-DNS-1.14
witch Mail::DKIM and Net::DNS version are you using ?
Giovanni
Custom rule don't match without empty line before the string!
Hello guys, I have the following SA rule which is supposed to block base64 encoded mails: bodyEN_BASE64_B/(Content-Transfer-Encoding: base64\sContent-Type: text\/(plain|html); charset="?utf-8"?)|(Content-Type: text\/(plain|html); charset="?utf-8"?\sContent-Transfer-Encoding: base64)/i describe EN_BASE64_BTEXT OR HTML B64 ENCODED score EN_BASE64_B5 this is the mail that i want to stop: -- (... header header...) X-Scanned-By: MIMEDefang 2.79 # last header line here --Boundary_(ID_xx) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8hIA0KDQpIYXZlIHlvdSAgc2VlbiAgdGhpcz8gIFlvdSd2ZSBnb3Qg dG8gdGFrZSAgYSBsb29rLCB0aGF0J3MgYXdlc29tZSwgcmVhZGluZyAgbW9y ZSBoZXJlIGh0dHA6Ly93d3cuZHVydXNhbGlzLmx0L2JjaC5waHA/a3lnDQoN= --Boundary_(ID_IcM7JgudOk13I7fXE7a3Zw)-- - the rule don't match for this mail, but it match when i had an empty line like this: --Boundary_(ID_xx) #empty line here Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 How can i do to match the both, with the empty line and without it? THANK'S Regards, S.AQARIDEN. Signature Academique
Re: Junk mixed in with ham on whitelists
On 02/22/2018 08:52 AM, Benny Pedersen wrote:
Giovanni Bechis skrev den 2018-02-22 15:39:
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if
!$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain
will do,
# also any signing key size will do
} else {
$result =
$self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
$self->_check_dkim_signed_by already checks for miminal key bits
elsif part is correct ?
i read code as any key bits can make valid dkim
That is also my finding based on:
https://pastebin.com/mjvB0MKg
which hit DKIM_VALID with a 768-bit key.
--
David Jones
Re: oxy/diabetes/cbd/big pharma spam
On Wed, 21 Feb 2018 11:43:59 -0500 Alex wrote: > Hi all, > > Over the past few weeks I've noticed a few different campaigns that > are using the same overall template, but continue to not hit bayes99 > or really any other significant rules. I'm assuming this is some sort > of botnet? > > https://pastebin.com/Q9w1p2ht > https://pastebin.com/rKvKYmhY > https://pastebin.com/2VpVVA4A > > The last two are more than a week old, so I suspect it's already being > blocked by RBL, but ideas for a more general way to block these before > they hit the RBLs would be appreciated. This might help a bit headerBOGUS_MIME_VERSION MIME-Version =~ /^(?!\s*1\.0).+/ Scoring words like "Anxiety" in the display name From: Treat Anxiety looks promising.
Re: Junk mixed in with ham on whitelists
Giovanni Bechis skrev den 2018-02-22 15:39:
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if
!$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain will
do,
# also any signing key size will do
} else {
$result =
$self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
$self->_check_dkim_signed_by already checks for miminal key bits
elsif part is correct ?
i read code as any key bits can make valid dkim
Re: Junk mixed in with ham on whitelists
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/22/18 15:34, Benny Pedersen wrote:
> Benny Pedersen skrev den 2018-02-21 17:55:
>> David Jones skrev den 2018-02-21 17:41:
>>
>>> I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the
>>> size acceptable for whitelisting is different from the DKIM_VALID
>>> check?
>>
>> minimal key bits could be a plugin test yes, but imho it never made to do
>> this
>>
>>> Does the check_dkim_valid function need to also check for the
>>> dkim_minimum_key_bits size to consider it DKIM_VALID?
>>
>> i cant figure out where problem is either, since i am more a comal
>> programmer then a perl :=)
>>
>> DKIM_VALID and DKIM_VALID_AU should not give pass if minimal key bits is to
>> low
>
> sub check_dkim_valid {
> my ($self, $pms, $full_ref, @acceptable_domains) = @_;
> $self->_check_dkim_signature($pms) if !$pms->{dkim_checked_signature};
> my $result = 0;
> if (!$pms->{dkim_valid}) {
> # don't bother
> } elsif (!@acceptable_domains) {
> $result = 1; # no additional constraints, any signing domain will do,
> # also any signing key size will do
> } else {
> $result = $self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
> }
> return $result;
> }
>
> there we go :(
>
> dkim signed should be any key bits allowed, but dkim valid should not allow
> under minimal key bits
$self->_check_dkim_signed_by already checks for miminal key bits
Giovanni
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEqg3TnG6R3qYMxl94+r7qCYlyWOUFAlqO1hgACgkQ+r7qCYly
WOWbzQ//ZmOupz9AmyVV/155HcYOY9KpSN3FPNUxzNbfpQK/zEA2XK4XPIEKcsYn
qr7e81PlWnW/dKgquItylHxk3DOHUbn/+yUJ0WzVpbXXGWlW7Byf/PibzYSQa1tg
7RvQXgVBFjC+O67BhDxQH3JnHswf4H9pRjuF0jtErA/rgDEG8g8MV/3DG0jj0FpD
qRNKpkRy1pkS1lTe+yV9kvcz9pwiRygPjMGvMlEr+1pQ3T8iEgFTPSiBdwyVnaEc
JcgtpO/JQeGMcblIy+jF0ZJQbBYeHxD/W3S8gFcKbo0OT1CBdG/qARvA6TnUrTqb
J/kC4HfRgsWRe86SFSMOSmOCyhLuuKIv95Xsq+u9cqu9vPlJ80eY8Gf/bEg8wT5f
zlqecksTYN6Dl7GW7eKl11luQm6OM29p+a9woZ+i5K+pFokEfISg8LlpyUOVMb4O
AmHLE5O7xI+lvyK4g0CcQpbLC0EHaYCas/8q/0zKVCyws0gb5Pg8XB7K/VLDjtWP
etw6Qj8VGUPER1Kidh8VVH/My0kr9sRdFIhcJqCT4ISUfUjEELXzrLqcGdMxBoQg
/vTg/wnyfrxjIe6H9HuSEFiP0KWwlmwa0YPR0tU1SmxIm/fsOAuXaJDQiJdJZWEF
Koto7UjxXilu//X29y+ClF4DtwqYNO3zhDAO3eujwu5y3BSoOgo=
=iKOh
-END PGP SIGNATURE-
Re: Junk mixed in with ham on whitelists
Benny Pedersen skrev den 2018-02-21 17:55:
David Jones skrev den 2018-02-21 17:41:
I have that same code in my DKIM.pm and I am running 3.4.1. Maybe the
size acceptable for whitelisting is different from the DKIM_VALID
check?
minimal key bits could be a plugin test yes, but imho it never made to
do this
Does the check_dkim_valid function need to also check for the
dkim_minimum_key_bits size to consider it DKIM_VALID?
i cant figure out where problem is either, since i am more a comal
programmer then a perl :=)
DKIM_VALID and DKIM_VALID_AU should not give pass if minimal key bits
is to low
sub check_dkim_valid {
my ($self, $pms, $full_ref, @acceptable_domains) = @_;
$self->_check_dkim_signature($pms) if
!$pms->{dkim_checked_signature};
my $result = 0;
if (!$pms->{dkim_valid}) {
# don't bother
} elsif (!@acceptable_domains) {
$result = 1; # no additional constraints, any signing domain will
do,
# also any signing key size will do
} else {
$result =
$self->_check_dkim_signed_by($pms,1,0,\@acceptable_domains);
}
return $result;
}
there we go :(
dkim signed should be any key bits allowed, but dkim valid should not
allow under minimal key bits
Re: Custom Rulesets
On 02/21/2018 11:48 PM, Rajkiran Rajkumar wrote: Thank you Kevin and @lbutlr for the response. Checking out KAM ruleset now. We are not using Postfix for mail server, but I will check out how to achieve postscreen's functionality using JAMES(which we use). See this thread for more suggestions: https://www.mail-archive.com/users@spamassassin.apache.org/msg99953.html -- David Jones
Re: spamasssassin vs mimedefang scores
On 2/22/2018 4:15 AM, saqariden wrote: i'm using mimedefang with spamassasin, when I test an email with the command "spamassain -t file.eml", I got results like this: Dails de l'analyse du message: (-5.8 points, 3.0 requis) -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [70.38.112.54 listed in list.dnswl.org] -1.9 BAYES_00 BODY: L'algorithme Bayien a alula probabilitde spam entre 0 et 1% [score: 0.] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.3 TO_EQ_FM_DOM_SPF_FAIL To domain == From domain and external SPF failed However, the SA check which was done trough mimedefang, seems like giving other scores, how can i test an email to get these scores, and saw the difference. Network tests and Bayesian tests could change in between runs. Unless you ran the tests almost concurrently, this could be normal/expected behavior. I love MD and I don't run it with spamassassin it's space. I use a system call to spamc and interpret the results. That way I'm always using the same configuration for spamassassin and I can spam it onto other servers easily. Regards, KAM
spamasssassin vs mimedefang scores
Hello guys, i'm using mimedefang with spamassasin, when I test an email with the command "spamassain -t file.eml", I got results like this: Dails de l'analyse du message: (-5.8 points, 3.0 requis) -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [70.38.112.54 listed in list.dnswl.org] -1.9 BAYES_00 BODY: L'algorithme Bayien a alula probabilitde spam entre 0 et 1% [score: 0.] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.3 TO_EQ_FM_DOM_SPF_FAIL To domain == From domain and external SPF failed However, the SA check which was done trough mimedefang, seems like giving other scores, how can i test an email to get these scores, and saw the difference. Signature Academique
