You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <no...@apache.org> on 2010/12/14 10:49:51 UTC
[PROPOSAL] MailServer interface make sense / Move methods ?
Hi there,
after spending some thoughts about last optimization before the next
release, I stumpled again over the MailServer interface.
The Mailserver interface has corrently 5 methods listed. I think a few
of them should be moved and a few should get removed at all. Let me
propose the following changes:
* MailServer.getId();
This method is only used by MailImpl to generate a new Mail name.
I think there are two things which would make sense...
1) Remove the method from the interface and just move the Id
generation code to MailImpl. In fact its only some kind of UUID and
long combination
2) Create a new Interface called MailNameGenerator with the method
createName() which will generate a new name to use in the Mail.
I think I would prefer 1.
* MailServer.supportVirtualHosting();
This method returns true if the server supports virtualhosting.
Which in fact means that the users must be added with an
"@domainpart". So your users would look like: user1@domain1,
user2@domain2 etc.
So I think it would make more sense to move the method to
UsersRepository interface. By default it would return false
* MailServer.getDefaultDomain();
Return the default domain which will get used if an email is
delivered to an user via smtp and no domainpart was given. As this is
clearly about domains I would suggest to move it to DomainList
interface
* MailServer.getHelloName();
Return the default hello name which will be used if no other is
configured for the service. I would just remove this method at all and
fallback to dnsservice.getLocalHost() by default if no hello name is
configured for the service.
* MailServer.getPostMaster():
Is only used by MailetContext.getPostMaster() as a wrapped call. So
just remove it.
Wdyt ?
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Eric Charles <er...@apache.org>.
If OK to everyone, I will commit/document enableVirtualHosting=true and
JPADomainList configs.
Tks,
Eric
On 20/12/2010 21:23, Norman Maurer wrote:
> +1,
>
> Makes sense in most cases.
>
> Bye,
> Norman
>
> 2010/12/20 Eric Charles<er...@apache.org>:
>> Most users also expect to add/remove domains via management interfaces.
>> JPADomainList could be shipped as default if we want to cover users'
>> expectations.
>>
>> Tks,
>>
>> Eric
>>
>>
>> On 19/12/2010 20:05, Norman Maurer wrote:
>>> 2010/12/17 Norman Maurer<no...@apache.org>:
>>>> 2010/12/16 Stefano Bagnara<ap...@bago.org>:
>>>>> 2010/12/16 Eric Charles<er...@apache.org>:
>>>>>> Hi,
>>>>>> We also need to cover James used as simple MTA/mail-relay/honeypot
>>>>>> without
>>>>>> any users defined (for example, in an internal network when processing
>>>>>> mails
>>>>>> for virus/spam detection,...).
>>>>>> In this case, we could use in this case the "localhost" domain.
>>>>>>
>>>>>> I'm also in favor of having only the virtualhosting enabled. I guess
>>>>>> this
>>>>>> would simply lead to remove this notion from code/conf.
>>>>> In anyone needs the "old" behaviour then he just need to add a rewrite
>>>>> for the recipient (.*)@(.*) => $1@defaultdomain as the first mailet. I
>>>>> think everything is easier to understand this way (not sure if we
>>>>> already provide a good way to do this rewrite easily, but we can
>>>>> create a simple mailet if we don't already have something usable).
>>>>>
>>>>> Stefano
>>>> I thought a bit about it and I think the rewrite stuff would work once
>>>> the email is spooled. But there is still the problem with
>>>> authentication (SMTP/POP3/IMAP). The user will need to login with
>>>> user@domain as username. Not really a problem but maybe confuse
>>>> people, but I guess if we document it it would be enough...
>>>>
>>>> Bye
>>>> Norman
>>>>
>>> After thinking a bit more about it I think Stefano is right.. we
>>> should just use virtualhosting by default. Which also will force users
>>> contain a domain part in the username.
>>>
>>> It's prolly the thing most of users look for anyway and for all others
>>> we can add a Mailet which do the mapping.
>>>
>>> Bye,
>>> Norman
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Norman Maurer <no...@apache.org>.
+1,
Makes sense in most cases.
Bye,
Norman
2010/12/20 Eric Charles <er...@apache.org>:
> Most users also expect to add/remove domains via management interfaces.
> JPADomainList could be shipped as default if we want to cover users'
> expectations.
>
> Tks,
>
> Eric
>
>
> On 19/12/2010 20:05, Norman Maurer wrote:
>>
>> 2010/12/17 Norman Maurer<no...@apache.org>:
>>>
>>> 2010/12/16 Stefano Bagnara<ap...@bago.org>:
>>>>
>>>> 2010/12/16 Eric Charles<er...@apache.org>:
>>>>>
>>>>> Hi,
>>>>> We also need to cover James used as simple MTA/mail-relay/honeypot
>>>>> without
>>>>> any users defined (for example, in an internal network when processing
>>>>> mails
>>>>> for virus/spam detection,...).
>>>>> In this case, we could use in this case the "localhost" domain.
>>>>>
>>>>> I'm also in favor of having only the virtualhosting enabled. I guess
>>>>> this
>>>>> would simply lead to remove this notion from code/conf.
>>>>
>>>> In anyone needs the "old" behaviour then he just need to add a rewrite
>>>> for the recipient (.*)@(.*) => $1@defaultdomain as the first mailet. I
>>>> think everything is easier to understand this way (not sure if we
>>>> already provide a good way to do this rewrite easily, but we can
>>>> create a simple mailet if we don't already have something usable).
>>>>
>>>> Stefano
>>>
>>> I thought a bit about it and I think the rewrite stuff would work once
>>> the email is spooled. But there is still the problem with
>>> authentication (SMTP/POP3/IMAP). The user will need to login with
>>> user@domain as username. Not really a problem but maybe confuse
>>> people, but I guess if we document it it would be enough...
>>>
>>> Bye
>>> Norman
>>>
>> After thinking a bit more about it I think Stefano is right.. we
>> should just use virtualhosting by default. Which also will force users
>> contain a domain part in the username.
>>
>> It's prolly the thing most of users look for anyway and for all others
>> we can add a Mailet which do the mapping.
>>
>> Bye,
>> Norman
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Eric Charles <er...@apache.org>.
Most users also expect to add/remove domains via management interfaces.
JPADomainList could be shipped as default if we want to cover users'
expectations.
Tks,
Eric
On 19/12/2010 20:05, Norman Maurer wrote:
> 2010/12/17 Norman Maurer<no...@apache.org>:
>> 2010/12/16 Stefano Bagnara<ap...@bago.org>:
>>> 2010/12/16 Eric Charles<er...@apache.org>:
>>>> Hi,
>>>> We also need to cover James used as simple MTA/mail-relay/honeypot without
>>>> any users defined (for example, in an internal network when processing mails
>>>> for virus/spam detection,...).
>>>> In this case, we could use in this case the "localhost" domain.
>>>>
>>>> I'm also in favor of having only the virtualhosting enabled. I guess this
>>>> would simply lead to remove this notion from code/conf.
>>> In anyone needs the "old" behaviour then he just need to add a rewrite
>>> for the recipient (.*)@(.*) => $1@defaultdomain as the first mailet. I
>>> think everything is easier to understand this way (not sure if we
>>> already provide a good way to do this rewrite easily, but we can
>>> create a simple mailet if we don't already have something usable).
>>>
>>> Stefano
>> I thought a bit about it and I think the rewrite stuff would work once
>> the email is spooled. But there is still the problem with
>> authentication (SMTP/POP3/IMAP). The user will need to login with
>> user@domain as username. Not really a problem but maybe confuse
>> people, but I guess if we document it it would be enough...
>>
>> Bye
>> Norman
>>
> After thinking a bit more about it I think Stefano is right.. we
> should just use virtualhosting by default. Which also will force users
> contain a domain part in the username.
>
> It's prolly the thing most of users look for anyway and for all others
> we can add a Mailet which do the mapping.
>
> Bye,
> Norman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Norman Maurer <no...@apache.org>.
2010/12/17 Norman Maurer <no...@apache.org>:
> 2010/12/16 Stefano Bagnara <ap...@bago.org>:
>> 2010/12/16 Eric Charles <er...@apache.org>:
>>> Hi,
>>> We also need to cover James used as simple MTA/mail-relay/honeypot without
>>> any users defined (for example, in an internal network when processing mails
>>> for virus/spam detection,...).
>>> In this case, we could use in this case the "localhost" domain.
>>>
>>> I'm also in favor of having only the virtualhosting enabled. I guess this
>>> would simply lead to remove this notion from code/conf.
>>
>> In anyone needs the "old" behaviour then he just need to add a rewrite
>> for the recipient (.*)@(.*) => $1@defaultdomain as the first mailet. I
>> think everything is easier to understand this way (not sure if we
>> already provide a good way to do this rewrite easily, but we can
>> create a simple mailet if we don't already have something usable).
>>
>> Stefano
>
> I thought a bit about it and I think the rewrite stuff would work once
> the email is spooled. But there is still the problem with
> authentication (SMTP/POP3/IMAP). The user will need to login with
> user@domain as username. Not really a problem but maybe confuse
> people, but I guess if we document it it would be enough...
>
> Bye
> Norman
>
After thinking a bit more about it I think Stefano is right.. we
should just use virtualhosting by default. Which also will force users
contain a domain part in the username.
It's prolly the thing most of users look for anyway and for all others
we can add a Mailet which do the mapping.
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Norman Maurer <no...@apache.org>.
2010/12/16 Stefano Bagnara <ap...@bago.org>:
> 2010/12/16 Eric Charles <er...@apache.org>:
>> Hi,
>> We also need to cover James used as simple MTA/mail-relay/honeypot without
>> any users defined (for example, in an internal network when processing mails
>> for virus/spam detection,...).
>> In this case, we could use in this case the "localhost" domain.
>>
>> I'm also in favor of having only the virtualhosting enabled. I guess this
>> would simply lead to remove this notion from code/conf.
>
> In anyone needs the "old" behaviour then he just need to add a rewrite
> for the recipient (.*)@(.*) => $1@defaultdomain as the first mailet. I
> think everything is easier to understand this way (not sure if we
> already provide a good way to do this rewrite easily, but we can
> create a simple mailet if we don't already have something usable).
>
> Stefano
I thought a bit about it and I think the rewrite stuff would work once
the email is spooled. But there is still the problem with
authentication (SMTP/POP3/IMAP). The user will need to login with
user@domain as username. Not really a problem but maybe confuse
people, but I guess if we document it it would be enough...
Bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Stefano Bagnara <ap...@bago.org>.
2010/12/16 Eric Charles <er...@apache.org>:
> Hi,
> We also need to cover James used as simple MTA/mail-relay/honeypot without
> any users defined (for example, in an internal network when processing mails
> for virus/spam detection,...).
> In this case, we could use in this case the "localhost" domain.
>
> I'm also in favor of having only the virtualhosting enabled. I guess this
> would simply lead to remove this notion from code/conf.
In anyone needs the "old" behaviour then he just need to add a rewrite
for the recipient (.*)@(.*) => $1@defaultdomain as the first mailet. I
think everything is easier to understand this way (not sure if we
already provide a good way to do this rewrite easily, but we can
create a simple mailet if we don't already have something usable).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Eric Charles <er...@apache.org>.
Hi,
We also need to cover James used as simple MTA/mail-relay/honeypot
without any users defined (for example, in an internal network when
processing mails for virus/spam detection,...).
In this case, we could use in this case the "localhost" domain.
I'm also in favor of having only the virtualhosting enabled. I guess
this would simply lead to remove this notion from code/conf.
Tks,
Eric
On 15/12/2010 20:21, Norman Maurer wrote:
> 2010/12/15 Stefano Bagnara<ap...@bago.org>:
>>>> What about moving to virtual hosting as the default (and maybe the ONLY) option?
>>>> When you setup a mailserver you have a domain, I think it is easier to
>>>> understand for newbies if they create users with their full email
>>>> address instead of using simple "usernames" and receive email for that
>>>> username on each configured domain.
>>> I thought about this too.. I'm just not sure if thats really the think
>>> todo. For example in qmail and postfix you don't have virtualhosting
>>> enabled by default. So I thought follow this princip make sense..
>> I always thought that unix servers still used this because of legacy
>> issues. Unix users don't have a domain and that servers inherited
>> (from sendmail) this mail issue in order to deliver mail to local
>> users (and use system authentication/authorization by default).
>>
>> We don't provide such system integration so it seems we just get the
>> disadvantages and no advantage.
> See your point here..
>
>> BTW I'm fine with both solutions. It's just that now it's the moment
>> to "change" stuff, and I think it would be easier to
>> understand/explain/document if we only support one method as I don't
>> see advantages in not enabling virtualhosting.
>>
>> Stefano
>>
> I need to think about it a bit more.. Anyone else has some thoughts about this ?
>
> Bye,
> Norman
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Norman Maurer <no...@apache.org>.
2010/12/15 Stefano Bagnara <ap...@bago.org>:
>>> What about moving to virtual hosting as the default (and maybe the ONLY) option?
>>> When you setup a mailserver you have a domain, I think it is easier to
>>> understand for newbies if they create users with their full email
>>> address instead of using simple "usernames" and receive email for that
>>> username on each configured domain.
>>
>> I thought about this too.. I'm just not sure if thats really the think
>> todo. For example in qmail and postfix you don't have virtualhosting
>> enabled by default. So I thought follow this princip make sense..
>
> I always thought that unix servers still used this because of legacy
> issues. Unix users don't have a domain and that servers inherited
> (from sendmail) this mail issue in order to deliver mail to local
> users (and use system authentication/authorization by default).
>
> We don't provide such system integration so it seems we just get the
> disadvantages and no advantage.
See your point here..
>
> BTW I'm fine with both solutions. It's just that now it's the moment
> to "change" stuff, and I think it would be easier to
> understand/explain/document if we only support one method as I don't
> see advantages in not enabling virtualhosting.
>
> Stefano
>
I need to think about it a bit more.. Anyone else has some thoughts about this ?
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Stefano Bagnara <ap...@bago.org>.
>> What about moving to virtual hosting as the default (and maybe the ONLY) option?
>> When you setup a mailserver you have a domain, I think it is easier to
>> understand for newbies if they create users with their full email
>> address instead of using simple "usernames" and receive email for that
>> username on each configured domain.
>
> I thought about this too.. I'm just not sure if thats really the think
> todo. For example in qmail and postfix you don't have virtualhosting
> enabled by default. So I thought follow this princip make sense..
I always thought that unix servers still used this because of legacy
issues. Unix users don't have a domain and that servers inherited
(from sendmail) this mail issue in order to deliver mail to local
users (and use system authentication/authorization by default).
We don't provide such system integration so it seems we just get the
disadvantages and no advantage.
BTW I'm fine with both solutions. It's just that now it's the moment
to "change" stuff, and I think it would be easier to
understand/explain/document if we only support one method as I don't
see advantages in not enabling virtualhosting.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Norman Maurer <no...@apache.org>.
Hi Stefano,
thanks for the feedback.. Just some minor comments inline
2010/12/15 Stefano Bagnara <ap...@bago.org>:
> 2010/12/14 Norman Maurer <no...@apache.org>:
>> Hi there,
>>
>> after spending some thoughts about last optimization before the next
>> release, I stumpled again over the MailServer interface.
>> The Mailserver interface has corrently 5 methods listed. I think a few
>> of them should be moved and a few should get removed at all. Let me
>> propose the following changes:
>>
>> * MailServer.getId();
>> This method is only used by MailImpl to generate a new Mail name.
>> I think there are two things which would make sense...
>>
>> 1) Remove the method from the interface and just move the Id
>> generation code to MailImpl. In fact its only some kind of UUID and
>> long combination
>> 2) Create a new Interface called MailNameGenerator with the method
>> createName() which will generate a new name to use in the Mail.
>>
>> I think I would prefer 1.
>
> I agree.
>
>> * MailServer.supportVirtualHosting();
>> This method returns true if the server supports virtualhosting.
>> Which in fact means that the users must be added with an
>> "@domainpart". So your users would look like: user1@domain1,
>> user2@domain2 etc.
>> So I think it would make more sense to move the method to
>> UsersRepository interface. By default it would return false
>
> What about moving to virtual hosting as the default (and maybe the ONLY) option?
> When you setup a mailserver you have a domain, I think it is easier to
> understand for newbies if they create users with their full email
> address instead of using simple "usernames" and receive email for that
> username on each configured domain.
I thought about this too.. I'm just not sure if thats really the think
todo. For example in qmail and postfix you don't have virtualhosting
enabled by default. So I thought follow this princip make sense..
>
>> * MailServer.getDefaultDomain();
>> Return the default domain which will get used if an email is
>> delivered to an user via smtp and no domainpart was given. As this is
>> clearly about domains I would suggest to move it to DomainList
>> interface
>
> Make sense.
>
>> * MailServer.getHelloName();
>> Return the default hello name which will be used if no other is
>> configured for the service. I would just remove this method at all and
>> fallback to dnsservice.getLocalHost() by default if no hello name is
>> configured for the service.
>
> I agree. THe hello name should be configured in the specific service,
> doens't make sense to configure it in MailServer (it is not useful
> there).
>
>> * MailServer.getPostMaster():
>> Is only used by MailetContext.getPostMaster() as a wrapped call. So
>> just remove it.
>
> +1
>
> Go ahead!
> Stefano
>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Stefano Bagnara <ap...@bago.org>.
2010/12/14 Norman Maurer <no...@apache.org>:
> Hi there,
>
> after spending some thoughts about last optimization before the next
> release, I stumpled again over the MailServer interface.
> The Mailserver interface has corrently 5 methods listed. I think a few
> of them should be moved and a few should get removed at all. Let me
> propose the following changes:
>
> * MailServer.getId();
> This method is only used by MailImpl to generate a new Mail name.
> I think there are two things which would make sense...
>
> 1) Remove the method from the interface and just move the Id
> generation code to MailImpl. In fact its only some kind of UUID and
> long combination
> 2) Create a new Interface called MailNameGenerator with the method
> createName() which will generate a new name to use in the Mail.
>
> I think I would prefer 1.
I agree.
> * MailServer.supportVirtualHosting();
> This method returns true if the server supports virtualhosting.
> Which in fact means that the users must be added with an
> "@domainpart". So your users would look like: user1@domain1,
> user2@domain2 etc.
> So I think it would make more sense to move the method to
> UsersRepository interface. By default it would return false
What about moving to virtual hosting as the default (and maybe the ONLY) option?
When you setup a mailserver you have a domain, I think it is easier to
understand for newbies if they create users with their full email
address instead of using simple "usernames" and receive email for that
username on each configured domain.
> * MailServer.getDefaultDomain();
> Return the default domain which will get used if an email is
> delivered to an user via smtp and no domainpart was given. As this is
> clearly about domains I would suggest to move it to DomainList
> interface
Make sense.
> * MailServer.getHelloName();
> Return the default hello name which will be used if no other is
> configured for the service. I would just remove this method at all and
> fallback to dnsservice.getLocalHost() by default if no hello name is
> configured for the service.
I agree. THe hello name should be configured in the specific service,
doens't make sense to configure it in MailServer (it is not useful
there).
> * MailServer.getPostMaster():
> Is only used by MailetContext.getPostMaster() as a wrapped call. So
> just remove it.
+1
Go ahead!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [PROPOSAL] MailServer interface make sense / Move methods ?
Posted by Norman Maurer <no...@apache.org>.
I created an issue which has a patch attached..
https://issues.apache.org/jira/browse/JAMES-1147
If I hear nothing against it I will commit the changes..
Bye,
Norman
2010/12/14 Norman Maurer <no...@apache.org>:
> Hi there,
>
> after spending some thoughts about last optimization before the next
> release, I stumpled again over the MailServer interface.
> The Mailserver interface has corrently 5 methods listed. I think a few
> of them should be moved and a few should get removed at all. Let me
> propose the following changes:
>
> * MailServer.getId();
> This method is only used by MailImpl to generate a new Mail name.
> I think there are two things which would make sense...
>
> 1) Remove the method from the interface and just move the Id
> generation code to MailImpl. In fact its only some kind of UUID and
> long combination
> 2) Create a new Interface called MailNameGenerator with the method
> createName() which will generate a new name to use in the Mail.
>
> I think I would prefer 1.
>
> * MailServer.supportVirtualHosting();
> This method returns true if the server supports virtualhosting.
> Which in fact means that the users must be added with an
> "@domainpart". So your users would look like: user1@domain1,
> user2@domain2 etc.
> So I think it would make more sense to move the method to
> UsersRepository interface. By default it would return false
>
> * MailServer.getDefaultDomain();
> Return the default domain which will get used if an email is
> delivered to an user via smtp and no domainpart was given. As this is
> clearly about domains I would suggest to move it to DomainList
> interface
>
> * MailServer.getHelloName();
> Return the default hello name which will be used if no other is
> configured for the service. I would just remove this method at all and
> fallback to dnsservice.getLocalHost() by default if no hello name is
> configured for the service.
>
> * MailServer.getPostMaster():
> Is only used by MailetContext.getPostMaster() as a wrapped call. So
> just remove it.
>
>
> Wdyt ?
>
> Bye,
> Norman
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org