Wietse Venema reported an issue affecting Postfix 2.4+ on Linux systems with 2.6.x kernels.  Issue can be exploited by local user with privilege to run own programs from .forward or .procmailrc to cause denial of service.

Upstream advisory with further details:

Summary:
========
Postfix 2.4 and later, on Linux kernel 2.6, is vulnerable to a
denial of service attack by a local user. There is no breach of
data confidentiality or data integrity. This problem was found by
the Postfix author during routine source code maintenance.

Discussion:
===========
Postfix is an open-source mail transfer agent (MTA) that runs on
multiple types of UNIX systems.  Postfix 2.4 (released 2007)
introduces input/output event handling based on high-performance
primitives: BSD kqueue (also present in MacOS X), Linux epoll, and
Solaris /dev/poll.  These implement more scalable event handling
than the older select() and poll() primitives.

With 2.6 Linux kernels, Postfix 2.4 and later has an epoll file
descriptor leak when it executes non-Postfix commands in, for
example, a user's $HOME/.forward file.  A local user can access a
leaked epoll file descriptor to implement a denial of service attack
on Postfix. The attack may result in reduced Postfix performance,
or in automatic Postfix shutdown when an internal safety mechanism
triggers.  Some possible attacks are discussed in the last paragraph
of this section.

Not affected is Postfix input/output event handling based on BSD
kqueue and Solaris /dev/poll.  There, the kernel effectively revokes
access to the underlying kernel object when it creates a child
process with fork(), keeping the kernel object normally accessible
only by the process that creates it.

The above approaches could help to improve the consistency of Linux
input/output event notification.  Currently, 1) different Linux
processes may make conflicting updates to a shared epoll instance;
2) therefore, the Linux kernel may report input/output events to
processes that didn't ask for those events; and 3) those events may
involve activity on pipes, sockets, etc.  that aren't open in those
processes.  Such inconsistency could be avoided when an epoll
instance were normally accessible only by the process that creates
it.

Workaround:
===========
Allow only trusted users to control delivery to non-Postfix commands.
In the following example, the directory /var/forward is not writable
by users, and Postfix is configured to search for /var/forward/username
(plus optional address extension) instead of the default location
~~username/.forward (plus optional address extension).

/etc/postfix/main.cf:
    forward_path = /var/forward/${user}${recipient_delimiter}${extension},
	/var/forward/${user}

Other workarounds would be required for other mail filtering software
that executes commands in user-controlled configuration files.

Solution:
=========
Apply the source code patch below, or install an updated Postfix
version.  Postfix versions 2.4.9, 2.5.5, and 2.6-20080902 are made
available via http://www.postfix.org/. Vendors will make updated
versions available according to their own support policies.

Patch:
======

Begin of patch
*** src/util/events.c.orig	Mon Mar 24 13:19:23 2008
--- src/util/events.c	Tue Aug 26 17:43:41 2008
***************
*** 426,431 ****
--- 427,433 ----
  
  #define EVENT_REG_INIT_HANDLE(er, n) do { \
  	er = event_epollfd = epoll_create(n); \
+ 	if (event_epollfd >= 0) close_on_exec(event_epollfd, CLOSE_ON_EXEC); \
      } while (0)
  #define EVENT_REG_INIT_TEXT	"epoll_create"
  
End of patch