If thats the case its a bug we should fix.. Bye, Norman
2011/1/26 Eric Charles <[email protected]>: > With current trunk, I defined a virtualuser, and ValidRecipientHandler > rejected the mail because it does not exist as a "user/recipient". > I don't have the exception anymore cause I finally added the virtualuser as > a user. > I'm also fine with the option to update the ValidRecipientHanlder and have > alias that don't exist as real user. > > Tks, > Eric > > > On 26/01/2011 10:46, Norman Maurer wrote: >> >> Comments inside.. >> >> 2011/1/26 Eric Charles<[email protected]>: >>> >>> Hi, >>> >>> So we've got the api: "alias maps to existinguser" :) >>> >>> 1. Should alias always exist as user? >>> 1.1 no => we need to update ValidRecipientHandler (and maybe other smtp >>> handlers) to make it work, otherwise users will be sorry. >>> 1.2 yes => we could automatically create the alias user if it does not >>> exists (but with which password ?) or throw an exception asking to create >>> the user beforehand. >> >> Could you explain why we need to update the ValidRecipientHandler ? I >> think if a mapping exist it should accept the email. If later in the >> mailet pipeline we see that there is no real user for the email and it >> is not "consumed" by a matcher we will send a bounce. Thats what qmail >> + patches and postfix does and I think thats the correct way of >> handling it.. >> >>> 2. Can we map to a non-existing user (for further processing but >>> mailets,...) >>> 2.1. no => we could automatically create the user if it does not exist >>> (but >>> with which password ?) or throw an exception asking to create the user >>> beforehand. >>> 2.2 yes => we need to update ValidRecipientHandler (and maybe other smtp >>> handlers) to make it work, otherwise users will be sorry. >> >> See above.. >> >>> 3. Should we stricly follow the other MTAs working >>> 3.1. no => this may be confusing for users used to other MTAs (btw we >>> already diverge with the virtualhosting enabled by default) >>> 3.2. yes => we benefit from all the experience of those MTAs, but we may >>> be >>> >>> My preference goes to 1.2, 2.1 and 3.1. >>> I see virtualusers more like "links between existing users". The link can >>> be >>> set or can be removed, users are there and remain. >>> >>> Tks, >>> >>> Eric >>> >>> >>> On 25/01/2011 20:15, Norman Maurer wrote: >>>> >>>> Hi, >>>> >>>> comments inside.. >>>> >>>> 2011/1/25 Stefano Bagnara<[email protected]>: >>>>> >>>>> 2011/1/25 Norman Maurer<[email protected]>: >>>>>> >>>>>> 2011/1/25 Eric Charles<[email protected]>: >>>>>> [...] >>>>>>> >>>>>>> 2.- Since we enabled the SMTP ValidRcptHandler, we need to really >>>>>>> create the >>>>>>> user, before using it as an virtual user. This was not the case >>>>>>> before. >>>>>>> The >>>>>>> need to previously create a user does not worry me, but I find >>>>>>> strange >>>>>>> that, >>>>>>> depending on smtp configuration, we would or not need to create a >>>>>>> user >>>>>>> to >>>>>>> define a virtualuser. >>>>>> >>>>>> I think the need of having the existing user before add the mapping is >>>>>> a good think. We also would need to check if there is a mapping when >>>>>> deleting a user and remove it too. >>>>> >>>>> I don't agree. I usually think at aliasing as "rewriting" so I expect >>>>> to write aliases like this >>>>> alias@mydomain maps to existinguser@mydomain >>>>> >>>>> At least this is what I was used to do in sendmail (are other MTA >>>>> different from this??) >>>>> It's like "search&replace" you usually put "search" on the left and >>>>> replace on the "right". >>>> >>>> I see your point and I checked other mailservers which seems to behave >>>> like you descripted.. >>>> >>>>>>> 3.- JIRA-1126 Disallow the creation of alias from non-existing >>>>>>> username: I >>>>>>> think this is needed so we don't arrive to situation where mails are >>>>>>> no >>>>>>> more >>>>>>> delivered in case a bad usage of the API (reversing the method >>>>>>> params). >>>>>> >>>>>> +1 >>>>> >>>>> Not sure. I often use aliasing to "virtual addresses". THen I have >>>>> matchers to match this virtual addresses and do something. >>>>> So they are not users. >>>>> In my James I usually have 1 single user that is used from my >>>>> webapplication to submit messages, no other james users. Still I use >>>>> aliasing. >>>>> >>>>> Sendmail also allow bounces to be generated by virtusertable, e.g: >>>>> *@your-comapny.com maps to "error:5.1.1:550 No such user." >>>>> >>>>> (I don't know what aliasing is supported by trunk VUTs, so maybe I'm >>>>> completely wrong) >>>>> >>>> That works for james too ;) >>>> >>>>> Stefano >>>>> >>>> Bye, >>>> Norman >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> Bye, >> Norman >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
