- The "change header" milter request could replace the wrong header. A long
header name could match a shorter one, because a length check was done on
the wrong string. Reported by Vladimir Vassiliev.
- Core dump when postlog emitted the "usage" message, caused by an extraneous
null assignment. Reported by Kant (fnord.hammer).
- These releases add support to turn off the TLSv1.1 and TLSv1.2 protocols.
Introduced with OpenSSL version 1.0.1, these protocols are known to cause
inter-operability problems, for example with some hotmail services.
The radical workaround is to temporarily turn off problematic protocols
globally:
/etc/postfix/main.cf:
smtp_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
smtpd_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
However, it may be better to temporarily turn off problematic protocols for
broken sites only:
/etc/postfix/main.cf:
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
/etc/postfix/tls_policy:
example.com may protocols=!SSLv2:!TLSv1.1:!TLSv1.2
Notes:
Note the use of ":" instead of comma or space. Also, note that there is NO
space around the "=" in "protocols=".
The smtp_tls_policy_maps lookup key must match the "next-hop" destination
that is given to the Postfix SMTP client. If you override the next-hop
destination with transport_maps, relayhost, sender_dependent_relayhost_maps,
or otherwise, you need to specify the same destination for the
smtp_tls_policy_maps lookup key.
- OpenSSL related (all supported Postfix versions).
Some people have reported program crashes when the OpenSSL library was
updated while Postfix was accessing the Postfix TLS session cache. To avoid
this, the Postfix TLS session cache ID now includes the OpenSSL library
version number. This cache ID is not shared via the network.
- The OpenSSL workaround introduced with the previous stable and legacy
releases did not compile with older gcc compilers. These compilers can't
handle #ifdef inside a macro invocation (NOT: definition).
- To avoid repeated warnings from postscreen(8) with "connect to
private/dnsblog service: Connection refused" on FreeBSD, the dnsblog(8)
daemon now uses the single_server program driver instead of the multi_server
driver. This one-line code change has no performance impact for other
systems, and eliminates a high-frequency accept() race on a shared socket
that appears to cause trouble on FreeBSD. The same single_server program
driver has proven itself for many years in smtpd(8). Problem reported by
Sahil Tandon.
- Laptop-friendly support (all supported Postfix versions). A little-known
secret is that Postfix has always had support to avoid unnecessary disk
spin-up for MTIME updates, by doing s/fifo/unix/ in master.cf (this is
currently not supported on Solaris systems). However, two minor fixes are
needed to make this bullet-proof.
- In laptop-friendly mode, the "postqueue -f" and "sendmail -q" commands did
not wait until their requests had reached the pickup and qmgr servers before
closing their UNIX-domain request sockets.
- In laptop-friendly mode, the unused postkick command waited for more than
a minute because the event_drain() function was comparing bitmasks
incorrectly on systems with kqueue(2), epoll(2) or /dev/poll support.
Fix locking of file handle. More cleanup on error paths.
Keep track of CCBs, so they cannot be used after a session ends.
Handle CCB timeouts even when the connection is terminated.
Compute firstdata, firstimmed correctly.
is a global sysctl kern.maxlwp to control this, which is by default 2048.
The first lwp of each process or kernel threads are not counted against the
limit. To show the current resource usage per user, I added a new sysctl
that dumps the uidinfo structure fields.
things may happen in a parallel build - especially with rules like the
automatic size adjustment for SYMTAB_SPACE, see long standing failure of
evbarm on the build cluster.
Easy fix: .WAIT for each config to complete, before going on with the
next. Low impact, only minor loss of paralellism, and only in cases where
needed.
limits (often way too high) and skipping the test case if in doubt,
raise the limits as far as we can, and fix a few places in the test where
we could run into the limits and either skip or fail with a reasonable
message.
- cpu_load_pmap: use atomic kcpuset(9) operations; fixes rare crashes.
- Add kcpuset_copybits(9) and replace xen_kcpuset2bits(). Avoids incorrect
ncpu problem in early boot. Also, micro-optimises xen_mcast_invlpg() and
xen_mcast_tlbflush() routines.
Tested by chs@.
caches, merge together pool_drain_start() and pool_drain_end() into
bool pool_drain(struct pool **ppp);
"bool" value indicates whether reclaiming was fully done (true) or not (false)
"ppp" will contain a pointer to the pool that was drained (optional).
See http://mail-index.netbsd.org/tech-kern/2012/06/04/msg013287.html
context, re-enable the portion of code that allows invalidation of CPU-bound
pool caches.
Two reasons:
- CPU cached objects being invalidated, the probability of fetching an
obsolete object from the pool_cache(9) is greatly reduced. This speeds up
pool_cache_get() quite a bit as it does not have to keep destroying objects
until it finds an updated one when an invalidation is in progress.
- for situations where we have to ensure that no obsolete object remains
after a state transition (canonical example: pmap mappings between Xen VM
restoration), invalidating all pool_cache(9) is the safest way to go.
As it uses xcall(9) to broadcast the execution of pool_cache_transfer(),
pool_cache_invalidate() cannot be called from interrupt or softint context
(scheduling a xcall(9) can put a LWP to sleep).
pool_cache_xcall() => pool_cache_transfer() to reflect its use.
Invalidation being a costly process (1000s objects may be destroyed),
all places where pool_cache_invalidate() may be called from
interrupt/softint context will now get caught by the proper KASSERT(), and
fixed. Ping me when you see one.
Tested under i386 and amd64 by running ATF suite within 64MiB HVM
domains (tried triggering pgdaemon a few times).
No objection on tech-kern@.
XXX a similar fix has to be pulled up to NetBSD-6, but with a more
conservative approach.
See http://mail-index.netbsd.org/tech-kern/2012/05/29/msg013245.html
