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...@bugzilla.spamassassin.org on 2009/10/11 12:42:54 UTC
[Bug 6221] New: DnsResolver.pm attempts to bind ports at random
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Summary: DnsResolver.pm attempts to bind ports at random
Product: Spamassassin
Version: 3.2.5
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: Libraries
AssignedTo: dev@spamassassin.apache.org
ReportedBy: spamassassin.bugzilla.apache.simon@arlott.org
Created an attachment (id=4551)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4551)
Patch to always use port 0 instead of trying ports at random
DnsResolver.pm attempts to bind UDP ports at random. This causes numerous
errors if listening on specific ports is restricted to specific
applications/users.
The correct way to acquire a UDP socket to listen for responses is to bind to
port 0 instead. The OS will automatically allocate an appropriate free port
from the range defined for local allocation (net.ipv4.ip_local_port_range on
Linux).
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P5 |P3
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #15 from Sidney Markowitz <si...@sidney.com> 2010-01-27 13:29:45 UTC ---
(in response to comment #14)
> it should keep whichever port it finds until it's done with all its queries
That is not true if it could have well more than 65536 queries. But it is true
if the lifetime of a spamd child process is less than that number of queries,
which means that number divided by the average number of DNS queries per
message. I think we are dealing with on the order of 50 to 100 queries per
message processed. What is the lifetime of a spamd child process expressed as
number of messages processed on a very active system? Have the assumptions
about that changed since bug 4260?
I am very ready to find out that one or more of the underlying assumptions that
led to the design used in bug 4260 are no longer valid, but I want to make sure
that we understand all of the issues before changing things. I hope you don't
think that I am arguing with you about this -- It is all in the spirit of
trying to dig as deep into the details as possible.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #10 from Simon Arlott <sp...@arlott.org> 2010-01-27 10:45:41 UTC ---
(In reply to comment #9)
> (in reply to comment #8)
>
> I didn't reference the Dan Kaminsky vulnerability because of security concerns,
> so using a trusted filtered local server or whatever is not the issue. If you
> go back through the complicated discussion in bug 4260 the point is to assure
> that the 32 bit combination of port and ID do not get reused within the
> possible lifetime of a DNS request and its reply. The insight we got from that
> bug was that there really are so many DNS queries that a 16 bit space just from
> the ID is not enough to avoid collisions. It is the same problem that the
Specifically, it would need to be lots of queries that are timing out.
Successful queries will not cause problems.
> Kaminsky vulnerability was based on, which is why I am wondering if the
> solution to that vulnerability, which should be pretty universally deployed
> now, has now spread the port/ID combination that is seen in practice out over
> more of the possible 32-bit space, rendering the code that we put in no longer
> necessary.
The solution to the vulnerability is to use an unpredictable source port on the
client side, so it has no effect on SpamAssassin's need to avoid receiving a
response to an older request.
On any deployment where there is an actual need to handle huge numbers of DNS
queries, the local nameserver should have an appropriate query timeout (ideally
this value would be in the request message but it's not). This would work much
more reliably than pseudo-random port/ID selection because the nameserver
wouldn't be replying to queries that SA had given up on.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #8 from Simon Arlott <sp...@arlott.org> 2010-01-27 04:51:01 UTC ---
(In reply to comment #4)
> I didn't notice or pay attention to this bug when it was opened three or four
> months ago and just looked it over now.
>
> I think bug #4260 comment #49 contains the reason not to let the OS pick a
> "suitable" port. We need to have the port numbers spread so that they do not
> get re-used by any of the spamd child processes over a lifetime that is
> determined by how long it can take for any DNS server to finally respond to a
> query. The OS has no reason to randomize the ports, it can re-use a port number
> as soon as there is no active listener for it.
Linux iterates through the available ports. Randomly selecting ports can easily
steal a port that should have been available for something else.
Responding to a DNS query after the client has timed out is a potential
problem, but randomly selecting ports doesn't guarantee a fix either. It can't
even guarantee a free port will be found within N attempts. If the ports used
are iterative then the query ID (assuming the resolver is trusted; see below)
can be based on time to filter out old responses.
Can't a configuration option be added to let the OS assign a port?
> Does anyone know if the big security fix for all DNS implementations in July
> 2008 took care of this for us so using port 0 is now ok? See, for example this
> article:
>
> http://news.cnet.com/8301-10789_3-9985618-57.html
This is irrelevant when querying a trusted local resolver. Assuming there is an
appropriate filter on incoming spoofed traffic.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #13 from Sidney Markowitz <si...@sidney.com> 2010-01-27 13:03:15 UTC ---
As we discuss this, I'm remembering more from when I worked on bug 4620.
SpamAssassin selects a port number at random and then increments from there.
That is to keep two processes from working in the same range of ports.
If, as you say for Linux, the counter that iterates through port numbers is
system wide and not per process, then this would not be necessary and I think
your patch would work and would be better.
I don't think that we can count on that behavior. I certainly didn't see it in
the tests I ran for bug 4260. When I did that I was testing under Cygwin on
Windows and Fedora Core 3. It would be good to have a simple test that shows
how the port selection goes with repeated UDP port 0 socket creation across
different processes, and test that on different platforms.
Your idea of making it a configuration option may be the way to go if it is
possible to easily test what a particular system's behavior is, even if it is a
test that a sysadmin has to run manually to help decide how to set the
configuration option.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #22 from Mark Martinec <Ma...@ijs.si> 2010-03-30 14:24:31 UTC ---
Bug 6221: DnsResolver.pm attempts to bind ports at random:
make auxiliary data structures initializations more
self-contained to avoid undef warnings in t/dnsbl_subtests.t;
save about 10 kB when port allocation task is delegated to OS
Sending lib/Mail/SpamAssassin/Conf.pm
Sending lib/Mail/SpamAssassin/DnsResolver.pm
Committed revision 929150.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Karsten Bräckelmann <gu...@rudersport.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Group|security |
Component|Security |Libraries
AssignedTo|security@spamassassin.apach |dev@spamassassin.apache.org
|e.org |
--- Comment #19 from Karsten Bräckelmann <gu...@rudersport.de> 2010-03-23 17:42:15 UTC ---
Moving back off of Security, which got changed by accident during the mass
Target Milestone move.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #17 from Sidney Markowitz <si...@sidney.com> 2010-01-27 19:19:56 UTC ---
(in reply to comment #16)
The queries are all sent before the rest of the rule processing, then the
replies are gathered at the end. Once the rest of the rules have been
processed, outstanding queries are polled in a nonblocking manner and each
reply is processed as it is found, until some timout is reached the the
remaining ones are dropped. Those are the ones that have the potential of
causing a problem if they arrive during the polling of the queries of another
message.
Since all the queries go out at once at the beginning, it wouldn't be possible
to reuse an ID after a reply is received.
I seem to recall that the new port per query was something that was tried and
dropped while working on bug 4260, but I'm not sure of that.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #16 from Simon Arlott <sp...@arlott.org> 2010-01-27 13:47:53 UTC ---
(In reply to comment #15)
> (in response to comment #14)
> > it should keep whichever port it finds until it's done with all its queries
> That is not true if it could have well more than 65536 queries.
Once you have a response, you can reuse the ID. Ideally it would poll the
socket in a non-blocking manner before doing each new query to attempt to
cleanup old queries more quickly.
> I am very ready to find out that one or more of the underlying assumptions that
> led to the design used in bug 4260 are no longer valid, but I want to make sure
> that we understand all of the issues before changing things. I hope you don't
> think that I am arguing with you about this -- It is all in the spirit of
> trying to dig as deep into the details as possible.
It appears that the previous code which that bug addresses used to request a
new port for every query (perhaps because it didn't use/verify the ID?). That's
far more likely to be the cause of the problems observed, with multiple
processes using hundreds of ports and then dropping them too quickly when they
don't respond.
The OS could also have been allocating ports inappropriately too, but this
should have affected DNS resolution for all applications because a port is
always needed to do a query.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #21 from Mark Martinec <Ma...@ijs.si> 2010-03-29 18:00:10 UTC ---
The related Bug 5264 (to a large extent a duplicate) has been closed
as its immediate goal has now been met. Further discussion on whether
randomization is still necessary etc. can take place here.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Simon Arlott <sp...@arlott.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |spamassassin.bugzilla.apach
| |e.simon@arlott.org
--- Comment #2 from Simon Arlott <sp...@arlott.org> 2009-10-15 11:02:26 UTC ---
(In reply to comment #1)
> While I agree in general, I think there was some underlying reason for the
> current hack, but I can't find a reference now. Possibly something to do
> with mismatching DNS replies with queries. Moving to 3.3.0 target.
According to the SVN log for revision 161778, it is the Net::DNS code that
mismatched DNS replies. The original bug that introduced this "select a random
port" behaviour is 4260.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #12 from Simon Arlott <sp...@arlott.org> 2010-01-27 12:45:47 UTC ---
(In reply to comment #11)
> (in reply to comment 10)
>
> You are correct that the fix to Dan Kaminsky's security problem involved making
> the port unpredictable, but wouldn't that imply using a port number selected
> randomly from the entire space of available ports within the 16 bit space? A
> single server can't keep reusing the same one or few port numbers because then
> an attacker can spend a little time looking at which ones are being used and it
> would be predictable. So I would think that maybe we get what we need from the
> security fix. I haven't had time to test this out, but when we were working on
The fix is an unrelated issue and concerns the communication between your local
caching nameserver and remote servers. The only similarities are the need to
use the full range of ports and IDs (previous DNS servers only ever using one
source port being most vulnerable to this).
> this, before the big DNS security fix, I found that when the OS chose the port
> it wold just start with the first number in the available range, then increment
> the port number with each new port, and do that with each process. It woud be
> interesting to see what the pattern looks like now.
It still does this on Linux (but the new port is global not per process).
> I don't see how we can make a timeout work. here is what happens: A query is
> sent out on port A with 16-bit ID B. No response is received within the
> lifetime of the listener and the listener times out. Possibly another process
> sends out a query that also is on port A with ID B. Then the reply from the
> first query finally arrives from the remote nameserver, arriving on port A with
> ID B, and that reply is incorrectly processed by the listener that is waiting
> for the reply to the second query.
>
> Where can we or the sysadmin put a timeout that would help in that scenario?
Remote nameservers should not be used because SA does not cache replies. A
local caching nameserver is required to be efficient (or you keep externally
querying the same records over an over again every time the same IP/domain
sends you email).
Two processes cannot share the same port, and you control both SA and the local
nameserver. As long as the local nameserver discards the query from SA when it
knows SA will time out waiting for a response, there is no problem with replies
going to the wrong process.
Nameservers typically have much longer timeouts that their clients (which the
RFC allows for, as clients are supposed to simply retry [another server]).
> The purpose of randomising the port is so that the probability of the almost
> 32-bit combination of port and ID colliding is too low to worry about. If too
> few port numbers are used the probability of collision on just the 16 bit ID is
> too high for the number of DNS queries that are generated in a high volume
> situation.
The full range of local source ports is available. There is no reason why
iterating through them should be any worse than the (not guaranteed) random
selection. The implication that a small port range will cause SA major issues
means that the configuration option would need to be "OS allocated" or "random"
and not allow a range.
In either case, it should be possible to stop SA trying to bind arbitrary ports
that it chooses as it does not necessarily have free reign over the system.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #9 from Sidney Markowitz <si...@sidney.com> 2010-01-27 09:27:22 UTC ---
(in reply to comment #8)
I didn't reference the Dan Kaminsky vulnerability because of security concerns,
so using a trusted filtered local server or whatever is not the issue. If you
go back through the complicated discussion in bug 4260 the point is to assure
that the 32 bit combination of port and ID do not get reused within the
possible lifetime of a DNS request and its reply. The insight we got from that
bug was that there really are so many DNS queries that a 16 bit space just from
the ID is not enough to avoid collisions. It is the same problem that the
Kaminsky vulnerability was based on, which is why I am wondering if the
solution to that vulnerability, which should be pretty universally deployed
now, has now spread the port/ID combination that is seen in practice out over
more of the possible 32-bit space, rendering the code that we put in no longer
necessary.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #11 from Sidney Markowitz <si...@sidney.com> 2010-01-27 11:37:01 UTC ---
(in reply to comment 10)
You are correct that the fix to Dan Kaminsky's security problem involved making
the port unpredictable, but wouldn't that imply using a port number selected
randomly from the entire space of available ports within the 16 bit space? A
single server can't keep reusing the same one or few port numbers because then
an attacker can spend a little time looking at which ones are being used and it
would be predictable. So I would think that maybe we get what we need from the
security fix. I haven't had time to test this out, but when we were working on
this, before the big DNS security fix, I found that when the OS chose the port
it wold just start with the first number in the available range, then increment
the port number with each new port, and do that with each process. It woud be
interesting to see what the pattern looks like now.
I don't see how we can make a timeout work. here is what happens: A query is
sent out on port A with 16-bit ID B. No response is received within the
lifetime of the listener and the listener times out. Possibly another process
sends out a query that also is on port A with ID B. Then the reply from the
first query finally arrives from the remote nameserver, arriving on port A with
ID B, and that reply is incorrectly processed by the listener that is waiting
for the reply to the second query.
Where can we or the sysadmin put a timeout that would help in that scenario?
The purpose of randomising the port is so that the probability of the almost
32-bit combination of port and ID colliding is too low to worry about. If too
few port numbers are used the probability of collision on just the 16 bit ID is
too high for the number of DNS queries that are generated in a high volume
situation.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Justin Mason <jm...@jmason.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|security@spamassassin.apach |dev@spamassassin.apache.org
|e.org |
--- Comment #7 from Justin Mason <jm...@jmason.org> 2010-01-27 03:16:01 UTC ---
reassigning, too
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #14 from Simon Arlott <sp...@arlott.org> 2010-01-27 13:12:00 UTC ---
(In reply to comment #13)
> As we discuss this, I'm remembering more from when I worked on bug 4620.
> SpamAssassin selects a port number at random and then increments from there.
> That is to keep two processes from working in the same range of ports.
That doesn't make sense... it should keep whichever port it finds until it's
done with all its queries. There's then much less chance of reusing a port from
another process. Each process can guarantee uniqueness by not reusing IDs. As
far as I could tell the last time I checked, it kept the same port throughout
the process lifetime.
> If, as you say for Linux, the counter that iterates through port numbers is
> system wide and not per process, then this would not be necessary and I think
> your patch would work and would be better.
>
> I don't think that we can count on that behavior. I certainly didn't see it in
> the tests I ran for bug 4260. When I did that I was testing under Cygwin on
> Windows and Fedora Core 3. It would be good to have a simple test that shows
> how the port selection goes with repeated UDP port 0 socket creation across
> different processes, and test that on different platforms.
It looks like a recent Linux kernel now picks ports at random. Older kernels
definitely iterated through them. The OS is also best placed to avoid reusing
ports too soon.
> Your idea of making it a configuration option may be the way to go if it is
> possible to easily test what a particular system's behavior is, even if it is a
> test that a sysadmin has to run manually to help decide how to set the
> configuration option.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #23 from Mark Martinec <Ma...@ijs.si> 2011-09-24 01:14:04 UTC ---
closing, fixed for 3.4.0
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |3.3.0
--- Comment #1 from Mark Martinec <Ma...@ijs.si> 2009-10-15 10:18:26 UTC ---
> Created an attachment (id=4551)
--> (https://issues.apache.org/SpamAssassin/attachment.cgi?id=4551) [details]
> Patch to always use port 0 instead of trying ports at random
>
> DnsResolver.pm attempts to bind UDP ports at random. This causes numerous
> errors if listening on specific ports is restricted to specific
> applications/users.
>
> The correct way to acquire a UDP socket to listen for responses is to bind to
> port 0 instead. The OS will automatically allocate an appropriate free port
> from the range defined for local allocation (net.ipv4.ip_local_port_range on
> Linux).
While I agree in general, I think there was some underlying reason for the
current hack, but I can't find a reference now. Possibly something to do
with mismatching DNS replies with queries. Moving to 3.3.0 target.
Related to Bug 5264.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6221] DnsResolver.pm attempts to bind ports at random
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
Mark Martinec <Ma...@ijs.si> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.3.2 |3.4.0
--- Comment #20 from Mark Martinec <Ma...@ijs.si> 2010-03-29 17:43:15 UTC ---
trunk:
Bug 5264: Specification of DNS-query source port range;
Bug 6221: DnsResolver.pm attempts to bind ports at random;
Implements config directives dns_local_ports_permit,
dns_local_ports_avoid and dns_local_ports_none, allowing
admin control over the set of local port numbers used
in sending DNS queries to a resolving DNS server, or
letting the operating system choose a free port number.
Also avoids a sequential ports scanning when one is
unlucky that a random start point falls in a range
of consecutive busy ports.
The 10_default_prefs.cf now brings a set of
dns_local_ports_avoid directives to exclude IANA
assigned high port numbers and some other ranges.
Sending lib/Mail/SpamAssassin/Conf.pm
Sending lib/Mail/SpamAssassin/DnsResolver.pm
Sending rules/10_default_prefs.cf
Transmitting file data ...
Committed revision 928844.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.