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 =3d dns.findMXRecords(domain);
> if (mxRecords !=3d 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]
