Ok just tried it with current trunk.. if there is an alias which maps to an non exist address it accept the mail via ValidRcptHandler.
Bye, Norman 2011/1/26 Norman Maurer <[email protected]>: > 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]
