[Bug 7247] New: SPF: increase max_void_dns_lookups

[bu...@bugzilla.spamassassin.org]

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

            Bug ID: 7247
           Summary: SPF: increase max_void_dns_lookups
           Product: Spamassassin
           Version: 3.4.1
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: spamassassin
          Assignee: dev@spamassassin.apache.org
          Reporter: sebastiaanlokhorst@gmail.com

According to the latest RFC 7208, section 11.1, there should be a maximum of 2
"void DNS lookups". (Specifically, the DNS look-ups that are subject to this
limit are those caused by the a, mx, ptr, and exists mechanisms and the p
macro.)

The current Perl Mail::SPF module implements this[1], which causes every
SPF-check against a domain which has more than e.g. 2 "a:" fields in their
SPF-record to receive a permerror, effectively not doing the SPF-check at all.

I have come across a few websites who do have more than 2 "a:" fields in their
SPF-record, because they are not aware of this limitation. The result is that I
cannot use SpamAssassin to SPF-check them.

So I ask to increase the max_void_dns_lookups value when calling Mail::SPF,
just like we do with max_dns_interactive_terms. This is done done by adding
"max_void_dns_lookups => 10" in Plugin/SPF.pm on line 506.


[1] http://search.cpan.org/~jmehnle/Mail-SPF-v2.9.0/lib/Mail/SPF/Server.pm

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

[Bug 7247] SPF: increase max_void_dns_lookups

[bu...@bugzilla.spamassassin.org]

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

Sebastiaan <se...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sebastiaanlokhorst@gmail.co
                   |                            |m
         Resolution|---                         |INVALID

--- Comment #1 from Sebastiaan <se...@gmail.com> ---
Nevermind, I misunderstood the meaning of "void lookups".

I'm sorry for the noise.

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

[Bug 7247] SPF: increase max_void_dns_lookups

[bu...@bugzilla.spamassassin.org]

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

Joe Quinn <jq...@pccc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jquinn+SAbug@pccc.com

--- Comment #2 from Joe Quinn <jq...@pccc.com> ---
Ironically, this is the one case of bad SPF records that the spec would
actually allow us to do anything about

http://serverfault.com/questions/666282/permerror-spf-permanent-error-void-lookup-limit-of-2-exceeded

SPF implementations SHOULD limit "void lookups" to two. An implementation MAY
choose to make such a limit configurable. In this case, a default of two is
RECOMMENDED. Exceeding the limit produces a "permerror" result.

If anyone can point out real-world examples of SPF records performing too many
NXDOMAIN or empty NOERROR lookups, your suggestion is perfect. According to the
link above, Microsoft was having that issue at some point this year.

Considering some large organizations can't even keep to under 10 lookups, it
would be interesting to see what ends up being the case for this.

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

[Bug 7247] SPF: increase max_void_dns_lookups

[bu...@bugzilla.spamassassin.org]

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

Benny Pedersen <me...@junc.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |me@junc.eu

--- Comment #3 from Benny Pedersen <me...@junc.eu> ---
i think email service providders can change there problem to make all there mta
for outgoing emails into a single cidr range, and then put all incomming into
another or samme as outgoing cidr range will solve spf problems very nicely

but it needs ip change of every host to do so, but if big email hosters begin
to understand that, it would be more spf safe in the end

just my 1€ :-)

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