Re: DMARC_REJECT?

2019-11-15 Thread Dominic Raferd
On Fri, 15 Nov 2019 at 21:17, Kevin A. McGrail  wrote:

> Good idea.  This is done.
>
> On 11/15/2019 11:49 AM, David Jones wrote:
> > Perhaps it needs to be named KAM_DMARC_REJECT to make it obvious that it
> > came from the KAM.cf and have a default score of 0.001?
>

I believe only the renaming has been done, the default score remains 10; so
anyone overriding the default score (that would be, er, me) needs to update
their local settings for the new name.


Re: DMARC_REJECT?

2019-11-15 Thread Amir Caspi
On Nov 15, 2019, at 4:35 PM, RW  wrote:
> 
> DKIM_VALID_AU is too strict for DMARC as it requires strict alignment.

Indeed, although I wonder if DKIM_VALID_AU is itself too strict?  In 
particular, one sender that triggers this issue is coming from a .gov 3rd-level 
subdomain where the valid DKIM signature specifies only the 2LD, i.e.,

sender = u...@sub.domain.gov 
DKIM d=domain.gov 

So SA recognizes DKIM_VALID but does _not_ recognize DKIM_VALID_AU even though 
the sender is from a legit subdomain of the DKIM signer.  (And, the signer is 
in the DKIM WL, so __DKIM_RELIABLE is also hitting.)  It would seem to me that 
a situation like the above should hit DKIM_VALID_AU as the sender address is an 
authorized subdomain, and the signing (higher-level) domain is reputable.

Or, as you say, it should be based on DKIM_VALID and not DKIM_VALID_AU.

> OTOH SPF_PASS requires no alignment at all which should eliminate most
> FPs on incoming mail - including most forwarded mail. DKIM should only
> rarely make a difference on ham. 
> 
> Do you have something preventing SPF from working correctly?

Apparently, yes.  It appears that some incoming messages are missing the 
Return-Path header that sendmail is supposed to insert.  This appears 
intermittent -- most messages have it, but some do not, and it varies even for 
messages from the same sender, so I have not yet been able to identify a 
pattern.

After exhaustive googling, it appears that this is likely related to 
MailScanner, because it picks up the message from sendmail before final 
delivery, does its processing, then lets sendmail do final delivery... and in 
the process it looks like it kills the Return-Path header in some emails, for 
reasons unknown.  I've filed a bug with them, resolution TBD.

In the meantime, I also discovered that SA provides support for non-standard 
Envelope-From headers, so I've directed it to use the one that MailScanner 
inserts (X-*-MailScanner-From), and that seems to be working... so SPF_PASS 
should be working correctly now for all messages.  I still want to figure out 
why MS is killing the correct Return-Path header in those intermittent cases, 
but it appears I at least have a workaround for now...

So, at the very least, this workaround should enable SPF_PASS and eliminate FPs 
due to that.

But I agree that DMARC_REJECT should be based either on DKIM_VALID (without 
_AU), or DKIM_VALID_AU should allow qualified subdomains of the signing domain.

Thanks!

--- Amir




Re: DMARC_REJECT?

2019-11-15 Thread Benny Pedersen

On 2019-11-16 00:35, RW wrote:


meta DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) && __DMARC_POLICY_REJECT


this is when not aligned and domain owner want to reject

adding another meta with MAILING_LIST_MULTI included does not harm imho


Re: DMARC_REJECT?

2019-11-15 Thread RW
On Fri, 15 Nov 2019 10:02:48 -0700
Amir Caspi wrote:

> On Nov 15, 2019, at 9:50 AM, David Jones  wrote:
> > 
> > If SA is being run post MTA (i.e. inside Thunderbird) then any
> > filtering can change the content to remove potentially bad
> > attachments, add an "EXTERNAL" warning to the Subject or body, etc.
> > which will break DKIM signing.  
> 
> I believe this is what’s happening on my FPs. My mail flow is
> sendmail to MailScanner to SA (spamc) via procmail, and MS will do
> some content altering (e.g. to disable web bugs or reveal potential
> phishing links). That breaks DKIM. I could disable those features but
> that obviates half the point of MS. If I could swap the order of MS
> and SA that would resolve this issue... but I’m not sure if that’s
> possible with my setup. (I know MS can call SA from within its flow
> but it doesn’t use spamc/spamd and I think can not accommodate
> per-user prefs.)
> 
> The other FP I’ve seen is forwarded mail, I’m not sure why DKIM broke
> there because I didn’t see evidence of MS munging. Will have to
> examine more closely.


The rule  is

meta DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) && __DMARC_POLICY_REJECT

DKIM_VALID_AU is too strict for DMARC as it requires strict alignment.
OTOH SPF_PASS requires no alignment at all which should eliminate most
FPs on incoming mail - including most forwarded mail. DKIM should only
rarely make a difference on ham. 


Do you have something preventing SPF from working correctly?


It would be useful to include  ALL_TRUSTED in these rules to handle
local and outgoing mail better.

I would also include __RP_MATCHES_RCVD.




Re: DMARC_REJECT?

2019-11-15 Thread Kevin A. McGrail
Good idea.  This is done.

On 11/15/2019 11:49 AM, David Jones wrote:
> Perhaps it needs to be named KAM_DMARC_REJECT to make it obvious that it 
> came from the KAM.cf and have a default score of 0.001?

-- 
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171



Re: DMARC_REJECT?

2019-11-15 Thread Amir Caspi
On Nov 15, 2019, at 9:50 AM, David Jones  wrote:
> 
> If SA is being run post MTA (i.e. inside Thunderbird) then any filtering 
> can change the content to remove potentially bad attachments, add an 
> "EXTERNAL" warning to the Subject or body, etc. which will break DKIM 
> signing.

I believe this is what’s happening on my FPs. My mail flow is sendmail to 
MailScanner to SA (spamc) via procmail, and MS will do some content altering 
(e.g. to disable web bugs or reveal potential phishing links). That breaks 
DKIM. I could disable those features but that obviates half the point of MS. If 
I could swap the order of MS and SA that would resolve this issue... but I’m 
not sure if that’s possible with my setup. (I know MS can call SA from within 
its flow but it doesn’t use spamc/spamd and I think can not accommodate 
per-user prefs.)

The other FP I’ve seen is forwarded mail, I’m not sure why DKIM broke there 
because I didn’t see evidence of MS munging. Will have to examine more closely.

Cheers.

--- Amir
thumbed via iPhone


Re: DMARC_REJECT?

2019-11-15 Thread David Jones
On 11/15/19 12:35 AM, Kevin A. McGrail wrote:
> The DMARC Reject rule is about whether a domain has failed DKIM and has
> a DMARC reject policy.  I will add descriptions to these rules ASAP.
> Thanks.
> 
> We have encapsulated the rules in a check for DKIM and SPF.
> 
> Best to report issues with KAM.cf as noted in the file :-)  Happy to
> look at samples.  I would imagine you might have something breaking DKIM
> in your environment with FPs as my first guess.  We've had this in
> production and so does another ISP with no other FPs reported.
> 

While I am for this rule helping all SA instances with KAM.cf added, 
it's pretty risky to put this rule in with a default score higher than 
1.0 as there are so many ways that SA can be launched/integrated.

Perhaps it needs to be named KAM_DMARC_REJECT to make it obvious that it 
came from the KAM.cf and have a default score of 0.001?

I have my own rule for DMARC_REJECT that is tied closely to the headers 
added by OpenDMARC which is going to be more reliable / less risky due 
to it being linked to the MTA as a milter.

If SA is being run post MTA (i.e. inside Thunderbird) then any filtering 
can change the content to remove potentially bad attachments, add an 
"EXTERNAL" warning to the Subject or body, etc. which will break DKIM 
signing.

-- 
David Jones


Re: 3.4.3 release Re: DMARC_REJECT?

2019-11-15 Thread David Jones
On 11/15/19 1:02 AM, Kevin A. McGrail wrote:
> 
>> how more longer will it take to make 3.4.3 realease by looking ? :=)
> 
> Right now, I'm working through bugs found by myself and my staff to make
> sure the release is up to snuff.
> 
> The biggest delay is a lack of feedback and testing.  Please grab rc6
> and give feedback.
> 

I have been running 3.4.3 rc6 for a few days in production and no 
problems so far on my cluster of 12 SA servers with a pretty good volume 
of emails (about 600,000 per day hit SA).

-- 
David Jones


Re: How to Bypass Specific Spamassassin Rule

2019-11-15 Thread Henrik K


If you don't want to hit it at all for some recipient, you can try
redefining the whole UNWANTED_LANGUAGE_BODY rule into a meta.

body __UNWANTED_LANGUAGE_BODY eval:check_language()
header __UNWANTED_LANGUAGE_SKIP X-Envelope-To =~ /\@foo\.com>/i
meta UNWANTED_LANGUAGE_BODY __UNWANTED_LANGUAGE_BODY && 
!__UNWANTED_LANGUAGE_SKIP

Note that X-Envelope-To might be Amavis specific header..  you can check
basic To header also, but it can be faked or missing unlike envelope
address.


On Fri, Nov 15, 2019 at 11:51:12AM +0530, KADAM, SIDDHESH wrote:
> Hi Folks,
> 
> I have multiple domains which are running after Spamassassin server.
> 
> I want to bypass one specific Spamassassin rule ie TextCat(Unwanted
> Language) for one recipient domain.
> 
> Can someone please help me in achieving this requirement.
> 
> Regards,
> Siddhesh


Re: How to Bypass Specific Spamassassin Rule

2019-11-15 Thread Matus UHLAR - fantomas

On 15.11.19 11:51, KADAM, SIDDHESH wrote:

I have multiple domains which are running after Spamassassin server.

I want to bypass one specific Spamassassin rule ie TextCat(Unwanted 
Language) for one recipient domain.


how do you run spamassassin? with spamass-milter you can use per-recipient
ok_languages setting.

if amavis (global settings), wouldn't it be better to add that language to
ok_languages

I feel amavis can use per-destination domain rules, is you use it, maybe ask
in its list?

--
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.
It's now safe to throw off your computer.