|
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
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 user
example.com on A is routed to its final
mailbox via an alias to user
B.example.com, then the message will leave
host A decorated with a "Delivered-To: user
example.com" header and with
an envelope recipient of user
B.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 ]