+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