Alan,
I agree that it could go into a matcher, rather than the core, and I'll
probably do it that way.
There was never any thought to change isLocalUser functionality. The point
regarding isLocalUser is regarding the failure state. Right now the way it
works is described by:
isLocalUser isLocalServer Result
True N/A Store locally
False True Address Error
False False Relay Request
If we change isLocalServer to imply only that we're in the MX record list,
it would impact address error detection. Furthermore, JDBCVirtualUserTable
uses isLocalServer to differentiate between local users vs relay requests.
That code should go into the Redirect mailet, too.
The code I posted would work better in a matcher, and the fact is that
anyone using it for gateway behavior needs to configure one or more gateway
relays, anyway.
--- Noel
P.S. The code I posted was the bare code that handles the lookup, since I
just wanted to get the idea across. I have more code wrapped around it that
improves performance:
Total time: 36162
Successes: 9000000, time: 11395
Failures: 5000000, time: 14447
In other words, the test driver took 36 seconds. Within the test driver, 11
seconds were measured as handling 9 million successful lookups, and 14
seconds were spent in handling 5 million failures.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 20, 2003 16:18
To: James Developers List
Subject: Re: Auto-detection of MX domains and
MailetContext.isLocalServer()
The code snippet you posted, could be placed in a matcher as
opposed to part of the core – primarily because of
performance issues; nonethelsee, the questions you pose are
interesting; isLocalServer will definitely benefit by
matching a 'domain' to 'us', but does that mean that 'us'
handles the mail?? No, it doesn't; there is no implication
either that it should.
The existing method for determining local storage (
isLocalUser() ) is used for that and I see no need to
convolute this functionality.
One could redefine the meaning of isLocalServer to mean
quite simply that 'us' is contained within a mail's MX
record(s). The implication is 'Local Domain' as described
below. No need for complex definitions.
However, I think we might want to keep the ability to
perform MX lookups outside; this way we need not redefine
methods nor will we be hampered by excessive MX lookups when
all that is handled is a single domain/server. With this
scenario, the MX record to match ('us') would be variable. I
am uneasy with using getAttribute(Constants.HELLO_NAME) as
it appears to be restrictive.
> Consider the following code, which implements automatic
> detection of MX domains:
>
> Collection mxRecords = dns.findMXRecords(domain);
> if (mxRecords != null && (mxRecords.contains(us))
> { ... we are responsible for this domain ... }
> else { we are not responsible for this domain ... }
>
> One question is where to put such code. We could add that
> to James.isLocalServer if the meaning of that method is
> that we are responsible for that domain, but not if it
> means that we are also responsible for that domain's
> storage. The latter is checked by calling
> MailetContext.isLocalUser(), but we need to know when to
> bounce mail for whom the local user is simply invalid.
>
> So what does isLocalServer mean? Does it mean that the
> mail repository is stored there? Does it mean that
> relaying checks don't need to be made? Do we need two
> methods?
>
> 1 - Local Stores - mail will be stored locally
>
> 2 - Local Domain - mail may or may not be stored locally,
> but we are a defined MX for that domain, and don't have to
> do relaying checks for mail going to it.
>
> 3 - !Local Domain - we are being asked to relay mail for
> a domain that we don't handle.
>
> We need to clarify this point in order to more readily
> support complex configurations than just local storage or
> remote relaying.
>
> Another issue is what value to use for the parameter to
> mxRecords.contains(...). We can't simply use
> InetAddress.getLocalHost().getHost(). I wouldn't mind
> keying off of
> getMailetContext().getAttribute(Constants.HELLO_NAME).
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
