Re: Messages from outer clients marked as spam

2023-01-23 Thread Bill Cole

On 2023-01-23 at 11:37:04 UTC-0500 (Mon, 23 Jan 2023 17:37:04 +0100)
Matus UHLAR - fantomas 
is rumored to have said:

Unfortunately SpamAssassin does not have set of rules to ignore for 
outgoing mail, nor special scores for those.


This isn't quite true.

The *_networks parameters determine how Received headers are interpreted 
and which client IPs are tested against which DNSBLs. We also have the 
ALL_TRUSTED rule which should match on authenticated initial message 
submission to the local host or to an authorized MSA, giving your own 
users (or anyone who has compromised their credentials...) a special 
benefit of the doubt.





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


RE: Messages from outer clients marked as spam

2023-01-23 Thread Marc
> 
> >> Since the beginning of this year, however, incoming (SMTP authenticated)
> >> mail from clients outside the LAN is marked as spam.
> >> E.g.
> >> > X-Spam-Score: 10.756 (**)
> >>
> BAYES_00,KAM_DMARC_REJECT,KAM_DMARC_STATUS,KAM_LOTSOFHASH,KHOP_HELO_FCRDNS,LOT
> >>
> S_OF_MONEY,PDS_RDNS_DYNAMIC_FP,RCVD_IN_PBL,RCVD_IN_ZEN_LASTEXTERNAL,RDNS_DYNAM
> >> IC,SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL
> 
> On 23.01.23 16:05, Marc wrote:
> >Don't you have more details? Looks to me you are on dns blacklists, your spf
> is not good etc.
> 
> You have misunderstood the problem. Authenticated clients are those who
> submit mail wia OP's server, so the SPF/DKIM/DMARC can't match as they match
> when they go out of the OP's server.
> 
> Also, it's common for authenticated clients to send mail from dynamic IP
> addresses, they don't leave the OP's server using dynamic IP anymore.

yes I got this, but it looks like the stage where the message is being parsed 
to spamassassin, spamassassin uses the client ip. This is also the problem with 
the rbl, the client ip is being parsed.

I think this was just always working like this, until more and more ip's are 
listed on dns blacklist and now all of a sudden he passed the threshold.

As you wrote, you can't have such checks on the email, only content can be 
checked by spamassassin in this setup.




Re: Messages from outer clients marked as spam

2023-01-23 Thread giovanni

On 1/23/23 17:53, Bill Cole wrote:

On 2023-01-23 at 10:51:14 UTC-0500 (Mon, 23 Jan 2023 16:51:14 +0100)
Andrea Venturoli 
is rumored to have said:


Hello.

I've got a long standing server, where I run FreeBSD (13.1) + sendmail (8.17.1) 
+ MIMEDefang (2.84) + SpamAssassin (3.4.6).
(I know there are more recent versions, but that's what ports currently 
provide).


SA4 has been in ports for a while. MD3.x should be but is not. This is unlikely 
to be relevant to your problem.


This has been working perfectly for years.

Since the beginning of this year, however, incoming (SMTP authenticated) mail 
from clients outside the LAN is marked as spam.


Very odd. Since you're still on SA3.4.6, the only piece that should have 
changed about SA is the rules and the data in external resources like DNSBLs. 
That should not have been able to affect how SA detects authenticated clients.


E.g.

X-Spam-Score: 10.756 (**) 
BAYES_00,KAM_DMARC_REJECT,KAM_DMARC_STATUS,KAM_LOTSOFHASH,KHOP_HELO_FCRDNS,LOTS_OF_MONEY,PDS_RDNS_DYNAMIC_FP,RCVD_IN_PBL,RCVD_IN_ZEN_LASTEXTERNAL,RDNS_DYNAMIC,SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL


Some external data sources there: sender domain DMARC/SPF records, SpamHaus, 
client rDNS. I think the KAM_DMARC_* rules may be new as well.

It is also possible that there were changes in your system that could trigger 
this, but I would expect that you'd have mentioned it if you had made any 
obvious ones: hostname, local.cf, mimedefang-filter. It would also be notable 
if your users have started connecting from a new range of addresses.



Right now I instructed MIMEDefang to avoid passing authenticated mails to 
SpamAssassin, but this is not what I ideally want. (If a client gets 
compromised...).


Correct. SA should be able to detect trustworthy authentication indications in 
the trusted Received headers which prevent it from applying *most* of those 
rules.


My real wish would be to always run messages through SpamAssassin, but avoid 
RBL/SPF/DMARC/dynamic IPs/etc... checks for those that come from an 
authenticated client, as these rules make no sense in that case.

What's the best practice to achieve this result?


Configure your internal_networks, msa_networks, and trusted_networks properly 
and make sure that your mimedefang-filter calls synthesize_received_header() 
before spam_assassin_check(). With those parameters set correctly and the local 
Received header included, SA should be able to detect authenticated clients of 
trusted machines and skip those rules.


in MIMEDefang 2.84 synthesize_received_header() doesn't add a correct header if 
the email is authenticated,
this has been fixed in MIMEDefang 2.85 with this commit:
https://github.com/The-McGrail-Foundation/MIMEDefang/commit/34ffd6fa31c4d9e79494fae427ec3b9da6a1c8b1

The problem could have been spotted only recently because more domains started 
to use DMARC.
 Giovanni


OpenPGP_signature
Description: OpenPGP digital signature


Re: Messages from outer clients marked as spam

2023-01-23 Thread Bill Cole

On 2023-01-23 at 10:51:14 UTC-0500 (Mon, 23 Jan 2023 16:51:14 +0100)
Andrea Venturoli 
is rumored to have said:


Hello.

I've got a long standing server, where I run FreeBSD (13.1) + sendmail 
(8.17.1) + MIMEDefang (2.84) + SpamAssassin (3.4.6).
(I know there are more recent versions, but that's what ports 
currently provide).


SA4 has been in ports for a while. MD3.x should be but is not. This is 
unlikely to be relevant to your problem.



This has been working perfectly for years.

Since the beginning of this year, however, incoming (SMTP 
authenticated) mail from clients outside the LAN is marked as spam.


Very odd. Since you're still on SA3.4.6, the only piece that should have 
changed about SA is the rules and the data in external resources like 
DNSBLs. That should not have been able to affect how SA detects 
authenticated clients.



E.g.
X-Spam-Score: 10.756 (**) 
BAYES_00,KAM_DMARC_REJECT,KAM_DMARC_STATUS,KAM_LOTSOFHASH,KHOP_HELO_FCRDNS,LOTS_OF_MONEY,PDS_RDNS_DYNAMIC_FP,RCVD_IN_PBL,RCVD_IN_ZEN_LASTEXTERNAL,RDNS_DYNAMIC,SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL


Some external data sources there: sender domain DMARC/SPF records, 
SpamHaus, client rDNS. I think the KAM_DMARC_* rules may be new as well.


It is also possible that there were changes in your system that could 
trigger this, but I would expect that you'd have mentioned it if you had 
made any obvious ones: hostname, local.cf, mimedefang-filter. It would 
also be notable if your users have started connecting from a new range 
of addresses.



Right now I instructed MIMEDefang to avoid passing authenticated mails 
to SpamAssassin, but this is not what I ideally want. (If a client 
gets compromised...).


Correct. SA should be able to detect trustworthy authentication 
indications in the trusted Received headers which prevent it from 
applying *most* of those rules.


My real wish would be to always run messages through SpamAssassin, but 
avoid RBL/SPF/DMARC/dynamic IPs/etc... checks for those that come from 
an authenticated client, as these rules make no sense in that case.


What's the best practice to achieve this result?


Configure your internal_networks, msa_networks, and trusted_networks 
properly and make sure that your mimedefang-filter calls 
synthesize_received_header() before spam_assassin_check(). With those 
parameters set correctly and the local Received header included, SA 
should be able to detect authenticated clients of trusted machines and 
skip those rules.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire


Re: Messages from outer clients marked as spam

2023-01-23 Thread Matus UHLAR - fantomas

Since the beginning of this year, however, incoming (SMTP authenticated)
mail from clients outside the LAN is marked as spam.
E.g.
> X-Spam-Score: 10.756 (**)
BAYES_00,KAM_DMARC_REJECT,KAM_DMARC_STATUS,KAM_LOTSOFHASH,KHOP_HELO_FCRDNS,LOT
S_OF_MONEY,PDS_RDNS_DYNAMIC_FP,RCVD_IN_PBL,RCVD_IN_ZEN_LASTEXTERNAL,RDNS_DYNAM
IC,SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL


On 23.01.23 16:05, Marc wrote:

Don't you have more details? Looks to me you are on dns blacklists, your spf is 
not good etc.


You have misunderstood the problem. Authenticated clients are those who 
submit mail wia OP's server, so the SPF/DKIM/DMARC can't match as they match 
when they go out of the OP's server.


Also, it's common for authenticated clients to send mail from dynamic IP 
addresses, they don't leave the OP's server using dynamic IP anymore.



Right now I instructed MIMEDefang to avoid passing authenticated mails
to SpamAssassin, but this is not what I ideally want. (If a client gets
compromised...).


I fully understand this.  except checking DNSBLs for dynamic IP and 
SPF/DKIM/DMARC checks, all other checks like BAYES, RAZOR/PYZOR/DCC are 
useful there.



My real wish would be to always run messages through SpamAssassin, but
avoid RBL/SPF/DMARC/dynamic IPs/etc... checks for those that come from
an authenticated client, as these rules make no sense in that case.



What's the best practice to achieve this result?


Separate in and out going servers and different configurations for their 
spamassassin.  It is almost impossible to have in/out going combined.


That's correct but often also expensive, impossible and ineffective 

(e.g.  when you want to match incoming mail onto outgoing to check whether 
it's real reply to existing problem)



Unfortunately SpamAssassin does not have set of rules to ignore for 
outgoing mail, nor special scores for those.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.


RE: Messages from outer clients marked as spam

2023-01-23 Thread Marc
> I've got a long standing server, where I run FreeBSD (13.1) + sendmail
> (8.17.1) + MIMEDefang (2.84) + SpamAssassin (3.4.6).
> (I know there are more recent versions, but that's what ports currently
> provide).
> This has been working perfectly for years.

yes time changes, currently gmail is sometimes blocking emails complain about 
spf+dkim, while these messages are not even configured for spf/dkim.

> Since the beginning of this year, however, incoming (SMTP authenticated)
> mail from clients outside the LAN is marked as spam.
> E.g.
> > X-Spam-Score: 10.756 (**)
> BAYES_00,KAM_DMARC_REJECT,KAM_DMARC_STATUS,KAM_LOTSOFHASH,KHOP_HELO_FCRDNS,LOT
> S_OF_MONEY,PDS_RDNS_DYNAMIC_FP,RCVD_IN_PBL,RCVD_IN_ZEN_LASTEXTERNAL,RDNS_DYNAM
> IC,SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL

Don't you have more details? Looks to me you are on dns blacklists, your spf is 
not good etc. 

> Right now I instructed MIMEDefang to avoid passing authenticated mails
> to SpamAssassin, but this is not what I ideally want. (If a client gets
> compromised...).

maybe just stat it only (with prometheus)? 
https://www.mail-archive.com/users@spamassassin.apache.org/msg109914.html

> My real wish would be to always run messages through SpamAssassin, but
> avoid RBL/SPF/DMARC/dynamic IPs/etc... checks for those that come from
> an authenticated client, as these rules make no sense in that case.

I prefer to have spf, dns rbl connect done in the milter, that is more 
efficient. As a last I parse message data to resource intensive tasks like 
spamassassin and clamav.

> What's the best practice to achieve this result?
> 

Separate in and out going servers and different configurations for their 
spamassassin. It is almost impossible to have in/out going combined.


Messages from outer clients marked as spam

2023-01-23 Thread Andrea Venturoli

Hello.

I've got a long standing server, where I run FreeBSD (13.1) + sendmail 
(8.17.1) + MIMEDefang (2.84) + SpamAssassin (3.4.6).
(I know there are more recent versions, but that's what ports currently 
provide).

This has been working perfectly for years.

Since the beginning of this year, however, incoming (SMTP authenticated) 
mail from clients outside the LAN is marked as spam.

E.g.

X-Spam-Score: 10.756 (**) 
BAYES_00,KAM_DMARC_REJECT,KAM_DMARC_STATUS,KAM_LOTSOFHASH,KHOP_HELO_FCRDNS,LOTS_OF_MONEY,PDS_RDNS_DYNAMIC_FP,RCVD_IN_PBL,RCVD_IN_ZEN_LASTEXTERNAL,RDNS_DYNAMIC,SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL


Right now I instructed MIMEDefang to avoid passing authenticated mails 
to SpamAssassin, but this is not what I ideally want. (If a client gets 
compromised...).
My real wish would be to always run messages through SpamAssassin, but 
avoid RBL/SPF/DMARC/dynamic IPs/etc... checks for those that come from 
an authenticated client, as these rules make no sense in that case.


What's the best practice to achieve this result?

 bye & Thanks
av.