Postfix docs Search Results:

Looking for new in entire archive - Found 230 matches in 47 files
Showing results 1 - 25
Postfix TLS Support, Feb 8 2008
For servers that are not public Internet MX hosts, Postfix supports configurations with no certificates. This entails the use of just the anonymous TLS ciphers, which are not supported by typical SMTP clients. Since such clients will not, as a rule, fall back to plain text after a TLS handshake failure, a certificate-less Postfix SMTP server will be unable to receive email from most TLS enabled clients. To avoid accidental configurations with no certificates, Postfix enables certificate-less operation only when the administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that new Postfix SMTP server configurations will not accidentally run with no certificates.
If clients instead attempted to verify the recipient domain name, an SMTP server for multiple domains would need to list all its email domain names in its certificate, and generate a new certificate each time a new domain were added. At least some CAs set fairly low limits (20 for one prominent CA) on the number of names that server certificates can contain. This approach is not consistent with current practice and does not scale.
Historical note: while the documentation of these issues and many of the related features are new with Postfix 2.3, the issue was well understood before Postfix 1.0, when Lutz Jänicke was designing the first unofficial Postfix TLS patch. See his original post http://www.imc.org/ietf-apps-tls/mail-archive/msg00304.html
With the Postfix 2.3 and later TLS policy table, specify the "encrypt" security level. With the obsolete per-site table, specify the "MUST_NOPEERMATCH" keyword. While the obsolete approach still works with Postfix 2.3, it is strongly discouraged: users of Postfix 2.3 and later should use the new TLS policy settings.
Note: Avoid policy lookups with the bare hostname (for example, "example.net"). Instead, use the destination (for example, ":587"), as the per-site table lookup key (a recipient domain or MX-enabled transport nexthop with no port suffix may look like a bare hostname, but is still a suitable destination). With Postfix 2.3 and later, do not use the obsolete per-site table; use the new policy table instead.
table, specify the "MUST" keyword. While the obsolete approach still works with Postfix 2.3, it is strongly discouraged: users of Postfix 2.3 and later should use the new TLS policy settings.
With the Postfix 2.3 and later TLS policy table, specify the "secure" security level. With the obsolete per-site table, specify the "MUST" keyword and harden the certificate verification against DNS forgery. While the obsolete approach still works with Postfix 2.3, it is strongly discouraged: users of Postfix 2.3 and later should use the new TLS policy settings.
Note: Avoid policy lookups with the bare hostname (for example, "tls.example.com"). Instead, use the destination (for example, "") as the per-site table lookup key (a recipient domain or MX-enabled transport nexthop with no port suffix may look like a bare hostname, but is still a suitable destination). With Postfix 2.3 and later, do not use the obsolete per-site table; use the new policy table instead.
Postfix 2.3 introduces a new more flexible TLS policy table. For earlier releases, read the description of the obsolete Postfix 2.2 per-site table.
The new policy table is specified via the smtp_tls_policy_maps
While secure verification can also be achieved with manual routing overrides in Postfix transport(5) tables, that approach can deliver mail to the wrong host when domains are assigned to new gateway hosts. The "match" attribute approach avoids the problems of manual routing overrides; mail is deferred if verification of a new MX host fails.
mechanism, this uses as a policy lookup key a potentially untrusted server hostname, and lacks control over what names can appear in server certificates. Because of this, the obsolete mechanism is typically vulnerable to false DNS hostname information in MX or CNAME records. These attacks can be eliminated only with great difficulty. The new policy table
Avoid policy lookups with the bare hostname. Instead, use the full destination nexthop (enclosed in [] with a possible ":port" suffix) as the per-site table lookup key (a recipient domain or MX-enabled transport nexthop with no port suffix may look like a bare hostname, but is still a suitable destination). With Postfix 2.3 and later, use of the obsolete approach documented here is strongly discouraged: use the new policy table instead.
Starting with Postfix 2.3, the underlying TLS enforcement levels are common to the obsolete per-site table and the new policy table. The main.cf smtp_tls_mandatory_ciphers and smtp_tls_mandatory_protocols
parameters control the TLS ciphers and protocols for mandatory encryption regardless of which table is used. The smtp_tls_verify_cert_match parameter determines the match strategy for the obsolete "MUST" keyword in the same way as for the "verify" level in the new policy.
Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key ....................++++++ .....++++++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase:whatever
% openssl req -new -nodes -keyout foo-key.pem -out foo-req.pem -days 365
Using configuration from /etc/ssl/openssl.cnf Generating a 1024 bit RSA private key ........................................++++++ ....++++++ writing new private key to 'foo-key.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request.
State or Province Name (full name) :New York
Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'New York' localityName :PRINTABLE:'Westchester' organizationName :PRINTABLE:'Porcupine' commonName :PRINTABLE:'foo.porcupine.org' emailAddress :IA5STRING:'wietse@porcupine.org' Certificate is to be certified until Nov 21 19:40:56 2005 GMT (365 days) Sign the certificate? :y
...limit of 20 lines reached, additional matching lines are not shown...

Postfix Configuration Parameters, Feb 8 2008
Note: automatic BCC recipients are produced only for new mail.
Whether or not to use the local biff service. This service sends "new mail" notifications to users who have requested new mail notification with the UNIX command "biff y".
Time to pause before accepting a new message, when the message arrival rate exceeds the message delivery rate. This feature is turned on by default (it's disabled on SCO UNIX due to an SCO bug).
A list of Milter (mail filter) applications for new mail that does not arrive via the Postfix smtpd(8) server. This includes local submission via the sendmail(1) command line, new mail that arrives via the Postfix qmqpd(8) server, and old mail that is re-injected into the queue with "postsuper -r". See the MILTER_README document for details.
Note: automatic BCC recipients are produced only for new mail.
Optional lookup tables with new contact information for users or domains that no longer exist. The table format and lookups are documented in relocated(5).
Note: automatic BCC recipients are produced only for new mail.
The message digest algorithm used to construct remote SMTP server certificate fingerprints. At the "fingerprint" TLS security level (smtp_tls_security_level = fingerprint), the server certificate is verified by directly matching its fingerprint. The fingerprint is the message digest of the server certificate using the selected algorithm. With a digest algorithm resistant to "second pre-image" attacks, it is not feasible to create a new public key and a matching certificate that has the same fingerprint.
The above keywords correspond to the "none", "may", "encrypt" and "verify" security levels for the new smtp_tls_security_level parameter introduced in Postfix 2.3. Starting with Postfix 2.3, and independently of how the policy is specified, the smtp_tls_mandatory_ciphers and smtp_tls_mandatory_protocols parameters only apply when TLS encryption is mandatory. Connections for which encryption is optional enable all "export" grade and better ciphers.
The match attribute is most useful when multiple domains are supported by common server, the policy entries for additional domains specify matching rules for the primary domain certificate. While transport table overrides routing the secondary domains to the primary nexthop also allow secure verification, they risk delivery to the wrong destination when domains change hands or are re-assigned to new gateways. With the "match" attribute approach, routing is not perturbed, and mail is deferred if verification of a new MX host fails.
smtpd_client_new_tls_session_rate_limit
The maximal number of new (i.e., uncached) TLS sessions that a remote SMTP client is allowed to negotiate with this service per time unit. The time unit is specified with the anvil_rate_time_unit
By default, a remote SMTP client can negotiate as many new TLS sessions per time unit as Postfix can accept.
smtpd_client_new_tls_session_rate_limit = 100
Change the meaning of the next restriction, so that it logs a warning instead of rejecting a request (look for logfile records that contain "reject_warning"). This is useful for testing new restrictions in a "live" environment without risking unnecessary loss of mail.
A list of Milter (mail filter) applications for new mail that arrives via the Postfix smtpd(8) server. See the MILTER_README
For servers that are not public Internet MX hosts, Postfix 2.3 supports configurations with no certificates. This entails the use of just the anonymous TLS ciphers, which are not supported by typical SMTP clients. Since such clients will not, as a rule, fall back to plain text after a TLS handshake failure, the server will be unable to receive email from TLS enabled clients. To avoid accidental configurations with no certificates, Postfix 2.3 enables certificate-less operation only when the administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that new Postfix configurations will not accidentally run with no certificates.

Postfix Configuration Parameters, Feb 8 2008
Note: automatic BCC recipients are produced only for new mail.
Whether or not to use the local biff service. This service sends "new mail" notifications to users who have requested new mail notification with the UNIX command "biff y".
Time to pause before accepting a new message, when the message arrival rate exceeds the message delivery rate. This feature is turned on by default (it's disabled on SCO UNIX due to an SCO bug).
A list of Milter (mail filter) applications for new mail that does not arrive via the Postfix smtpd(8) server. This includes local submission via the sendmail(1) command line, new mail that arrives via the Postfix qmqpd(8) server, and old mail that is re-injected into the queue with "postsuper -r". See the MILTER_README document for details.
Note: automatic BCC recipients are produced only for new mail.
Optional lookup tables with new contact information for users or domains that no longer exist. The table format and lookups are documented in relocated(5).
Note: automatic BCC recipients are produced only for new mail.
The message digest algorithm used to construct remote SMTP server certificate fingerprints. At the "fingerprint" TLS security level (smtp_tls_security_level = fingerprint), the server certificate is verified by directly matching its fingerprint. The fingerprint is the message digest of the server certificate using the selected algorithm. With a digest algorithm resistant to "second pre-image" attacks, it is not feasible to create a new public key and a matching certificate that has the same fingerprint.
The above keywords correspond to the "none", "may", "encrypt" and "verify" security levels for the new smtp_tls_security_level parameter introduced in Postfix 2.3. Starting with Postfix 2.3, and independently of how the policy is specified, the smtp_tls_mandatory_ciphers and smtp_tls_mandatory_protocols parameters only apply when TLS encryption is mandatory. Connections for which encryption is optional enable all "export" grade and better ciphers.
The match attribute is most useful when multiple domains are supported by common server, the policy entries for additional domains specify matching rules for the primary domain certificate. While transport table overrides routing the secondary domains to the primary nexthop also allow secure verification, they risk delivery to the wrong destination when domains change hands or are re-assigned to new gateways. With the "match" attribute approach, routing is not perturbed, and mail is deferred if verification of a new MX host fails.
smtpd_client_new_tls_session_rate_limit
The maximal number of new (i.e., uncached) TLS sessions that a remote SMTP client is allowed to negotiate with this service per time unit. The time unit is specified with the anvil_rate_time_unit
By default, a remote SMTP client can negotiate as many new TLS sessions per time unit as Postfix can accept.
smtpd_client_new_tls_session_rate_limit = 100
Change the meaning of the next restriction, so that it logs a warning instead of rejecting a request (look for logfile records that contain "reject_warning"). This is useful for testing new restrictions in a "live" environment without risking unnecessary loss of mail.
A list of Milter (mail filter) applications for new mail that arrives via the Postfix smtpd(8) server. See the MILTER_README
For servers that are not public Internet MX hosts, Postfix 2.3 supports configurations with no certificates. This entails the use of just the anonymous TLS ciphers, which are not supported by typical SMTP clients. Since such clients will not, as a rule, fall back to plain text after a TLS handshake failure, the server will be unable to receive email from TLS enabled clients. To avoid accidental configurations with no certificates, Postfix 2.3 enables certificate-less operation only when the administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that new Postfix configurations will not accidentally run with no certificates.

Postfix Configuration Parameters, Feb 8 2008
Note: automatic BCC recipients are produced only for new mail.
Whether or not to use the local biff service. This service sends "new mail" notifications to users who have requested new mail notification with the UNIX command "biff y".
Time to pause before accepting a new message, when the message arrival rate exceeds the message delivery rate. This feature is turned on by default (it's disabled on SCO UNIX due to an SCO bug).
A list of Milter (mail filter) applications for new mail that does not arrive via the Postfix smtpd(8) server. This includes local submission via the sendmail(1) command line, new mail that arrives via the Postfix qmqpd(8) server, and old mail that is re-injected into the queue with "postsuper -r". See the MILTER_README document for details.
Note: automatic BCC recipients are produced only for new mail.
Optional lookup tables with new contact information for users or domains that no longer exist. The table format and lookups are documented in relocated(5).
Note: automatic BCC recipients are produced only for new mail.
The message digest algorithm used to construct remote SMTP server certificate fingerprints. At the "fingerprint" TLS security level (smtp_tls_security_level = fingerprint), the server certificate is verified by directly matching its fingerprint. The fingerprint is the message digest of the server certificate using the selected algorithm. With a digest algorithm resistant to "second pre-image" attacks, it is not feasible to create a new public key and a matching certificate that has the same fingerprint.
The above keywords correspond to the "none", "may", "encrypt" and "verify" security levels for the new smtp_tls_security_level parameter introduced in Postfix 2.3. Starting with Postfix 2.3, and independently of how the policy is specified, the smtp_tls_mandatory_ciphers and smtp_tls_mandatory_protocols parameters only apply when TLS encryption is mandatory. Connections for which encryption is optional enable all "export" grade and better ciphers.
The match attribute is most useful when multiple domains are supported by common server, the policy entries for additional domains specify matching rules for the primary domain certificate. While transport table overrides routing the secondary domains to the primary nexthop also allow secure verification, they risk delivery to the wrong destination when domains change hands or are re-assigned to new gateways. With the "match" attribute approach, routing is not perturbed, and mail is deferred if verification of a new MX host fails.
smtpd_client_new_tls_session_rate_limit
The maximal number of new (i.e., uncached) TLS sessions that a remote SMTP client is allowed to negotiate with this service per time unit. The time unit is specified with the anvil_rate_time_unit
By default, a remote SMTP client can negotiate as many new TLS sessions per time unit as Postfix can accept.
smtpd_client_new_tls_session_rate_limit = 100
Change the meaning of the next restriction, so that it logs a warning instead of rejecting a request (look for logfile records that contain "reject_warning"). This is useful for testing new restrictions in a "live" environment without risking unnecessary loss of mail.
A list of Milter (mail filter) applications for new mail that arrives via the Postfix smtpd(8) server. See the MILTER_README
For servers that are not public Internet MX hosts, Postfix 2.3 supports configurations with no certificates. This entails the use of just the anonymous TLS ciphers, which are not supported by typical SMTP clients. Since such clients will not, as a rule, fall back to plain text after a TLS handshake failure, the server will be unable to receive email from TLS enabled clients. To avoid accidental configurations with no certificates, Postfix 2.3 enables certificate-less operation only when the administrator explicitly sets "smtpd_tls_cert_file = none". This ensures that new Postfix configurations will not accidentally run with no certificates.

Postfix and Mailman deliver enhanced e-mail security and performance, Feb 8 2008
Learn how these new open source products can improve the way you manage mail
Cameron and Kathryn introduce two new open source mail products called Postfix and Mailman and explain how you can begin to use them in your own work. Find out what you need to get started with these interesting and rewarding technologies. (2,500 words)
Finally, if you select or are leaning toward Postfix, strongly consider subscribing to the postfix-announce, postfix-users, and/or postfix-testers mailing lists. The latter, in particular, is where the design of new features is properly discussed. The Postfix home pages supplies more information about these mailing lists.
Mailman further resembles Postfix in having a robust and swift generation. Warning: As a practical matter, you'll need root access on your host to configure Mailman properly. Most open source products can be generated and initially tested by ordinary Unix users. Some organizations have a policy that requires this. With Mailman, though, you'll at least need to create a new account and group (the default for both is "mailman") for Mailman's use.
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.
News & Views: - Silicon Carny: A lazy afternoon - Man evolves to machine - SCO grasping at the Linux straw? - Anything to everything - The physical data architecture - New Product Briefs (March 1, 1999) - - Sun extends Community Source Licensing to chip architectures - The latest tidbits on Sun deals and product news - The network is the story: News on the latest Internet standards and struggles - - Up-to-the-minute news on Sun's rivals - Regular Expressions: Dylan's appeal - LinuxWorld: IBM fills out Linux offerings - New Product Briefs (March 1, 1999) - Microsoft touts E-commerce strategy - News from LinuxWorld Expo - Highlights from LinuxWorld Expo - Open source software braces for another big year - Sun licenses Java Media APIs to Linux developers - Sun licenses Java Media APIs to Linux developers - Sun unveils new application server strategy - Gates predicts NT's high-end success next year - New Product Briefs (March 1, 1999) - Sun, NTT DoCoMo team on Java, Jini - Sun keeps its foot in Java's door - Intel unveils Pentium III Xeon - SCO dresses up UnixWare for the data center - CEBIT: Linux Alley Is crowded, but lacks apps - IDC: Worldwide server revenues down in Q4/98, volume up - Sun, AOL form e-commerce "virtual company" - AOL reorganizes to fold in Netscape
Tech Expertise: - The Solaris process model: Part 7 - Do you have an Incident Response Procedure in place? - Building a reliable NT server, part 3 - Sun's new compilers and tools - Using bc, the programmable calculator, Part 1 - A patch-work column, Part 2

Postfix Bottleneck Analysis, Feb 8 2008
service scanning the queue directory periodically or when notified of new message arrival by the postdrop(1) program. The postdrop(1)
Messages can potentially stay in the "hold" queue longer than $maximal_queue_lifetime. If such "old" messages need to be released from the "hold" queue, they should typically be moved into the "maildrop" queue using "postsuper -r", so that the message gets a new timestamp and is given more than one opportunity to be delivered. Messages that are "young" can be moved directly into the "deferred" queue using "postsuper -H".
All new mail entering the Postfix queue is written by the cleanup(8) service into the "incoming" queue. New queue files are created owned by the "postfix" user with an access bitmask (or mode) of 0600. Once a queue file is ready for further processing the cleanup(8) service changes the queue file mode to 0700 and notifies the queue manager of new mail arrival. The queue manager ignores incomplete queue files whose mode is 0600, as these are still being written by cleanup.
The queue manager scans the incoming queue bringing any new mail into the "active" queue if the active queue resource limits have not been exceeded. By default, the active queue accommodates at most 20000 messages. Once the active queue message limit is reached, the queue manager stops scanning the incoming (and deferred, see below) queue.
Under normal conditions the incoming queue is nearly empty (has only mode 0600 files), with the queue manager able to import new messages into the active queue as soon as they become available.
The in_flow_delay parameter is used to clamp the input rate when the queue manager starts to fall behind. The cleanup(8) service will pause for $in_flow_delay seconds before creating a new queue file if it cannot obtain a "token" from the queue manager.
Input into the active queue comes both from new mail in the "incoming" queue, and retries of mail in the "deferred" queue. Should the "deferred" queue get really large, retries of old mail can dominate the arrival rate of new mail. Systems with more CPU, faster disks and more network bandwidth can deal with larger deferred queues, but as a rule of thumb the deferred queue scales to somewhere between 100,000 and 1,000,000 messages with good performance unlikely above that "limit". Systems with queues this large should typically stop accepting new mail, or put the backlog "on hold" until the underlying issue is fixed (provided that there is enough capacity to handle just the new mail).

Catching up with Wietse Venema, creator of Postfix and TCP Wrapper, Feb 8 2008
Wietse: I have been finishing things, so that I can start work on new projects. After a major documentation rewrite for the Postfix mail system, I finished the manuscript for a book on computer forensic analysis with Dan Farmer. When I finish something, I normally start reading everything that I can lay my hands on and then inspiration comes.
Wietse: It has been fairly typical here in southern New York state. We dig ourselves out from the snow a few times in January and February.
Once the snow is gone in March, we spend quality time walking up a hill or riding a bike. Many several former railroads are/were converted into trails, and riding them is fun. Unlike Europe, where I grew up, the roads in southern New York state are not really safe for riding a bicycle.
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?
Linuxsecurity.com: Postfix is a really good Mail Transport Agent (MTA), I've been using it for a long time and I set it up for someone any chance I get. Why did you decide to write a new MTA instead of scaling down an existing MTA? :-)
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.
Wietse: We just finished a manuscript for a book on computer forensic analysis that we hope will come out this year. In this book we write about things that we learned after we released the TCT. For some experiments we used the TCT, and for other measurements we wrote a few new tools. When this book is published I will be happy to turn my attention to other projects.

Postfix Queue Scheduler, Feb 8 2008
The queue manager is by far the most complex part of the Postfix mail system. It schedules delivery of new mail, retries failed deliveries at specific times, and removes mail from the queue after the last delivery attempt. There are two major classes of mechanisms that control the operation of the queue manager.
The pseudo code shows how the ideas behind new concurrency scheduler are implemented as of November 2007. The actual code can be found in the module qmgr/qmgr_queue.c.
Discussions about the concurrency scheduler redesign started early 2004, when the primary goal was to find alternatives that did not exhibit exponential growth or rapid concurrency throttling. No code was implemented until late 2007, when the primary concern had shifted towards better handling of server concurrency limits. For this reason we measure how well the new scheduler does this job. The table below compares mail delivery performance of the old +/-1 feedback per delivery with several less-than-1 feedback functions, for different limited-concurrency server scenarios.
The first results are for a FreeBSD 6.2 server, where our artificially low listen(2) backlog results in a very short kernel queue for established connections. The table shows that all deferred deliveries failed due to a 30s connection timeout, and none failed due to a server greeting timeout. This measurement simulates what happens when the server's connection queue is completely full under load, and the TCP engine drops new connections.
The following sections describe the new queue manager and its preemptive scheduler algorithm. Note that the document was originally written to describe the changes between the new queue manager (in this text referred to as nqmgr, the name it was known by before it became the default queue manager) and the old queue manager (referred to as oqmgr). This is why it refers to oqmgr
The first approximation of the new scheduling algorithm is like this:
Things work fine in such state for most of the time, because the current job is either completely read in-core or has as much recipient slots as there are, but there is one situation which we still have to take care of specially. Imagine if the current job is preempted by some unread job from the job list and there are no more recipient slots available, so this new current job could read only batches of qmgr_message_recipient_minimum recipients at a time. This would really degrade performance. For this reason, each transport has extra pool of transport_extra_recipient_limit recipient slots, dedicated exactly for this situation. Each time an unread job preempts the current job, it gets half of the remaining recipient slots from the normal pool and this extra pool.

Postfix Performance Tuning, Feb 8 2008
If the number of smtpd(8) processes has reached the process limit as specified in master.cf, new SMTP clients must wait until a process becomes available. Increase the number of processes if memory permits. See the instructions given under "Tuning the number of Postfix processes".
When the smtpd(8) server replies slowly, sessions take more time, so that more smtpd(8) server processes are needed to handle the load. When your Postfix smtpd(8) server process limit is reached, new clients must wait until a server process becomes available.
IMPORTANT: These delays slow down Postfix, too. When too much delay is configured, the number of simultaneous SMTP sessions will increase until it reaches the smtpd(8) server process limit, and new SMTP clients must wait until an smtpd(8) server process becomes available.
smtpd_client_new_tls_session_rate_limit (default: no limit) The maximum number of new TLS sessions (without using the TLS session cache) that an SMTP client may negotiate in the time interval specified with anvil_rate_time_unit (default: 60s).
The active queue becomes saturated with mail that has delivery problems. New mail enters the active queue only when an old message is deferred. This is a slow process that usually requires timing out one or more SMTP connections.
All available Postfix delivery agents become occupied trying to connect to unreachable sites etc. New mail has to wait until a delivery agent becomes available. This is a slow process that usually requires timing out one or more SMTP connections.

Postfix Lookup Table Overview, Feb 8 2008
Examples are address rewriting (the lookup string is the old address, and the result is the new address) or access control (the lookup string is the client, sender or recipient, and the result is an action such as "reject").
When you make changes to a database while the mail system is running, it would be desirable if Postfix avoids reading information while that information is being changed. It would also be nice if you can change a database without having to execute "postfix reload", in order to force Postfix to use the new information. Each time you do "postfix reload" Postfix loses a lot of performance.
If you change a network database such as LDAP, NIS or SQL, there is no need to execute "postfix reload". The LDAP, NIS or SQL server takes care of read/write access conflicts and gives the new data to Postfix once that data is available.
If you change a local file based database such as DBM or Berkeley DB, there is no need to execute "postfix reload". Postfix uses file locking to avoid read/write access conflicts, and whenever a Postfix daemon process notices that a file has changed it will terminate before handling the next client request, so that a new process can initialize with the new database.
creates a new file, and renames the file upon successful completion.

Salon.com Technology | How Big Blue fell for Linux, Feb 8 2008
Search Directory -->About Salon Table Talk Newsletters Advertise in Salon Investor Relations
Find out more | Log in
your PDA
Salon.com headlines from My Netscape
View Salon privately with SafeWeb
The magazines may not make good marketing material right now. Collab.net, the brainchild of open-source star Brian Behlendorf,* aims to make a business out of, he says, "distilling the principles of open source." But at least half of the covers of these new-economy bibles are screaming dire, boldface warnings about the current dot-com meltdown, including Wall Street's sharp turn away from Linux-related stocks in the spring and summer.
It's a good thing the office tunes are soothing, because jangled nerves are suddenly everywhere in that strange land where free software and dot-com start-ups mix. In the summer of 1999, Red Hat's IPO, occurring right in the middle of a packed LinuxWorld convention, sent attendees into a dither of delight. But in mid-August, no less an authority than the New York Times takes advantage of another LinuxWorld convention to declaim about how Wall Street is souring on Linux.
And yet, those who take heart in a one-day surge are just as guilty of overeagerness. Both cynics and Pollyannas are like marks suckered into a New York huckster's game of three-card monte. While they busily stare, striving to follow the movements of the dealer's hand, they never notice that Times Square around them is meanwhile being transformed from pimp heaven into Disneyland. Sure, companies in the business of selling Linux may have questionable prospects -- but the open-source revolution is still in full effect, rebuilding the software industry from top to bottom, forcing everyone to adapt.
Improve eBusiness operations by quantum leaps
Let us Clean your house for a Year! FREE!
Looking for Love? Try Salon Personals
...limit of 20 lines reached, additional matching lines are not shown...

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.
Netscape to Release New Browser Engine to Developers
These sites are not part of The New York Times on the Web, and The Times has no control over their content or availability.
Help/Feedback | Classifieds | Services | New York Today
Copyright 1998 The New York Times Company

SecurityPortal - Kurt's Closet: Postfix - the Sendmail replacement, Feb 8 2008
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.
New problems
Of course replacing one software package with another will solve certain problems, and create new ones, to which Postfix is no exception. Partly due to it's design as a secure MTA you may experience some minor problems with Postfix. The best example is email to root, Postfix, by default, does not like to deliver email with elevated privileges (necessary to send email to root typically). You will need to define an alias for root in the aliases file, such as: "root: someuser". This also leads to problems with several mailing list packages, especially SmartList, which by default does all sorts of funky things that Postfix will not stand for. In any case I would advise switching to Majordomo, it is easier to configure and maintain via email for owners of mailing lists.

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.
Away from the keyboard, Venema and his wife Annita are looking forward to replacing the bicycles they sold when they moved. This will give them a chance to explore the North Country Trailway, which runs near their new home. "This is continent collision zone, with lots of weird geology. It's quite a change from the Netherlands, which is all flat and which has almost no trees."
What's New:
Prentice Hall co-authors of Java Design Pete Coad, Mark Mayfield, and Jon Kern are talking in our new forum. Join them!

sendmail.net:, Feb 8 2008
I post to it infrequently, and I follow it from a distance. I don't know if you've noticed, but there are several new vulnerabilities every week. I don't think anybody on this planet is really keeping up to date with all these vulnerabilities.
I guess you have the same problem whether you're developing a new application or doing a new version of an existing application: you have to keep from scaring users off by changing things too fast.
It's possible, but it hasn't really evolved at all. Instead, what you see is new applications coming up and, side by side, email. There is the World Wide Web - and email has, of course, inherited some of its features. But the basic model is still the same: I sit at my screen, I do stuff, I send it to you. You receive my message and read it from your screen. And the two actions are completely disconnected. That's the basic character of email. If people want realtime conversations, they have lots of choices already.

Postfix Address Classes, Feb 8 2008
Postfix 2.0 address classes introduce a few incompatible changes in documented behavior. In order to ease the transitions, new parameters have default values that are backwards compatible.
For backwards compatibility with Postfix version 1.1, the new virtual_alias_maps parameter defaults to $virtual_maps, and the new virtual_alias_domains parameter defaults to $virtual_alias_maps.
For backwards compatibility with Postfix version 1.1, the new virtual_mailbox_domains parameter defaults to $virtual_mailbox_maps.

Postfix before-queue Milter support, Feb 8 2008
When new mail arrives via the sendmail(1) command line, the Postfix cleanup(8) server pretends that the mail arrives with ESMTP from "localhost" with IP address "127.0.0.1". The result is very similar to what happens with command line submissions in Sendmail version 8.12 and later, although Sendmail uses a different mechanism to achieve this result.
When new mail arrives via the qmqpd(8) server, the Postfix cleanup(8) server pretends that the mail arrives with ESMTP, and uses the QMQPD client hostname and IP address.
When old mail is re-injected into the queue with "postsuper -r", the Postfix cleanup(8) server uses the same client information that was used when the mail arrived as new mail.
/* get hostname; used in the X header and in new MIME boundaries */

Postfix Built-in Content Inspection, Feb 8 2008
The picture makes clear that the filter works while Postfix is receiving new mail. This means that Postfix can reject mail from the network without having to return undeliverable mail to the originator address (which is often spoofed anyway). However, this ability comes at a price: if mail inspection takes too much time, then the remote client will time out, and the client may send the same message repeatedly.
While all SMTP server processes are waiting for the cleanup(8) servers to finish, new SMTP clients have to wait until an SMTP server process becomes available. This causes mail deliveries to time out before they have even begun.
### Create a new message: $msg = MIME::Lite->new( From => 'your@send.er', To => 'your@recipie.nt', # Cc => 'some@other.com, some@more.com', Subject => 'pflogsumm', Date => `date`, Type => 'text/plain', Encoding => 'base64', Path => '/tmp/pflogg', );

Postfix Installation From Source Code, Feb 8 2008
Each system type that Postfix knows is identified by a unique name. Examples: SUNOS5, FREEBSD4, and so on. When porting Postfix to a new system, the first step is to choose a SYSTEMTYPE name for the new system. You must use a name that includes at least the major version of the operating system (such as SUNOS4 or LINUX2), so that different releases of the same system can be supported without confusion.
Add a case statement to the "makedefs" shell script in the source code top-level directory that recognizes the new system reliably, and that emits the right system-specific information.
Add an "#ifdef SYSTEMTYPE" section to the central util/sys_defs.h include file. You may have to invent new feature macro names.

Postfix SMTP Access Policy Delegation, Feb 8 2008
Policy delegation is now the preferred method for adding policies to Postfix. It's much easier to develop a new feature in few lines of Perl, Python, Ruby, or TCL, than trying to do the same in C code.
When the status file size exceeds some threshold you can simply rename or remove the file without adverse effects; Postfix automatically creates a new file. In the worst case, new mail will be delayed by an hour or so. To lessen the impact, rename or remove the file in the middle of the night at the beginning of a weekend.
# If new request, add this client/sender/recipient to the database.

Please choose a Postfix Web Site, Feb 8 2008
USA, NH, New Durham
USA, NY, New York
USA, NY, New York
New Zealand, Auckland

Postfix Address Rewriting, Feb 8 2008
new mail cleanup(8) always_bcc, sender_bcc_maps, recipient_bcc_maps receive_override_options
Note: automatic BCC recipients are produced only for new mail.
The Postfix qmgr(8) queue manager selects new mail from the incoming queue or old mail from the deferred queue, and asks the trivial-rewrite(8) address rewriting and resolving daemon where it should be delivered.

Postfix Address Rewriting, Feb 8 2008
new mail cleanup(8) always_bcc, sender_bcc_maps, recipient_bcc_maps receive_override_options
Note: automatic BCC recipients are produced only for new mail.
The Postfix qmgr(8) queue manager selects new mail from the incoming queue or old mail from the deferred queue, and asks the trivial-rewrite(8) address rewriting and resolving daemon where it should be delivered.

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.
Postfix is designed to be compatible with Sendmail to make migration easier, and to make the change transparent to users. In fact, you can continue to use Sendmail in conjunction with Postfix, allowing the new mailer to replace specific mail functions as needed. Postfix continues support for /etc/aliases and delivery to any of the standard mail directories as well as to a specified file or command. It also respects user.lock files and will obey $HOME/.forward directives. Basically all the aspects of Sendmail are present except one significant one -- sendmail.cf.
One issue that might affect your decision in considering a switch to Postfix is that there is not yet any commercial support for the product. If you now have support from your system vendor, or if you have contracted with a third party for Sendmail support, you will probably be on your own for the near future if you run Postfix. On the other hand, Postfix provides a stable and secure mail system that is easy to set up, yet provides most of the flexibility of Sendmail. It is a new application that has not had much experience in the real world, but based on its design and initial performance reports, it is an application that has tremendous promise and is probably worth an investment of some time to investigate its potential for your site.
SDMG Websites: C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, Sys Admin, SD Expo,SD Magazine, Unixreview.com, Windows Developer's Journal

SecurityPortal - Postfix - The Sendmail replacement part II, Feb 8 2008
This is an ideal feature for large companies that want to remap users without too much trouble. It allows you to specify the original email address and the new email address. For example, user joebob goes to another ISP instead of forwarding all their mail, which results in senders not realizing it has changed. They get an error message specifying the new email address. This can be used for wholesale domain moves as well. Simply add the following to your main.cf:
Then put the email address, username or domain name, followed by the email address or domain name, and anyone sending email in will get a nice error telling them the new address. See man relocated(5) for more information.


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