Viktor,

Wow! Now *that* was impressive. I haven't tested it, but everything you
say fits our situation and sounds right on. Our firewall is "A" in your
scenario, with our internal mail server being "B". Both present themselves
as being your "example.com", because they're serving different audiences
(the outside world or the inside world). However, they do exchange mail
between themselves of course, and that's where the tangle comes in. I would
have never figured out how the "Delivered-To" made the failure occur.
Spectacular work. We'll get right on it tomorrow morning.

Wietse,

As far as I can tell, the whole world is switching to Postfix. I certainly
recommend it to all my clients. You've done (and continue to do) the field
a huge service. Thank you for your help on this tricky problem.

                                     -Brian

> -----Original Message-----
> From: owner-postfix-userspostfix.org
> [mailto:owner-postfix-userspostfix.org]On Behalf Of
> Victor.Duchovnimorganstanley.com
> Sent: Thursday, November 14, 2002 10:44 PM
> To: Brian P. Martin
> Cc: postfix-userspostfix.org
> Subject: RE: .forward loops instead of placing mail in mailbox
> Importance: High
>
>
> 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/postf
> ix-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 ]