On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Sendmail merges aliases, virtualusertable, users entries to fill in a
single map for the matching.
We can't do this because we have mailets.
Sure, I just wanted to bring up the idea.
Maybe a flag (per hostname) to say whether to be rigoro
Am Freitag, den 26.05.2006, 15:02 +0200 schrieb Stefano Bagnara:
> Serge Knystautas wrote:
> > On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >> Is what you propose a service like:
> >>
> >> public class RewritingService {
> >> public MailAddress[] rewrite(MailAddress address);
>
Serge Knystautas wrote:
On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Is what you propose a service like:
public class RewritingService {
public MailAddress[] rewrite(MailAddress address);
}
Just to throw it out there... one thing that makes sendmail rather
strong is that sin
Serge Knystautas wrote:
> one thing that makes sendmail rather strong is that since
> it's aliases are quite structured, it can know (and thus
> reject during SMTP protocol) recipients that it cannot
> handle for authoritative domain. So perhaps add both a
> rewrite() and a handles() method?
Som
On 5/26/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Is what you propose a service like:
public class RewritingService {
public MailAddress[] rewrite(MailAddress address);
}
Just to throw it out there... one thing that makes sendmail rather
strong is that since it's aliases are quite
de and to expose services that allow us to modularize an
> aspect... [continue...]
>
> > This is not the problem with JAMES-426. The issue with JAMES-426 is that it
> > neither takes into account that we can have non-JDBC virtual tables, nor the
> > fact that we can have mu
h JAMES-426 is that it
neither takes into account that we can have non-JDBC virtual tables, nor the
fact that we can have multiple virtual user tables. If implemented, it
would, at best, be a temporary solution for a sub-set of users.
Exposing a virtual user mapping service, and then querying th
res themselves, I instead prefer to
refactor the code and to expose services that allow us to modularize an
aspect... [continue...]
This is not the problem with JAMES-426. The issue with JAMES-426 is that it
neither takes into account that we can have non-JDBC virtual tables, nor the
fact that
r would have a valid mapping, and if the mapping would be
> local.
>
> That requires a bit of thought, rather than rushing into coding, because we
> can configure multiple virtual user tables, implying that any client of the
> service would need to make sure that the desired m
The issue with JAMES-426 is that it
neither takes into account that we can have non-JDBC virtual tables, nor the
fact that we can have multiple virtual user tables. If implemented, it
would, at best, be a temporary solution for a sub-set of users.
Exposing a virtual user mapping service, and then q
Noel J. Bergman wrote:
That requires a bit of thought, rather than rushing into coding
I'm against this fear of coding.
Writing code many times takes much less that discussing and it decreases
the misunderstandings because we all share the JVM/Java specification
knowledge.
I have lost the
g into coding, because we
can configure multiple virtual user tables, implying that any client of the
service would need to make sure that the desired mapping was being applied.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PRO
This patch enhances virtual user processing in JAMES, and affects
JDBCVirtualUserTable. Included:
1) Refactoring of common functionality in an abstract superclass,
AbstractVirtualUserTable. Subclasses need only map a virtual input
MailAddress to a target recipient (or recipients). See javadoc for d
13 matches
Mail list logo
