Postfix docs Search Results:

Looking for security in entire archive - Found 453 matches in 30 files
Showing results 1 - 25
Postfix Configuration Parameters, Feb 8 2008
The local(8) delivery agent disallows regular expression substitution of $1 etc. in alias_maps, because that would open a security hole.
lmtp_sasl_security_options
SASL security options; as of Postfix 2.3 the list of available features depends on the SASL client implementation that is selected with lmtp_sasl_type.
The following security features are defined for the cyrus
lmtp_sasl_security_options = noplaintext
lmtp_sasl_tls_security_options
(default: $lmtp_sasl_security_options)
The LMTP-specific version of the smtp_sasl_tls_security_options
lmtp_sasl_tls_verified_security_options
(default: $lmtp_sasl_tls_security_options)
The LMTP-specific version of the smtp_sasl_tls_verified_security_options configuration parameter.
lmtp_tls_security_level
The LMTP-specific version of the smtp_tls_security_level configuration parameter. See there for details.
This feature is available in Postfix 2.2 and later. With Postfix 2.3 and later use smtp_tls_security_level instead.
smtp_sasl_security_options
Postfix SMTP client SASL security options; as of Postfix 2.3 the list of available features depends on the SASL client implementation that is selected with smtp_sasl_type.
The following security features are defined for the cyrus
smtp_sasl_security_options = noplaintext
smtp_sasl_tls_security_options
(default: $smtp_sasl_security_options)
...limit of 20 lines reached, additional matching lines are not shown...

Postfix Configuration Parameters, Feb 8 2008
The local(8) delivery agent disallows regular expression substitution of $1 etc. in alias_maps, because that would open a security hole.
lmtp_sasl_security_options
SASL security options; as of Postfix 2.3 the list of available features depends on the SASL client implementation that is selected with lmtp_sasl_type.
The following security features are defined for the cyrus
lmtp_sasl_security_options = noplaintext
lmtp_sasl_tls_security_options
(default: $lmtp_sasl_security_options)
The LMTP-specific version of the smtp_sasl_tls_security_options
lmtp_sasl_tls_verified_security_options
(default: $lmtp_sasl_tls_security_options)
The LMTP-specific version of the smtp_sasl_tls_verified_security_options configuration parameter.
lmtp_tls_security_level
The LMTP-specific version of the smtp_tls_security_level configuration parameter. See there for details.
This feature is available in Postfix 2.2 and later. With Postfix 2.3 and later use smtp_tls_security_level instead.
smtp_sasl_security_options
Postfix SMTP client SASL security options; as of Postfix 2.3 the list of available features depends on the SASL client implementation that is selected with smtp_sasl_type.
The following security features are defined for the cyrus
smtp_sasl_security_options = noplaintext
smtp_sasl_tls_security_options
(default: $smtp_sasl_security_options)
...limit of 20 lines reached, additional matching lines are not shown...

Postfix Configuration Parameters, Feb 8 2008
The local(8) delivery agent disallows regular expression substitution of $1 etc. in alias_maps, because that would open a security hole.
lmtp_sasl_security_options
SASL security options; as of Postfix 2.3 the list of available features depends on the SASL client implementation that is selected with lmtp_sasl_type.
The following security features are defined for the cyrus
lmtp_sasl_security_options = noplaintext
lmtp_sasl_tls_security_options
(default: $lmtp_sasl_security_options)
The LMTP-specific version of the smtp_sasl_tls_security_options
lmtp_sasl_tls_verified_security_options
(default: $lmtp_sasl_tls_security_options)
The LMTP-specific version of the smtp_sasl_tls_verified_security_options configuration parameter.
lmtp_tls_security_level
The LMTP-specific version of the smtp_tls_security_level configuration parameter. See there for details.
This feature is available in Postfix 2.2 and later. With Postfix 2.3 and later use smtp_tls_security_level instead.
smtp_sasl_security_options
Postfix SMTP client SASL security options; as of Postfix 2.3 the list of available features depends on the SASL client implementation that is selected with smtp_sasl_type.
The following security features are defined for the cyrus
smtp_sasl_security_options = noplaintext
smtp_sasl_tls_security_options
(default: $smtp_sasl_security_options)
...limit of 20 lines reached, additional matching lines are not shown...

Postfix TLS Support, Feb 8 2008
Transport Layer Security (TLS, formerly called SSL) provides certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with SMTP mail or with SASL authentication.
By default, TLS is disabled in the Postfix SMTP server, so no difference to plain Postfix is visible. Explicitly switch it on with "smtpd_tls_security_level = may" (Postfix 2.3 and later) or "smtpd_use_tls = yes" (obsolete but still supported).
/etc/postfix/main.cf: # Postfix 2.3 and later smtpd_tls_security_level = may # Obsolete, but still supported smtpd_use_tls = yes
You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt" (Postfix 2.3 and later) or "smtpd_enforce_tls = yes" (obsolete but still supported). According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used.
/etc/postfix/main.cf: # Postfix 2.3 and later smtpd_tls_security_level = encrypt # Obsolete, but still supported smtpd_enforce_tls = yes
/etc/postfix/main.cf: smtpd_tls_ask_ccert = yes # Postfix 2.3 and later smtpd_tls_security_level = may # Obsolete, but still supported smtpd_use_tls = yes
/etc/postfix/main.cf: smtpd_tls_req_ccert = yes # Postfix 2.3 and later smtpd_tls_security_level = encrypt # Obsolete, but still supported smtpd_enforce_tls = yes
Sending AUTH data over an unencrypted channel poses a security risk. When TLS layer encryption is required ("smtpd_tls_security_level = encrypt" or the obsolete "smtpd_enforce_tls = yes"), the Postfix SMTP server will announce and accept AUTH only after the TLS layer has been activated with STARTTLS. When TLS layer encryption is optional ("smtpd_tls_security_level = may" or the obsolete "smtpd_enforce_tls = no"), it may however still be useful to only offer AUTH when TLS is active. To maintain compatibility with non-TLS clients, the default is to accept AUTH without encryption.
The Postfix SMTP server supports 5 distinct cipher security levels as specified by the smtpd_tls_mandatory_ciphers configuration parameter, which determines the cipher grade with mandatory TLS encryption. The default value is "medium" which is essentially 128-bit encryption or better.
/etc/postfix/main.cf: smtpd_tls_cert_file = /etc/postfix/cert.pem smtpd_tls_key_file = /etc/postfix/key.pem smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 smtpd_tls_security_level = encrypt smtpd_tls_mandatory_protocols = TLSv1 # Also available with Postfix ≥ 2.5: smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
Client TLS security levels
The security properties of TLS communication channels are application specific. While the TLS protocol can provide a confidential, tamper-resistant, mutually authenticated channel between client and server, not all of these security features are applicable to every communication.
For example, while mutual TLS authentication between browsers and web servers is possible, it is not practical, or even useful, for web-servers that serve the public to verify the identity of every potential user. In practice, most HTTPS transactions are asymmetric: the browser verifies the HTTPS server's identity, but the user remains anonymous. Much of the security policy is up to the client. If the client chooses to not verify the server's name, the server is not aware of this. There are many interesting browser security topics, but we shall not dwell on them here. Rather, our goal is to understand the security features of TLS in conjunction with SMTP.
One may be tempted to try enforcing TLS for mail from specific sending organizations, but this, too, runs into obstacles. One such obstacle is that we don't know who is (allegedly) sending mail until we see the "MAIL FROM:" SMTP command, and at that point, if TLS is not already in use, a potentially sensitive sender address (and with SMTP PIPELINING one or more of the recipients) has (have) already been leaked in the clear. Another obstacle is that mail from the sender to the recipient may be forwarded, and the forwarding organization may not have any security arrangements with the final destination. Bounces also need to be protected. These can only be identified by the IP address and HELO name of the connecting client, and it is difficult to keep track of all the potential IP addresses or HELO names of the outbound email servers of the sending organization.
Consequently, TLS security for mail delivery to public MX hosts is almost entirely the client's responsibility. The server is largely a passive enabler of TLS security, the rest is up to the client. While the server has a greater opportunity to mandate client security policy when it is a dedicated MSA that only handles outbound mail from trusted clients, below we focus on the client security policy.
(fully authenticated and immune to man-in-the-middle attacks) impose constraints on the sending and receiving sites that preclude ubiquitous deployment. One needs to manually configure this type of security for each destination domain, and in many cases implement non-default TLS policy table entries for additional domains hosted at a common secured destination. With Postfix 2.3, we make secure-channel configurations substantially easier to configure, but they will never be the norm. For the generic domain with which you have made no specific security arrangements, this security level is not a good fit.
Client TLS security levels
The TLS security levels listed below are described in more detail in the sections that follow.
At the "none" TLS security level, TLS encryption is disabled. This is the default security level. With Postfix 2.3 and later, it can be configured explicitly by setting "smtp_tls_security_level = none".
With Postfix 2.2 and earlier, or when smtp_tls_security_level is set to its default (backwards compatible) empty value, the appropriate configuration settings are "smtp_use_tls = no" and "smtp_enforce_tls = no".
...limit of 20 lines reached, additional matching lines are not shown...

Postfix and Mailman deliver enhanced e-mail security and performance, Feb 8 2008
Postfix and Mailman deliver enhanced e-mail security and performance
Solaris Security
Secure Programming
Postfix and Mailman deliver enhanced e-mail security and performance
Sendmail isn't perfect, though. It's bulky, difficult, and has a history of security problems. More precisely, it's in just the shape you'd expect of a product originally built for a much different computing environment, and it's been patched and rewritten during several computing generations. Still, the Sendmail development team has achieved quite a feat in bringing it forward from the far more relaxed security traditions of two decades ago.
Wietse Venema has an alternative, though. Venema, a security expert on the IBM Research staff, started fresh, and has produced Postfix, a drop-in replacement for Sendmail which promises to deliver e-mail more quickly, conveniently, and safely.
Venema has a track record in secure computing. He says his "claim to fame is largely based on the low incidence of error" in the systems he's written, including Security Administrator Tool for Analyzing Networks (SATAN) and TCP Wrapper. In designing and implementing Postfix (which began life as VMailer and Secure Mailer; don't be confused by the name changes), Venema's goal was for it "to be fast, easy to administer, and hopefully secure, while at the same time being Sendmail-compatible enough to not upset your users."
Sendmail is a famous monolith: it's one big program that does everything. Postfix is more Unix-like in that it consists of a number of little programs, each of which is easy to understand and validate, including postlock, postalias, postlog, postmap, and others. This is part of the answer to Sendmail's notorious vulnerability. Because Sendmail does so much, it effectively needs superuser privileges and is correspondingly easy to subvert. Each of Postfix's parts has a limited role, so even if it's faulty and behaves in an unplanned way, it's unlikely to have enough security permissions to do any serious damage.
Postfix seems to be less scary to manage than Sendmail. Customizing or even configuring Sendmail always feels like a big deal; on the other hand, Postfix is quite a bit easier to experiment with because you can test just one thing at a time. Venema, for example, recently added a "debugging" feature suggested by Bennett Todd, a Unix systems and security analyst working on Wall Street: a "soft_bounce" selection to ensure that, even in the case of misconfiguration, messages are not erroneously returned to their senders.
If you're using Sendmail, though, you have a professional responsibility to update it to a current release. The security hazards of running an older version (some major Unix vendors still ship Sendmail 5.65!) are simply unacceptable.
Anyone considering Postfix should also know about qmail -- a more mature open source project that occupies almost exactly the same niche as Postfix. Its security and performance are very good, and it's had a couple more years to ripen than Postfix. It has about the same set of features as Postfix, plus a clever built-in "aliasing" scheme that simplifies mailing list management.
Also, note that the qmail license is an unusual one. While Bernstein has liberalized it again recently, it generally has been more restrictive than the licenses for many other open source products in that it restricts developers from modifying the core of qmail or distributing binary images. This has been a predictably contentious topic throughout qmail's history. On one side, Bernstein doesn't want people to degrade qmail's security, even if inadvertently, and give his product a bad name. But then proponents of license liberalization argue that the license is a practical inconvenience that decreases the usefulness of qmail.
You're probably running Sendmail now, and all you need to do is pick up the latest release for its tighter security and antispamming features. But do tens of thousands of people look to you when they have e-mail problems? Is your domain a prominent one that might attract crackers? Has your uptime been floating higher? In such cases, it's time you at least begin to experiment with Postfix (or qmail, or one of the higher-end commercial products), which will give you superior performance and security to Sendmail with all the reliability that the latter has gained during two decades of refinement.
According to Warsaw, Mailman is coded in approximately 13,000 lines of Python code, along with 600 lines of C which wrap security facilities. Mailman exposes Python as an extension language that allows for customization of Mailman's interfaces.
The software you're already using to handle your e-mail requirements probably works reliably. However, the scale of your operations is likely growing, while security threats become more difficult, and your users' demands for convenience expand. It might be time for you to move to a new technology -- one better suited to modern needs. Several of the best e-mail products are open source. In particular, you can easily install Postfix and Mailman, and test their performance in realistic settings. Postfix and Mailman already have healthy user communities. You can have confidence that Postfix and Mailman will be fresh and well-supported for years to come.
Also this month in SunWorld Features: - How to manage and implement change in your Unix environment - Fibre Channel vs. SCSI: Which is more advantageous for your Storage Area Network? - Postfix and Mailman deliver enhanced e-mail security and performance
ftp://ftp.porcupine.org/pub/security/index.html
"Report from SANS '98: Why Wietse Venema says Sendmail can never be made secure" July 1998 Security column in SunWorld
http://www.sunworld.com/swol-07-1998/swol-07-security.html

Postfix manual - smtp(8), Feb 8 2008
SECURITY
The SMTP+LMTP client is moderately security-sensitive. It talks to SMTP or LMTP servers and to DNS servers on the network. The SMTP+LMTP client can be run chrooted at fixed low privilege.
smtp_sasl_security_options (noplaintext, noanonymous)
Postfix SMTP client SASL security options; as of Postfix 2.3 the list of available features depends on the SASL client implementation that is selected with smtp_sasl_type.
smtp_tls_security_level (empty)
The default SMTP TLS security level for the Postfix SMTP client; when a non-empty value is specified, this overrides the obsolete parameters smtp_use_tls, smtp_enforce_tls, and smtp_tls_enforce_peername.
smtp_sasl_tls_security_options ($smtp_sasl_secu-
rity_options)
The SASL authentication security options that the Postfix SMTP client uses for TLS encrypted SMTP sessions.
List of ciphers or cipher types to exclude from the Postfix SMTP client cipher list at all TLS security levels.
Additional list of ciphers or cipher types to exclude from the SMTP client cipher list at manda- tory TLS security levels.
Optional lookup tables with the Postfix SMTP client TLS security policy by next-hop destination; when a non-empty value is specified, this overrides the obsolete smtp_tls_per_site parameter.
The server certificate peername verification method for the "secure" TLS security level.
The server certificate peername verification method for the "verify" TLS security level.
smtp_sasl_tls_verified_security_options
($smtp_sasl_tls_security_options)
The SASL authentication security options that the Postfix SMTP client uses for TLS encrypted SMTP sessions with a verified server certificate.
List of acceptable remote SMTP server certificate fingerprints for the "fingerprint" TLS security level (smtp_tls_security_level = fingerprint).

SecurityPortal - Kurt's Closet: Postfix - the Sendmail replacement, Feb 8 2008
Security 101
September 15, 1999 – Most, if not all the readers of this column run a mail server, and more then likely it is running Sendmail. In all fairness Sendmail is a damn good MTA (Mail Transfer Agent), Eric Allman originally wrote it with one main goal in mind: the mail must get through. Unfortunately, when Sendmail was originally written security wasn't a major concern on the Internet and it shows. Sendmail runs almost exclusively as the root user on most systems, meaning any flaws are potentially very serious. In addition to this Sendmail isn't very good at handling high loads. New mailers, such as Postfix, Zmailer, and Qmail are several times faster then Sendmail on the same hardware. Until recently most of the alternative mailers to Sendmail were not drop-in replacements, to replace Sendmail was a painful task, and the new software typically behaved differently then Sendmail. Postfix was designed from the start to address all these problems.
Security
Kurt Seifried is a security analyst and the author of the "Linux Administrators Security Guide", a source of natural fiber and Linux security, part of a complete breakfast.
IWON: NetWolves Says GE To Use Its Internet Security System
Boston Internet: RSA Security Opens Ireland Plant

Sys Admin Magazine Online, Feb 8 2008
Wietse Venema, probably best known as the developer of SATAN and the TCP Wrapper security tools, has now created Secure Mailer. In December of 1998, IBM released Secure Mailer as open source software providing a new, freely available alternative to the nearly universal Sendmail program. The program, more commonly known in open-source circles as Postfix, attempts to be fast, easy to administer, and secure. One of the primary goals of Postfix is to be widely implemented in order to make the most significant impact on the performance and security of Internet email overall.
Sendmail by some estimates handles nearly three-quarters of all email on the Internet, but it has had a bit of a checkered past with a history of security problems. A scan through the CERT Advisories quickly turned up more than a dozen Sendmail incidents.
In addition to tighter security, Postfix offers several advantages over Sendmail while maintaining a high level of compatibility with it. The Postfix Web site claims that it is up to three times faster than its nearest competitor. (There are several other Sendmail alternatives, such as qmail and various commercial packages.) It is designed to be robust and behave well under stress. For example, runaway conditions that might occur during error handling are diminished because the software pauses before sending error messages or terminating with a fatal error. It operates under a "no thundering herd" policy when delivering mail to other hosts. Initially, Postfix will make only two simultaneous connections. If the deliveries succeed, Postfix will slowly increase connections up to a configurable limit. It will also detect whether the receiving host can no longer handle the load and decrease the number of connections.
Overall, Postfix is written to be a highly secure network application. It employs multiple layers of defense. All of its processes run at a fixed low privilege, and most can be run within a chrooted environment. Sendmail is the classic monolithic program, and it runs with root privilege. These two facts are largely the reason for the severity of Sendmail's security problems. If a vulnerability is discovered, the possibility that it will allow root access is high.
It is quite possible that Postfix has security bugs, but because of its design, whatever vulnerabilities might exist will be very limited and possibly not even exploitable over a network. Its modularity provides flexibility and also security. There are various processes that perform specific tasks. There is a separate process to send mail and receive mail and to deliver mail locally.
Some additional security aspects are that Postfix programs do not run under a user process, thereby eliminating exploits that involve signals, open files, the environment, and other process attributes that might be passed from a parent to a child. Postfix relies on the security notion of trust or lack of it. Postfix processes do not even trust each other. Contents of queue files or IPC messages might have been tampered with; therefore, each process tries to use only its own information in taking security-sensitive actions.
Some other security lessons learned from Sendmail (among others) and incorporated into Postfix are that there are no setuid programs, no /tmp race conditions, no remote data in shell variables or shell commands, and no fixed-length string buffers.
In addition to configuration changes, you have the option of running most of the Postfix processes within a chrooted environment. This is an excellent security measure that will add another layer of protection from someone trying to penetrate your system. The steps for creating a chroot are a bit tricky, and they vary from platform to platform. Also, the chroot
examples/chroot-setup directory, but these are a bit skimpy and probably do not provide all the information you will need. You will have to investigate the documentation for your system and experiment. From a security point of view, this is well worth the effort.
There is another security decision you will have to make regarding Postfix's submission mechanism, that is, the attributes on directories used for mail spooling. Postfix offers two options. The first uses a world-writable, sticky (1733) directory for messages. Because it is world-writable there is no need to run any program with special privileges (setuid or setgid), and the mail files themselves are not world-writable or otherwise accessible to other users.
There is a possibility that a local user could do some small damage. For example, it would be possible to create a hard link to a mail file so that it is not removed when Postfix deletes it. Or, a local user could copy or hard link some system file to the directory to try to have it delivered as mail. Postfix does take steps to prevent this (remember, trust no one), so the likelihood that this would work is significantly diminished. However, if you have a lot of local users on the mail system, and your own security policies would not permit world-write permissions, Postfix offers an alternative. You can set the directory permissions more restrictively (1730) and install an additional program, called postdrop, provided to run setgid. You will have to create a special group that has no members and set the mail spool directory's group to the unique group you created. Postfix will automatically run postdrop when it detects that the spool directory write permission is restricted.
Kyle Dent is the founder and owner of SeaGlass Technologies, Inc. a company specializing in secure Web hosting/development and Internet/security consulting. He can be reached at: kdent@seaglass.com.

SecurityPortal - Postfix - The Sendmail replacement part II, Feb 8 2008
Security 101
Subscribe to get FREE security news, commentary, and articles.
Transport Layer Security is to email as SSL is to Web browsing. TLS allows you to encrypt email transfers from server to server, but more importantly, it allows you to add authentication to the mail server. Instead of having to allow access based on IP and hostname, you can use usernames and passwords. That way people can connect securely from off-site - while using dialup on the road - and spammers are not able to use you as a relay.
Postfix is ideal for large installations, with its database backends and extremely tight control of mail delivery. Additionally, it supports numerous security features, such as TLS and even the ability to specify which users are allowed to send mail off-site and which aren't - again, in a very selective manner. Qmail has quite a few of these features, but has one significant problem: The license makes it extremely difficult to distribute in a binary format, which is what most people want.
IWON: NetWolves Says GE To Use Its Internet Security System
Boston Internet: RSA Security Opens Ireland Plant

Catching up with Wietse Venema, creator of Postfix and TCP Wrapper, Feb 8 2008
Internet Extortion Ring Smashed
Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit
Wietse Venema is best known for the software TCP Wrapper, which is still widely used today and is included with almost all unix systems. Wietse is also the author of the Postfix mail system and the co-author of the very cool suite of utilities called The Coroner's Toolkit
Linuxsecurity.com: You have a suite of tools available on your website. Any new ones coming out that address basic fundamental security practices that still aren't followed or are you going to add any new functionality to your existing programs?
Writing a new mail system from scratch was a change from previous projects. Normally I would retrofit security features almost invisibly, either by replacing an existing server such as portmap by a hardened version that was 100% compatible, or by adding a very thin layer such as tcp_wrappers. In the case of the Postfix mail system, there was no way that the changes could be made in an invisible manner.
Linuxsecurity.com: In one article, I wrote about how attackers are still breaking into computer systems using well-known exploits. Any ideas on how to help instill basic security practices in administrators and vendors?
Wietse: I think that learning by example is a good way to bring the point across. This is what Dan Farmer and I attempted years ago with our white paper on improving the security of your system by breaking into it.
I have the same experience when explaining how to build more secure software. People just don't see that there is a problem until you can show good examples of software that does not do the things that it obviously was meant to do. Security problems happen when there is a mismatch between expected behavior and actual behavior.
"As long as there is support for ad hoc fixes and security packages for these inadequate designs and as long as the illusory results of penetration teams are accepted as demonstrations of computer system security, proper security will not be a reality."
Roger Schell et al., Preliminary notes on the Design of Secure Military Computer Systems, 1973. Archive of seminal security papers at http://seclab.cs.ucdavis.edu/projects/history/seminal.html
Wietse: The caricature was drawn, by an artist whose name I do not know, at a conference dinner in 1997 when the Forum of Incident Response and Security Teams (www.first.org) met for its annual conference in Bristol, UK. I have supported this organization for many years, and I even had the privilege of spending more than the maximal time as its chair.
Duane Dunston is an Information Technology Specialist (Security) for the National Climatic Data Center. He was previously a contractor for STG Inc. for the same organization. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS. Hey, Ann Curry!

sendmail.net:, Feb 8 2008
When you name a program SATAN, you can expect your intentions to be misread. Wietse Venema discovered this firsthand when he and colleague Dan Farmer released the Security Administrator Tool for Analyzing Networks, reporting software designed to let administrators test their own networks for vulnerabilities, but immediately misconstrued as a toy for budding crackers.
There's little chance that mistake will be repeated. Venema's name has become synonymous with security in the minds of sysadmins worldwide, thanks to his work on SATAN,
TCP Wrappers, and a host of other tools to keep the scriptkiddies at bay. This work hasn't gone unnoticed: at the LISA '99 conference last November, Venema received the SAGE Outstanding Achievement Award, an honor previously bestowed upon the likes of Paul Vixie and Larry Wall.
The other thing Venema's famous for, of course, is Postfix, the mail transfer agent he wrote after coming to IBM's Thomas J. Watson Research Center from the Netherlands. Known briefly by the name "VMailer," Postfix aims to be "fast, easy to configure, and hopefully secure." We spoke with Venema by phone about Postfix, security, and the superiority of asynchronous communication - i.e., email.
Let's start with a question about Postfix. What are your plans for incorporating encryption? I'm thinking specifically of Transport Layer Security (TLS) and SMTP authentication.
Slowly. It's a problem, because by now lots of vendors are shipping systems with IP version 6 support. Postfix has taken a lot of my attention, and of course there are other things too, like the forensics tools I've been working on with Dan Farmer. We gave a free, full-day class on computer forensics last August and promised about six tools. The tools were given to the attendees as a beta release, but we really want to finish a first public release. I was actually hoping we would do it in April.
So there's an ease-of-administration tradeoff for the security that you get. The encryption has an administrative cost.
Yes, the encryption makes it impossible to do certain operations. Now, from the point of view of security, this is exactly what you want. All you want is to send your data to the other machine, and it should be sent unchanged: no man-in-the-middle attacks by "helpful" intermediate systems. So these are conflicting requirements.
The same thing happens with everybody who implements a system from the ground up. Just as Eric Allman had to solve problems as he was building sendmail over time, I ran into several problem instances myself and tried to solve them. And then I looked at how sendmail solved it, or how other systems solved it. Sometimes you find your solution is better, and sometimes you find your solution is worse. Sometimes you find a security problem in the other person's solution. All these things happen. But the end result, of course, is that people will have better software.
As you look forward at the future of email and Internet communication generally, aside from the obvious things - many more users and much greater security issues - what do you see as the forces shaping the evolution of these technologies? What direction do you see email going in, beyond simple one-to-one messaging?

Sharing Software, IBM to Release Mail Program Blueprint, Feb 8 2008
dding momentum to the open-source movement for the free sharing of software, IBM plans Monday to make available the original programmer's instructions for a new mail program that can be used to store and forward e-mail messages with a high level of security.
The program, Secure Mailer, serves as an electronic post office for server computers connected to the Internet. It was developed by Wietse Venema, an IBM researcher and computer security specialist.
"This is IBM's Christmas present to the Internet," said Abner Germanow, a computer security analyst at the International Data Corp., a market research firm. "For these are core pieces of software, and we're going beyond trying to make money off of them, to the idea that by freely sharing them it will make the world a better place."
IBM researchers said one of the drawbacks to Sendmail was that it had been written as a large, monolithic piece of software. As a result it has both performance and security limitations.
Charles Palmer, who manages a computer security research group at IBM's T.J. Watson Research Laboratory, said that enabling other programmers to look at all the original instructions written by the program's author would give them a high degree of confidence in the security of a program.

Postfix manual - qmqpd(8), Feb 8 2008
SECURITY
The QMQP server is moderately security-sensitive. It talks to QMQP clients and to DNS servers on the network. The QMQP server can be run chrooted at fixed low privilege.

Venema aims to make network software safe, Feb 8 2008
Venema's a good man for the job. He's worked for over a decade on a broad range of "software whose existence you don't notice because it works well": network security, inter-company financial transactions, terminal emulation, and so on. "My software rarely fails ... My claim to fame is largely based on the low incidence of error" in the infrastructural applications he's written. Now he's moved permanently to the "beautiful landscape" of central New York state from his native Netherlands to dedicate a year to VMailer.
Before VMailer, Venema was probably best known for his work with the Security Administrator Tool for Analyzing Networks (SATAN). SATAN probes machines connected to the Net and reports on problems or weaknesses it finds. This is a great convenience for system administrators responsible for securing these machines; it gives them a nicely formatted, thorough explanation of the deficiencies they need to address. As with all the tools Venema writes, "I have given away the programs ...
tcp wrappers BLURB

Postfix Basic Configuration, Feb 8 2008
If your machine has unusual security requirements you may want to run Postfix daemon processes inside a chroot environment.
Sites with high security requirements should consider to chroot all daemons that talk to the network: the smtp(8) and smtpd(8)

Guidelines for Package Builders, Feb 8 2008
Begin Security Alert
End Security Alert

Postfix Address Rewriting, Feb 8 2008
An aliases(5) file can specify that mail should be delivered to a local file, or to a command that receives the message in the standard input stream. For security reasons, deliveries to command and file destinations are performed with the rights of the alias database owner. A default userid, default_privs, is used for deliveries to commands or files in "root"-owned aliases.

Postfix Address Rewriting, Feb 8 2008
An aliases(5) file can specify that mail should be delivered to a local file, or to a command that receives the message in the standard input stream. For security reasons, deliveries to command and file destinations are performed with the rights of the alias database owner. A default userid, default_privs, is used for deliveries to commands or files in "root"-owned aliases.

http://www.postfix.org/linuxmag.200006/postfix.html, Feb 8 2008
Anfang April 2000 veröffentlichte Dan Bernstein, der Autor von Qmail, in den Newsgroups comp.mail.misc, comp.mail.sendmail,comp.security.unix eine Untersuchung über die Anteile der verschiedenen Mailer im Netz. Dazu schaute er sich 1/256 aller "second level" .com-Domains an, insgesamt 12595 IP-Adressen, und bekam in 11460 Fällen Kontakt auf dem SMTP-Port. Für die Verhältnisse in Europa mag diese Untersuchung wenig relevant sein, sie gestattet aber trotzdem einen gewissen Einblick.

Postfix Add-on Software, Feb 8 2008
PGP/SMIME gateways |
Z1 SecureMail Gateway Security server for email using S/MIME and PGP.

Postfix Architecture Overview, Feb 8 2008
The tlsmgr(8) server runs when TLS (Transport Layer Security, formerly known as SSL) is turned on in the Postfix smtp(8)

Postfix XFORWARD Howto, Feb 8 2008
Security

Postfix Installation From Source Code, Feb 8 2008
Sites with high security requirements should consider to chroot all daemons that talk to the network: the smtp(8) and smtpd(8)

Postfix XCLIENT Howto, Feb 8 2008
Security

Postfix PCRE Support, Feb 8 2008
Regular expression tables such as pcre: or regexp: are not allowed to do $number substitution in lookup results that can be security sensitive: currently, that restriction applies to the local aliases(5) database or the virtual(8) delivery agent tables.


Limit of 25 files reached.
New Query: Rank by:
Search results by Webglimpse Advanced Site Search Engine