Aaron Stone wrote: > > On Oct 6, 2008, at 3:58 PM, Peter Rabbitson wrote: > >> Aaron Stone wrote: >>> >>> On Oct 6, 2008, at 3:29 PM, Peter Rabbitson wrote: >>> >>>> Aaron Stone wrote: >>>>> >>>>> On Oct 6, 2008, at 11:40 AM, Peter Rabbitson wrote: >>>>> >>>>>> Aaron Stone wrote: >>>>>>> >>>>>>> On Oct 6, 2008, at 4:10 AM, Peter Rabbitson wrote: >>>>>>> >>>>>>>> >>>>>>>> If something matches we examine every forward destination. If it >>>>>>>> is an >>>>>>>> email address of the form: >>>>>>>> * [EMAIL PROTECTED] - we just forward >>>>>>>> * [EMAIL PROTECTED] AND there was a YYY above we send to [EMAIL >>>>>>>> PROTECTED] >>>>>>>> (using >>>>>>>> the >>>>>>>> same delimiter as found in the forward in case we recognize >>>>>>>> multiple >>>>>>>> delimiters) >>>>>>> >>>>>>> I'm not sure I get what you mean here... >>>>>>> >>>>>> >>>>>> Suppose we do: >>>>>> >>>>>> dbmail-users -x [EMAIL PROTECTED] -t [EMAIL PROTECTED] >>>>>> >>>>>> Then it would be neat (and logical) for any email to >>>>>> >>>>>> [EMAIL PROTECTED] to be forwarded to [EMAIL PROTECTED] >>>>>> >>>>>> This is just (to me) a logical extension of what is already in place. >>>>>> The original bug complains only about the lack of XXX+YYY@ support. >>>>> >>>>> >>>>> Oh, that's pretty neat. Currently the forward should work but with the >>>>> +mailbox removed. Does that work in practice for you? >>>>> >>>> >>>> I am not sure what your question is here. Can you clarify? >>> >>> Mail addressed to [EMAIL PROTECTED] where a forward exists for [EMAIL >>> PROTECTED] -> >>> [EMAIL PROTECTED] will work, but the original message will go into WWW's >>> Inbox. At >>> least, that's what I think happens; I haven't tried this in a while. >>> >> >> Yes this is what happens. And what I was proposing is expand on this >> schema to allow the sub-addressing to be carried over to the destination >> (unless the destination doesn't _already_ specify a sub-address on its >> own, in which case things have to be left intact) > > I'm pretty sure this is significantly non-trivial, but I'll take a look > and see! >
Oh... I thought it will be an additional line or two, as you already have extracted all the relevant information while processing the address against the alias/forward table... If it is indeed a non-trivial feature request, please disregard it. I am happy enough that XXX+YYY@ will get fixed :) Thank you for your time Cheers! _______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
