Ok so what you need is a "RewriteSender" mailet. It will resolve sender using RRT (as for recipient)
Except that rewriting to several addresses should fail (mailet container exception handling allows the user to specify the behavior when this happen). While making this mailet available in James bundled mailets, it should not be configured by default. Also, this brings the debate of "RecipientRewriteTable" naming... If we start applying this to senders, this naming is then clearly outdated. We should then rather call this API "AddressRewriteTable". Would this make sense? Regards, Benoit On 28/10/2019 23:44, Jerry Malcolm wrote: > Benoit, > > Sorry, I wasn't clear enough on the statement. I agree that the RRT > itself cannot be bidirectional. My situation is as follows: > > A company wants all employees to see company mail and be able to reply. > So there is only one user account (i.e. mailbox) for the company: > commoncompanym...@mycompany.com. But each employee has an alias address > so that the company's clients feel they are working with a particular > person unless another employee needs to jump in and answer a question, > etc. (Similar to the 'forum' model we have on this JAMES group). > > In the rrt: > > b...@mycompany.com --> commoncompanym...@mycompany.com > > su...@mycompany.com --> commoncompanym...@mycompany.com > > I never want to expose commoncompanym...@mycompany.com externally. > Bob sets up his account to send as bob@..... Likewise Susie uses > susie@..... When mail is received, RRT correctly maps bob@/susie@ to > commoncompanymail@.... and stores the email in the real 'common...' > account. > > The problem occurs when bob or susie sends an email. The email 'sender' > is bob@.... or susie@ since those are the external email addresses. But > right now, the server creates a previously-non-existent orphan mailbox > named bob@..... or susie@..... and stores the outbound mail in those boxes. > > In a fully aliased environment, where there is a common shared mailbox > among employees, yet the company clients email back and forth with 'bob' > or 'susie', I believe that both inbound and outbound mail should be > mapped to the rrt. > > This doesn't have to only apply to a common account. If for whatever > reason, there is a need to have m...@myserver.com map to a user account > named: > mysupercrypticemailaddress123213123...@jerrysjamesserverver34.com, I > believe we should have outbound mail map sender to mysupercryptic...... > account as well as having inbound map recipient to mysupercryptic..... > Otherwise, user is going to need to have two different user accounts to > see both inbound and outbound mail. > > Am I still missing something? > > Thanks, > > Jerry > > On 10/28/2019 6:00 AM, Tellier Benoit wrote: >> Hi Jerry, >> >> Recipient rewrite is not a bijection, as one recipient might be >> rewritten into several addresses. >> >> This means that, in some corner cases, you might end up with "two" >> senders. >> >> So solving that problem is not easy, and corner cases will arise. >> >> To answer you, I'm not sure "sender mapping" should be done "at all", >> especially that most clients (thunderbird, JMAP, etc..) handle this by >> themselves. >> >> Best regards, >> >> Benoit >> >> On 28/10/2019 04:58, Jerry Malcolm wrote: >>> How is RRT supposed to work with the sender side? I understand that RRT >>> stands for "Recipient......". But the translations still need to work >>> on outbound as well for storing in the 'sent' folder. I don't see >>> anywhere in the code that sender rrt is processed. And I confirmed >>> that ToSenderFolder was attempting to store my email using my 'alias' >>> sender address instead of the user account the alias address maps to in >>> rrt. >>> >>> Is the intended architecture design that RRT should handle sender as >>> well as recipient? Or should sender mapping be done elsewhere? I can >>> make the necessary changes and submit them to git. But as in other >>> cases, I want to do it the 'intended' way. >>> >>> Jerry >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org >>> For additional commands, e-mail: server-dev-h...@james.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org >> For additional commands, e-mail: server-dev-h...@james.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
