Mailing List Archive

>
> >X-Spam-Status: No, score=-2.383 tagged_above=-200 required=5
> > tests=[.BAYES_00=-1.9, DCC_REPUT_00_12=-0.4, DKIM_SIGNED=0.1,
> > DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DMARC_REJECT=0.1,
> > FROM_EXCESS_BASE64=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25,
> > HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, KAM_DMARC_REJECT=1,
> > KAM_REALLYHUGEIMGSRC=0.5, LOC_MKTING=0.25, MIME_HTML_ONLY=0.1,
> > POISEN_SPAM_PILL=0.1, POISEN_SPAM_PILL_1=0.1,
> > RCVD_IN_HOSTKARMA_W=-2.5, RCVD_IN_SENDERSCORE_90_100=-0.6,
> > RELAYCOUNTRY_US=0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
> > TXREP=0.714, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=disabled
>
> did you reload/restart amavis after installing new SA?
> This header is added by amavis which uses SA libraries internally.
>

Yes, thanks. This has been ongoing for weeks.

>> >X-Spam-Status: No, score=-2.383 tagged_above=-200 required=5
>> > tests=[.BAYES_00=-1.9, DCC_REPUT_00_12=-0.4, DKIM_SIGNED=0.1,
>> > DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DMARC_REJECT=0.1,
>> > FROM_EXCESS_BASE64=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25,
>> > HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, KAM_DMARC_REJECT=1,
>> > KAM_REALLYHUGEIMGSRC=0.5, LOC_MKTING=0.25, MIME_HTML_ONLY=0.1,
>> > POISEN_SPAM_PILL=0.1, POISEN_SPAM_PILL_1=0.1,
>> > RCVD_IN_HOSTKARMA_W=-2.5, RCVD_IN_SENDERSCORE_90_100=-0.6,
>> > RELAYCOUNTRY_US=0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
>> > TXREP=0.714, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=disabled
>>
>> did you reload/restart amavis after installing new SA?
>> This header is added by amavis which uses SA libraries internally.

On 30.05.22 09:50, Alex wrote:
>Yes, thanks. This has been ongoing for weeks.

doesn't amavisd by any chance use old SA installation/libraries?

--
Matus UHLAR - fantomas, uhlar@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.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*

>
>
>
> >> did you reload/restart amavis after installing new SA?
> >> This header is added by amavis which uses SA libraries internally.
>
> On 30.05.22 09:50, Alex wrote:
> >Yes, thanks. This has been ongoing for weeks.
>
> doesn't amavisd by any chance use old SA installation/libraries?
>

I don't think so - the current paths it uses are:

/usr/share/spamassassin
/var/lib/spamassassin/4.000000/updates_spamassassin_org
/var/lib/spamassassin/4.000000/kam_sa-channels_mcgrail_com
/etc/mail/spamassassin/

May 30 15:05:16.089 [1254396] dbg: generic: Perl 5.034001, PREFIX=/usr,
DEF_RULES_DIR=/usr/share/spamassassin,
LOCAL_RULES_DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/va
r/lib/spamassassin

The only rules in the /var/lib/spamassassin/ directory are those listed
above.

I used to have a local DMARC.cf file in /etc/mail/spamassassin before DMARC
was included in v4, but that's been removed.

If I understand Kevin's comments correctly, we know there are still DMARC
problems. I think maybe this is related?

$ spamassassin -t -D DMARC < dmarc-reject1 2>&1|grep -i dmarc
May 30 14:59:14.894 [1250699] dbg: DMARC: using Mail::DMARC::PurePerl for
DMARC checks
May 30 14:59:15.034 [1250699] dbg: DMARC: result: pass, disposition: none,
dkim: pass, spf: fail (spf: pass, spf_helo: fail)
DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,

Did SPF fail or pass above? It did hit SPF_PASS but it also
hit SPF_HELO_NONE.

It is curious that SA succeeds on its own but it's under amavisd that it
appears to fail.

I also see the following debug messages:

May 30 15:06:54.097 [1255659] dbg: check: tagrun - tag AUTHORDOMAIN is now
ready, value: indeedemail.com
May 30 15:06:54.325 [1255659] dbg: askdns: rule __KAM_DMARC_POLICY_REJECT
depends on tags: AUTHORDOMAIN
May 30 15:06:54.325 [1255659] dbg: check: tagrun - tag AUTHORDOMAIN was
ready, runnable immediately: CODE(0x563c09e23d70)
May 30 15:06:54.325 [1255659] dbg: askdns: launching query
(__KAM_DMARC_POLICY_REJECT): _dmarc.indeedemail.com
May 30 15:06:54.325 [1255659] dbg: async: query 50034/IN/TXT/_
dmarc.indeedemail.com already underway, adding no.4, rules:
__KAM_DMARC_POLICY_REJECT
May 30 15:06:54.518 [1255659] dbg: async: calling callback on key TXT/_
dmarc.indeedemail.com, rules: __KAM_DMARC_POLICY_REJECT
May 30 15:06:54.518 [1255659] dbg: askdns: answer received
(__KAM_DMARC_POLICY_REJECT), rcode NOERROR, query IN/TXT/_
dmarc.indeedemail.com, answer has 1 records
May 30 15:06:54.518 [1255659] dbg: askdns: domain "_dmarc.indeedemail.com"
listed (__KAM_DMARC_POLICY_REJECT): v=DMARC1; p=reject; sp=reject;
rua=mailto:f48jz-9178@rua.dm
arc.emailanalyst.com,mailto:dmarc@indeed.com; ruf=mailto:
f48jz-9178@ruf.dmarc.emailanalyst.com; adkim=r; aspf=r; pct=100

So it did hit __KAM_DMARC_POLICY_REJECT but just not whatever else was
necessary to fulfill the requirements for the KAM_DMARC_REJECT when run
with SA manually.

On 2022-05-30 at 15:12:34 UTC-0400 (Mon, 30 May 2022 15:12:34 -0400)
Alex <mysqlstudent@gmail.com>
is rumored to have said:

[...]
> $ spamassassin -t -D DMARC < dmarc-reject1 2>&1|grep -i dmarc
> May 30 14:59:14.894 [1250699] dbg: DMARC: using Mail::DMARC::PurePerl
> for
> DMARC checks
> May 30 14:59:15.034 [1250699] dbg: DMARC: result: pass, disposition:
> none,
> dkim: pass, spf: fail (spf: pass, spf_helo: fail)
> DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,
>
> Did SPF fail or pass above? It did hit SPF_PASS but it also
> hit SPF_HELO_NONE.

SPF_PASS tells you that the envelope sender domain has a SPF record that
validates the connecting IP.

SPF_HELO_NONE tells you that the client introduced itself with a
hostname that has no SPF record.

Those two states are not in any fundamental conflict with each other.

> It is curious that SA succeeds on its own but it's under amavisd that
> it
> appears to fail.

This would imply that amavisd has one of these issues relative to
running the spamassassin script from the command line:

1. It is using different user-level preferences.
2. It is using different systemwide rules & preferences.
3. It is unable to access something on the system due to security config
(permissions, SELinux, AppArmor, chrooting, etc.) that your login shell
is able to access.
4. Something substantive has changed between when amavisd ran and when
you are checking manually, e.g. DNSBL changes, custom DNS config, new
rules, etc.

If you can eliminate all of those, you will have established the
existence of magic.

> I also see the following debug messages:
>
> May 30 15:06:54.097 [1255659] dbg: check: tagrun - tag AUTHORDOMAIN is
> now
> ready, value: indeedemail.com
> May 30 15:06:54.325 [1255659] dbg: askdns: rule
> __KAM_DMARC_POLICY_REJECT
> depends on tags: AUTHORDOMAIN
> May 30 15:06:54.325 [1255659] dbg: check: tagrun - tag AUTHORDOMAIN
> was
> ready, runnable immediately: CODE(0x563c09e23d70)
> May 30 15:06:54.325 [1255659] dbg: askdns: launching query
> (__KAM_DMARC_POLICY_REJECT): _dmarc.indeedemail.com
> May 30 15:06:54.325 [1255659] dbg: async: query 50034/IN/TXT/_
> dmarc.indeedemail.com already underway, adding no.4, rules:
> __KAM_DMARC_POLICY_REJECT
> May 30 15:06:54.518 [1255659] dbg: async: calling callback on key
> TXT/_
> dmarc.indeedemail.com, rules: __KAM_DMARC_POLICY_REJECT
> May 30 15:06:54.518 [1255659] dbg: askdns: answer received
> (__KAM_DMARC_POLICY_REJECT), rcode NOERROR, query IN/TXT/_
> dmarc.indeedemail.com, answer has 1 records
> May 30 15:06:54.518 [1255659] dbg: askdns: domain
> "_dmarc.indeedemail.com"
> listed (__KAM_DMARC_POLICY_REJECT): v=DMARC1; p=reject; sp=reject;
> rua=mailto:f48jz-9178@rua.dm
> arc.emailanalyst.com,mailto:dmarc@indeed.com; ruf=mailto:
> f48jz-9178@ruf.dmarc.emailanalyst.com; adkim=r; aspf=r; pct=100
>
> So it did hit __KAM_DMARC_POLICY_REJECT but just not whatever else was
> necessary to fulfill the requirements for the KAM_DMARC_REJECT when
> run
> with SA manually.

__KAM_DMARC_POLICY_REJECT means that the DMARC record for the domain
part of the From header address has a p=reject attribute.

KAM_DMARC_REJECT requires __KAM_DMARC_POLICY_REJECT and NEITHER a
verified DKIM signature from the domain part of the From header address
(DKIM_VALID_AU) NOR a SPF_PASS for the domain part of the envelope
sender address, which must match the domain part of the From header
address.


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

>> >> did you reload/restart amavis after installing new SA?
>> >> This header is added by amavis which uses SA libraries internally.
>>
>> On 30.05.22 09:50, Alex wrote:
>> >Yes, thanks. This has been ongoing for weeks.

>> doesn't amavisd by any chance use old SA installation/libraries?

On 30.05.22 15:12, Alex wrote:
>I don't think so - the current paths it uses are:
>
>/usr/share/spamassassin
>/var/lib/spamassassin/4.000000/updates_spamassassin_org
>/var/lib/spamassassin/4.000000/kam_sa-channels_mcgrail_com
>/etc/mail/spamassassin/

these are rules, not libraries.
there is a possibility that you have multiple versions of SA installed and
amavis uses the old one.

try running:

% locate SpamAssassin.pm DMARC.pm

to see if there are some that shouldn't be...

>If I understand Kevin's comments correctly, we know there are still DMARC
>problems. I think maybe this is related?
>
>$ spamassassin -t -D DMARC < dmarc-reject1 2>&1|grep -i dmarc
>May 30 14:59:14.894 [1250699] dbg: DMARC: using Mail::DMARC::PurePerl for
>DMARC checks
>May 30 14:59:15.034 [1250699] dbg: DMARC: result: pass, disposition: none,
>dkim: pass, spf: fail (spf: pass, spf_helo: fail)
> DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,

it hit DMARC_PASS, which is the opposite of DMARC_REJECT or
KAM_DMARC_REJECT.

>So it did hit __KAM_DMARC_POLICY_REJECT but just not whatever else was
>necessary to fulfill the requirements for the KAM_DMARC_REJECT when run
>with SA manually.

__KAM_DMARC_POLICY_REJECT only says that the sender domain has DMARC policy
set to reject, it does not say that the mail is to be rejected


--
Matus UHLAR - fantomas, uhlar@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.
Linux is like a teepee: no Windows, no Gates and an apache inside...

Hi,


> >> doesn't amavisd by any chance use old SA installation/libraries?
>
> On 30.05.22 15:12, Alex wrote:
> >I don't think so - the current paths it uses are:
> >
> >/usr/share/spamassassin
> >/var/lib/spamassassin/4.000000/updates_spamassassin_org
> >/var/lib/spamassassin/4.000000/kam_sa-channels_mcgrail_com
> >/etc/mail/spamassassin/
>
> these are rules, not libraries.
>

Yes, I was responding to the "installation" part of your question.

there is a possibility that you have multiple versions of SA installed and
> amavis uses the old one.
>
> try running:
>
> % locate SpamAssassin.pm DMARC.pm
>

# locate SpamAssassin.pm DMARC.pm
/usr/share/perl5/vendor_perl/Mail/DMARC.pm
/usr/share/perl5/vendor_perl/Mail/SpamAssassin.pm
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DMARC.pm

# ls -l /usr/share/perl5/vendor_perl/Mail/DMARC.pm
/usr/share/perl5/vendor_perl/Mail/SpamAssassin.pm
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/
DMARC.pm
-rw-r--r-- 1 root root 18600 Dec 8 23:01
/usr/share/perl5/vendor_perl/Mail/DMARC.pm
-r--r--r-- 1 root root 9752 May 29 11:14
/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DMARC.pm
-r--r--r-- 1 root root 77572 May 29 11:14
/usr/share/perl5/vendor_perl/Mail/SpamAssassin.pm

# rpm -qf /usr/share/perl5/vendor_perl/Mail/DMARC.pm
perl-Mail-Dmarc-PurePerl-1.20211209-3.fc35.noarch

# rpm -qf /usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DMARC.pm
spamassassin-4.0.0-85.fc35.x86_64

Those are both packages I've created and built for fedora and are based on
existing fedora packages.

>If I understand Kevin's comments correctly, we know there are still DMARC
> >problems. I think maybe this is related?
> >
> >$ spamassassin -t -D DMARC < dmarc-reject1 2>&1|grep -i dmarc
> >May 30 14:59:14.894 [1250699] dbg: DMARC: using Mail::DMARC::PurePerl for
> >DMARC checks
> >May 30 14:59:15.034 [1250699] dbg: DMARC: result: pass, disposition: none,
> >dkim: pass, spf: fail (spf: pass, spf_helo: fail)
> > DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,
>
> it hit DMARC_PASS, which is the opposite of DMARC_REJECT or
> KAM_DMARC_REJECT.
>

I was referring to the "spf: fail" component of that, which appears to
conflict with the "spf: pass" within the parentheses. Perhaps the first is
result of the combination of the two checks (HELO and envelope)?