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]
