+1,

Makes sense in most cases.

Bye,
Norman

2010/12/20 Eric Charles <e...@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<nor...@apache.org>:
>>>
>>> 2010/12/16 Stefano Bagnara<apa...@bago.org>:
>>>>
>>>> 2010/12/16 Eric Charles<e...@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 (.*)@(.*) => �...@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
>>> u...@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-unsubscr...@james.apache.org
>> For additional commands, e-mail: server-dev-h...@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to