Il 26 gennaio 2011 10.00.39 UTC+1, Eric Charles <[email protected]> ha scritto: > 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.
1.1 IIRC we ValidRecipientHandler also supports an additional regex to match further addresses (in case you want to deal with them with mailets): do I remember correctly? Otherwise I think we should support this someway, so we get the benefits of fast fail during SMTP conversation also when people wants to write mailet based processors. > 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. 2.2 > 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 3.2 > 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. Maybe "virtual user" is not a good name. I see it as a generic rewrite method. With a single map I can add aliases, custom errors, 1-to-many recipients, domain mappings and much more. I think the old 2.3 behaviour was not good nor intuitive WRT user aliasing and forwarding (that required fake users to create aliases) and in fact we agreed to remove aliasing and forwarding from core because it was a weird/unexpected behaviour. I know I'm not a good target user for this because I used sendmail since '96 so much that I've been used to Eric Allman language for rewriting (but thanks God I forgot the language now!) but I don't know any MTA using virtual users as mapping between users like you explain in this mail. That said we can even have both behaviours supported by different implementations. Maybe the behaviour I propose is better reflected by a "RecipientRewriteTable" name instead of "VirtualUserTable" name. Stefano > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
