In a previous life I maintained 10 mail servers that all
were primary MX host for the same domain. Each host used
the equivalent of

    myorigin = $mydomain
    mydestination = myhostname, $mydomain, localhost.$mydomain

All users had an alias

    username: usernameserver.my.domain

That forwarded their mail to the "right" server.

Life was simple. Everyone's mail went to the right server
without loops.

        Wietse

Victor.Duchovnimorganstanley.com:
> 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.
>
>
>

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