You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@spamassassin.apache.org on 2022/08/01 14:19:40 UTC

[Bug 8021] New: SPF false positives

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

            Bug ID: 8021
           Summary: SPF false positives
           Product: Spamassassin
           Version: 3.4.6
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: Libraries
          Assignee: dev@spamassassin.apache.org
          Reporter: calaad@calaad.net
  Target Milestone: Undefined

Hello, 

I am using Spamassassin v3.4.6-1, installed from the Debian Bulleyes
repositories. 

I have SPF errors for domains that have a valid SPF record consistent with the
sending address:

spamd[3561832]: spf: using Mail::SPF for SPF checks
spamd[3561832]: spf: checking EnvelopeFrom (helo=massgateway3c.dhl.com,
ip=165.72.200.106, envfrom=noreply@dhl.com)
spamd[3561832]: dns: reply to 11241/IN/TXT/dhl.com truncated (EDNS 65535
bytes), 0 answer records
spamd[3561832]: dns: reply to 12708/IN/TXT/dhl.com truncated (EDNS 65535
bytes), 0 answer records
spamd[3561832]: spf: query for
noreply@dhl.com/165.72.200.106/massgateway3c.dhl.com: result: none, comment: ,
text: No applicable sender policy available

The same query sent directly from the command line via Mail::SPF is still
valid: 

# spfquery --scope mfrom --id noreply@dhl.com --ip 165.72.200.106
pass
dhl.com: Sender is authorized to use 'noreply@dhl.com' in 'mfrom' identity
(mechanism 'include:dpdhl._spf.dhl.com' matched)
dhl.com: Sender is authorized to use 'noreply@dhl.com' in 'mfrom' identity
(mechanism 'include:dpdhl._spf.dhl.com' matched)
Received-SPF: pass (dhl.com: Sender is authorized to use 'noreply@dhl.com' in
'mfrom' identity (mechanism 'include:dpdhl._spf.dhl.com' matched))
receiver=d44.altospam.com; identity=mailfrom; envelope-from="noreply@dhl.com";
client-ip=165.72.200.106

From what I can see, this error occurs when the response to the DNS query is
too long and is therefore truncated. 

I have tried increasing the buffer size and forcing the use of "Mail::SPF" in
"local.cf": 
do_not_use_mail_spf 0
do_not_use_mail_spf_query 1
dns_options edns=65535

No change. 

I don't know if the problem is in "Mail::SpamAssassin::Plugin::SPF", in
"Mail::SPF" or in another library. I confess I don't know where to look
anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8021] SPF false positives

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

Bill Cole <bi...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |billcole@apache.org

--- Comment #1 from Bill Cole <bi...@apache.org> ---
If the response is truncated, the correct behavior would be to retry using TCP.
It isn't clear to me why that's not happening. 

Your DNS option edns=65535 may be the source of the problem and I don't think
we can  do anything about it if that is the case. Please test with edns=512
(disabling EDNS) or no setting (equivalent to edns=4096) to see if that is in
fact the cause.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8021] SPF false positives

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

Kevin A. McGrail <km...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kmcgrail@apache.org

--- Comment #7 from Kevin A. McGrail <km...@apache.org> ---
Also, make sure if you are using a local resolver and you have firewalls/port
forwarding/etc. that you allow port 53 for UDP and TCP.  Many people don't
realize DNS can use both protocols.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8021] SPF false positives

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

--- Comment #3 from Bill Cole <bi...@apache.org> ---
Can you attach a sample message that demonstrates the issue to this report?
Sensitive information (e.g. recipient address, tracking numbers, etc.) can be
redacted.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8021] SPF false positives

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

Bill Cole <bi...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #5 from Bill Cole <bi...@apache.org> ---
(In reply to calaad from comment #4)
[...]
> Problem seems to come from resolver. When i configure public resolver, like
> 1.1.1.1, all works good. Problem only occurs when i use my bind9 local
> resolver. 

That's a serious clue. 

> So, I'm not sure if the problem is related to Spamassassin.  
> 
> Using 
> options {
>     edns-udp-size 4096;
>     max-udp-size 4096;
> };
> 
> in named.conf seems to make it works. 

Confirmed. I obtained a sample from elsewhere, reproduced the error, reproduced
the fix. 

Unvalidated guess: bug/misfeature in Net::DNS disabling TCP fallback. 

Thanks for finding the fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8021] SPF false positives

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

--- Comment #6 from calaad@calaad.net ---

> Unvalidated guess: bug/misfeature in Net::DNS disabling TCP fallback. 


Thre is a "igntc" flag in Net:DNS::Resolver that could be involved 

igntc

Get or set the igntc flag. If true, truncated packets will be ignored. If
false, the query will be retried using TCP. The default is false.

But, playing with it, i was not able to change the behaviour.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8021] SPF false positives

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

--- Comment #4 from calaad@calaad.net ---
(In reply to Bill Cole from comment #3)
> Can you attach a sample message that demonstrates the issue to this report?
> Sensitive information (e.g. recipient address, tracking numbers, etc.) can
> be redacted.

Sorry but no, i can't post complete message, even anonymized.

Problem seems to come from resolver. When i configure public resolver, like
1.1.1.1, all works good. Problem only occurs when i use my bind9 local
resolver. 

So, I'm not sure if the problem is related to Spamassassin.  

Using 
options {
    edns-udp-size 4096;
    max-udp-size 4096;
};

in named.conf seems to make it works. 

Sorry for the noise and thanks Bill !

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8021] SPF false positives

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8021

calaad@calaad.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |calaad@calaad.net

--- Comment #2 from calaad@calaad.net ---
(In reply to Bill Cole from comment #1)

> Your DNS option edns=65535 may be the source of the problem and I don't
> think we can  do anything about it if that is the case. Please test with
> edns=512 (disabling EDNS) or no setting (equivalent to edns=4096) to see if
> that is in fact the cause.

edns=512

spamd[2446951]: spf: using Mail::SPF for SPF checks
spamd[2446951]: spf: checking EnvelopeFrom (helo=gateway2c.dhl.com,
ip=199.40.206.35, envfrom=support@dhl.com)
spamd[2446951]: dns: reply to 31060/IN/TXT/dhl.com truncated (EDNS off), 3
answer records
spamd[2446951]: dns: reply to 58756/IN/TXT/dhl.com truncated (EDNS off), 6
answer records
spamd[2446951]: spf: query for support@dhl.com/199.40.206.35/gateway2c.dhl.com:
result: none, comment: , text: No applicable sender policy available

edns=4096 

spamd[2570448]: spf: using Mail::SPF for SPF checks
spamd[2570448]: spf: checking EnvelopeFrom (helo=gateway2b.dhl.com,
ip=199.40.206.34, envfrom=support@dhl.com)
spamd[2570448]: dns: reply to 22640/IN/TXT/dhl.com truncated (EDNS 4096 bytes),
0 answer records
spamd[2570448]: dns: reply to 6296/IN/TXT/dhl.com truncated (EDNS 4096 bytes),
0 answer records
spamd[2570448]: spf: query for support@dhl.com/199.40.206.34/gateway2b.dhl.com:
result: none, comment: , text: No applicable sender policy available

> If the response is truncated, the correct behavior would be to retry using TCP.
I agree with you, this should be the normal behaviour

-- 
You are receiving this mail because:
You are the assignee for the bug.