Re: From:name spoofing

[Amir Caspi]

> On Feb 16, 2018, at 4:41 PM, John Hardin  wrote:
> 
> Not necessarily safe. If your MTA receives a message without a Message-ID, it 
> is supposed to generate one. And if it does so, it will probably do so using 
> your (recipient) domain...

Wouldn't this also FP on messages internal to the domain, i.e., sent from one 
user to another on the same domain?

(Also, my Message-IDs don't seem to have this same format.  Nor do yours.)

--- Amir

Re: From:name spoofing

[John Hardin]

On Fri, 16 Feb 2018, Michael Storz wrote:


Am 2018-02-15 19:27, schrieb David Jones:

We have covered this issue a few times recently on this list but I
don't think anything definitive was ever decided or recommended to
detect and block this sort of spoofing:

https://pastebin.com/juXLD8vr

This appears to be a spoofed email from a compromised account trying
to be a known corespondent to this customer of mine.

The Message-ID is suspicious since it's an inbound email to the
hck12.net domain.


David,

You can reject this kind of spam using

ALL =~ /^To: .+\@([^>]+)\nMessage-ID: <\d{8,13}\.201[78]\d{5,11}\@\1>/m

and the message-id and the boundary. I am doing this since May last year.


Not necessarily safe. If your MTA receives a message without a Message-ID, 
it is supposed to generate one. And if it does so, it will probably do so 
using your (recipient) domain...


--
 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
---
  People that keep dreaming about the wasteland, labyrinths and
  quick cash, die in amusing ways. -- Root the Dragon
---
 6 days until George Washington's 286th Birthday

Re: Malformed List-Id header

[Kenneth Porter]

On 2/16/2018 12:57 PM, Alex wrote:

I think it's a mistake to whitelist (or even deduct significant
points) based on a header that can be controlled by a spammer.

We see tons of spam that has properly crafted MIDs. If you're using
procmail, it sounds like this is on a personal account, so perhaps
it's not so bad, but I wouldn't roll this out broadly.


It's just for my family domain.

If you're going to continue to use this, I'd then suggest at least
adding some other qualifiers like SPF or DKIM or
!KAM_LAZY_DOMAIN_SECURITY or !FREEMAIL_FROM etc...


Agreed. The whitelist rule isn't one I'd spread. It's the other one that 
catches the malformed header that I mainly want to share.  Eventually 
the bad actors will catch up and fix their header but for now this seems 
pretty good at spotting "lists" I didn't sign up for. When they DO fix 
their header, their lists will drop into my Unknown Lists folder and 
I'll adjust the rule as necessary.

Is there a way to perform selective full uri rbl lookups?

[jahlives]

Hi list

I'm looking for a way in spamassassin to run a full-uri-host rbl lookup
for a specific rule. I do not want to discuss about sense or non-sense
of full-uri-hosts lookups ;-)

lets assume I have two rules which query my own rbl

urirhssub HIT_DOMAINmy.rbl.tld. A 127.0.0.2
bodyHIT_DOMAIN  eval:check_uridnsbl('HIT_DOMAIN')

urifullsub HIT_FULL my.rbl.tld. A 127.0.0.4
bodyHIT_FULLeval:check_uridnsbl('HIT_FULL')

I know urifullsub does not exist, should just visualize what I try to
achieve :-)

now for a uri like www.sub.domain.tld both rules should be tested. The
first one for domain.tld (which sa does with rh lookups) and the second
one with the full-uri-host (www.sub.domain.tld)

I read about aux_tlds but I think this does not help me as if I add
domain.tld to aux_tlds the first query above would be fired with
sub.domain.tld

I thought that the second query could be solved using askdns plugin in a
way like this

askdns HIT_FULL _URIFULLHOST_.my.rbl.tld.   A   127.0.0.4

But how to get access to urifullhost? :-)

Currently I use a plugin of my antispam glue to perform the full uri
host lookups on uris found. This plugin adds a X-Header upon hit on
which spamassassin fires and scores.
So I have a solution to this "problem" but it would be nice to do both
queries from spamassassin :-)

Cheers

tobi

Re: Malformed List-Id header

[Alex]

Hi,

On Fri, Feb 16, 2018 at 12:41 PM, Kenneth Porter  wrote:
> I just put this into service. I'm white-listing mailing lists. Most go to
> their own folder via procmail filtering, and unrecognized ones go to the
> folder Lists/Unknown until I write a procmail rule. But this rule should
> catch lazy abusers. After a bit more experience I'll crank up the punishment
> score for those.
>
> header   __KP_LIST_ID_DOMAIN_IN_BRACKETS List-id =~ /<([\w-]+)?(\.[\w-]+)+>/
>
> describe KP_LIST_ID_DOMAIN_IN_BRACKETS List-id has domain in angle brackets
> meta KP_LIST_ID_DOMAIN_IN_BRACKETS __KP_LIST_ID_DOMAIN_IN_BRACKETS
> scoreKP_LIST_ID_DOMAIN_IN_BRACKETS -15.0
>
> describe KP_LIST_ID_IMPROPER_FORMAT List-id has improper format
> meta KP_LIST_ID_IMPROPER_FORMAT __HAS_LIST_ID &&
> !__KP_LIST_ID_DOMAIN_IN_BRACKETS
> scoreKP_LIST_ID_IMPROPER_FORMAT 0.1

I think it's a mistake to whitelist (or even deduct significant
points) based on a header that can be controlled by a spammer.

We see tons of spam that has properly crafted MIDs. If you're using
procmail, it sounds like this is on a personal account, so perhaps
it's not so bad, but I wouldn't roll this out broadly.

If you're going to continue to use this, I'd then suggest at least
adding some other qualifiers like SPF or DKIM or
!KAM_LAZY_DOMAIN_SECURITY or !FREEMAIL_FROM etc...

Re: From:name spoofing

[David Jones]

On 02/16/2018 02:40 PM, Michael Storz wrote:

Am 2018-02-15 19:27, schrieb David Jones:

We have covered this issue a few times recently on this list but I
don't think anything definitive was ever decided or recommended to
detect and block this sort of spoofing:

https://pastebin.com/juXLD8vr

This appears to be a spoofed email from a compromised account trying
to be a known corespondent to this customer of mine.

The Message-ID is suspicious since it's an inbound email to the
hck12.net domain.


David,

You can reject this kind of spam using

ALL =~ /^To: .+\@([^>]+)\nMessage-ID: <\d{8,13}\.201[78]\d{5,11}\@\1>/m

and the message-id and the boundary. I am doing this since May last year.

Michael


I have been testing out Paul Stead's plugin as a broad solution for this 
issue:


https://github.com/fmbla/spamassassin-fromnamespoof

So far it's working pretty well.  I don't get many of these but often 
times these are very targeted and potentially problematic emails that 
try to trick finance people into wiring lots of money.  They typically 
come from compromised accounts making them hard to block.


--
David Jones

Re: From:name spoofing

[Michael Storz]

Am 2018-02-15 19:27, schrieb David Jones:

We have covered this issue a few times recently on this list but I
don't think anything definitive was ever decided or recommended to
detect and block this sort of spoofing:

https://pastebin.com/juXLD8vr

This appears to be a spoofed email from a compromised account trying
to be a known corespondent to this customer of mine.

The Message-ID is suspicious since it's an inbound email to the
hck12.net domain.


David,

You can reject this kind of spam using

ALL =~ /^To: .+\@([^>]+)\nMessage-ID: <\d{8,13}\.201[78]\d{5,11}\@\1>/m

and the message-id and the boundary. I am doing this since May last 
year.


Michael

Re: Malformed List-Id header

[Kenneth Porter]

I just put this into service. I'm white-listing mailing lists. Most go to 
their own folder via procmail filtering, and unrecognized ones go to the 
folder Lists/Unknown until I write a procmail rule. But this rule should 
catch lazy abusers. After a bit more experience I'll crank up the 
punishment score for those.



header   __KP_LIST_ID_DOMAIN_IN_BRACKETS List-id =~ /<([\w-]+)?(\.[\w-]+)+>/

describe KP_LIST_ID_DOMAIN_IN_BRACKETS List-id has domain in angle brackets
meta KP_LIST_ID_DOMAIN_IN_BRACKETS __KP_LIST_ID_DOMAIN_IN_BRACKETS
scoreKP_LIST_ID_DOMAIN_IN_BRACKETS -15.0

describe KP_LIST_ID_IMPROPER_FORMAT List-id has improper format
meta KP_LIST_ID_IMPROPER_FORMAT __HAS_LIST_ID && 
!__KP_LIST_ID_DOMAIN_IN_BRACKETS

scoreKP_LIST_ID_IMPROPER_FORMAT 0.1

Re: problem with spamassassin for WIndows

[Kevin A. McGrail]

On 2/16/2018 1:24 AM, Gianluca Furnarotto wrote:

Hi Bill,

this is the result of the command you suggested to type:

feb 16 07:21:09.678 [21824] warn: Use of uninitialized value $_[1] in 
hash eleme

nt at Mail/SpamAssassin/Conf/Parser.pm line 571,  line 717.


Good call, Bill.  Sounds like a misconfiguration on line 717.  Not sure 
if that's easy to figure out but you are looking for problems if I had 
to guess around your bayesian configuration stuff.





On 16 febbraio 2018 a 02:06:40, Bill Cole 
(sausers-20150...@billmail.scconsult.com 
) scritto:



On 15 Feb 2018, at 15:33, Gianluca Furnarotto wrote:

> Hi,
>
> I am trying to use Bayes with spamassassin, now it seems stop to
> learn, and
> when I use a command as "sa-learn --dump magic", or "sa-learn --sync",
> or other sa-learn commands,
> it appears this error:
> "Use of uninitialized value $_[1] in hash element at
> Mail/SpamAssassin/Conf/Parser.pm line 571."
>
> Line 571 is this:
> " } "
> inside these lines.
> " elsif ($type == $Mail::SpamAssassin::Conf::CONF_TYPE_ADDRLIST) {
> $cmd->{code} = \&set_addrlist_value;
> }" <--- line 571

That absolutely IS NOT line 571 of Mail/SpamAssassin/Conf/Parser.pm in
SA version 3.4.1. That's line 685.

The relevant lines in Mail/SpamAssassin/Conf/Parser.pm:

568
569 # functions supported in the "if" eval:
570 sub cond_clause_plugin_loaded {
571 return $_[0]->{conf}->{plugins_loaded}->{$_[1]};
572 }
573

My first guess on this is that your configuration has a typo. Try
running 'spamassassin --lint' to check it.

The error message indicates that something is calling the subroutine
'cond_clause_plugin_loaded' in a way that gives it only one parameter
where it is expecting 2, the first of which is an object reference.