OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Victor.Duchovni_at_morganstanley.com
Date: Fri Nov 15 2002 - 00:44:13 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Thu, 14 Nov 2002, Brian P. Martin wrote:

    > Viktor,
    >
    > Your note says 20021114, but looking on the FTP site
    > (ftp://postfix.webweaver.net/experimental/) the latest I find is
    > postfix-1.1.11-20021109. Should I be looking somewhere else?

    ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-1.1.11-20021114.tar.gz

    As for the problem analysis I must apologize for sending Wietse on a
    wild-goose chase. Wietse I am terribly sorry to waste your precious time.
    The code in local does not have any duplicate detection problems. I got
    lazy and deserve to treated a bit more skeptically for while :-(

    The message bounced because it came in from another host already decorated
    with a "Delivered-To: user$myorigin" header (see the "delivered_init:"
    line from the posted "local" -v log).

    While the original recipient address did not match the "Delivered-To:"
    header, the rewrite to user$myorigin after forward regenerated the
    original address and the loop detection kicked in.

    Imagine a situation in which two hosts A and B share a common local domain
    "example.com" with some or all of the mailboxes stored on B, specifically
    the mailbox for "user" is on host B. Suppose further that A delivers to
    the mailboxes on B via the "alias_maps" of its "local" delivery agent.

    On host A mydestination is A.example.com, example.com.
    On host B mydestination is B.example.com, example.com.
    On host B myorigin is example.com (this is bad see below).

    If a message submitted for userexample.com on A is routed to its final
    mailbox via an alias to userB.example.com, then the message will leave
    host A decorated with a "Delivered-To: userexample.com" header and with
    an envelope recipient of userB.example.com.

    If on B the user has a .forward file listing his own mailbox, then loop
    detection will trigger despite the fact that the message has only visited
    B once.

    The problem is that is not safe to use a $myorigin setting on any host "B"
    which performs final delivery (actually hosts user .forward files and
    mailboxes) when the same domain name is in $mydestination for another host
    "A" that aliases mail for some or all mailboxes to "B".

    The solution is to not lie and set the myorigin setting on "B" to
    "B.example.com". If it necessary to masquerade this in order to emit only
    "example.com" on outbound mails, use "masquerade_domains" rather than
    lying about $myorigin.

    If "A" is a corporate gateway without any actual mailboxes and "B" is the
    internal mailhub, the best approach is to not use "local"/"alias_maps" on
    "A". Use "virtual_maps" or per-user "transport_maps" instead if at all
    possible.

    If using "local" on the gateway is unavoidable (try at all cost to avoid
    it, my gateway uses "error" as its "local_transport"), then host "B"'s
    myorigin may not match any of the domains in "A"'s mydestination. and
    masquerading (if necessary) combined with proper MUA settings is the only
    way to hide the mailserver names from the outside world.

    Again my apologies for seeing implementation problems, where configuration
    is to blame. My only excuse is that the configuration problem is subtle
    involves multiple hosts, ... and the loop detection code involves multiple
    daemons. The fact that the code is correct despite the many possible
    complications is a testament to a well designed and implemented system.
    Thanks again Wietse.

    -- 
    	Viktor.