OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Redhat Linux, Mailman and Sendmail
From: Brad Knowles (blkskynet.be)
Date: Tue Apr 04 2000 - 13:29:26 CDT

At 1:05 PM -0500 2000/4/4, Jonathan Bartlett wrote:

> Ummm, RFC 1123 is kind of a long document, care to be more specific?

        See section 5.3.3:

       5.3.3 Reliable Mail Receipt

          When the receiver-SMTP accepts a piece of mail (by sending a
          "250 OK" message in response to DATA), it is accepting
          responsibility for delivering or relaying the message. It must
          take this responsibility seriously, i.e., it MUST NOT lose the
          message for frivolous reasons, e.g., because the host later
          crashes or because of a predictable resource shortage.

          If there is a delivery failure after acceptance of a message,
          the receiver-SMTP MUST formulate and mail a notification
          message. This notification MUST be sent using a null ("<>")
          reverse path in the envelope; see Section 3.6 of RFC-821. The
          recipient of this notification SHOULD be the address from the
          envelope return path (or the Return-Path: line). However, if
          this address is null ("<>"), the receiver-SMTP MUST NOT send a
          notification. If the address is an explicit source route, it
          SHOULD be stripped down to its final hop.

          DISCUSSION:
               For example, suppose that an error notification must be
               sent for a message that arrived with:
               "MAIL FROM:<a,b:userd>". The notification message
               should be sent to: "RCPT TO:<userd>".

               Some delivery failures after the message is accepted by
               SMTP will be unavoidable. For example, it may be
               impossible for the receiver-SMTP to validate all the
               delivery addresses in RCPT command(s) due to a "soft"
               domain system error or because the target is a mailing
               list (see earlier discussion of RCPT).

          To avoid receiving duplicate messages as the result of
          timeouts, a receiver-SMTP MUST seek to minimize the time
          required to respond to the final "." that ends a message
          transfer. See RFC-1047 [SMTP:4] for a discussion of this
          problem.

        It's the last sentence of the first paragraph that is critical.
Using async mounts is known to cause the loss of entire filesystems
under some circumstances, and it is for this reason that most
versions of Unix do not default to mounting all filesystems async. I
quote from the FreeBSD man page for mount(8):

              async All I/O to the file system should be done asynchronously.
                      This is a dangerous flag to set, and should not be used
                      unless you are prepared to recreate the file system
                      should your system crash.

        Of course, Linux casually ignores this advice, and if a mail
administrator does not make changes to their configuration so as to
either mount the entire filesystem that /var/spool/mqueue is on with
synchronous meta-data writes, or use chattr +S on /var/spool/mqueue
to ensure that all writes to this directory are done with synchronous
meta-data updates, then they are in violation of RFC 1123, section
5.3.3.

        In fact, using chattr +S really isn't enough, since writes to
other parts of /var or /var/spool could cause the entire filesystem
to be toasted, and thus taking /var/spool/mqueue along with it. 

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blkskynet.be>                || Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49             || B-1140 Brussels
http://www.skynet.be                         || Belgium