You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Jerry Malcolm <te...@malcolms.com> on 2019/10/27 21:58:58 UTC
RRT on Sender
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RRT on Sender
Posted by Jerry Malcolm <te...@malcolms.com>.
Maybe 'rewrite sender' is not the right terminology. Maybe
"deriveSendersAccount" would better explain it. My whole point is that
if I prefer to use an 'alias' as my 'from' address instead of using the
precise address that is my account name, the code is going to look for a
'sent' folder in the 'alias' account (which doesn't exist). My only
concern is that the correct account is derived for the 'sent' folder
whether or not an alias is used for the 'from/sender' address. A few
weeks ago before I figured out what was happening, I had a lot of email
going into sent folders on 'orphaned' mailboxes named after aliases.
On 11/4/2019 3:10 AM, Tellier Benoit wrote:
> On 30/10/2019 01:08, Jerry Malcolm wrote:
>> I am curious, though, why you said it wouldn't be enabled for sending by
>> default.
> I say that because what you describe is well defined specific use cases
> (internal vs external mailboxes).
>
> As a James user, I don't have such needs, and I don't expect to rewritte
> senders.
>
> However, you should be able to modify the default configuration, adding
> a bundled mailet into it in order to configure this feature.
>
> That is what I mean by "not enabled by default".
>
> Regards,
>
> Benoit
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RRT on Sender
Posted by Tellier Benoit <bt...@apache.org>.
On 30/10/2019 01:08, Jerry Malcolm wrote:
> I am curious, though, why you said it wouldn't be enabled for sending by
> default.
I say that because what you describe is well defined specific use cases
(internal vs external mailboxes).
As a James user, I don't have such needs, and I don't expect to rewritte
senders.
However, you should be able to modify the default configuration, adding
a bundled mailet into it in order to configure this feature.
That is what I mean by "not enabled by default".
Regards,
Benoit
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RRT on Sender
Posted by Jerry Malcolm <te...@malcolms.com>.
Benoit,
I really like that idea. I also like the idea of renaming the mailet to
AddressRewriteTable. Probably keep an empty subclass of
AddressRewriteTable with the name RecipientRewriteTable so that existing
mailetcontainers.xml will still work.
I am curious, though, why you said it wouldn't be enabled for sending by
default. I see two separate uses for RRT:
1) Catch common misspelling errors in the inbound address. My mailbox
is malcolm@xyz.com. But it is a very common misspelling to leave out
the 2nd "L". So people repeatedly send email to malcom@xyz.com. So RRT
would 'correct' the misspelling on inbound and map it to the correct
inbox. I would never purposely send an email with my 'from' address
having the misspelled version of my name. So RRT would not be necessary
on outbound for this situation. This also includes where I want info@,
sales@, service@ to all map to my real malcolm@xyz.com address.
2) "Internal" mailbox name vs. "External" email address. This
represents the two scenarios I mentioned yesterday where my mailbox name
is never exposed externally, and I use an alias for sending and
receiving. If I have a different mailbox name than my 'external' email
address, I would want both outbound 'sender folder' and inbound 'inbox
folder' to be mapped automatically to the real mailbox name. If it is
enabled for inbound only by default, and I don't realize this, all of my
sent email will go to an orphan mailbox with the alias name, and I won't
be able to find my 'sent' email. Other than a slight performance hit, I
don't think it's going to affect anything to run it on both outbound and
inbound. If there is no RRT match to the sender email address, it'll
pass over the rewriting. But we can discuss enabling by default further
after I get the new mailet ready to go.
I'll start looking into the changes.
Thanks.
Jerry
On 10/28/2019 11:13 PM, Tellier Benoit wrote:
> 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:
>> commoncompanymail@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:
>>
>> bob@mycompany.com --> commoncompanymail@mycompany.com
>>
>> susie@mycompany.com --> commoncompanymail@mycompany.com
>>
>> I never want to expose commoncompanymail@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 me@myserver.com map to a user account
>> named:
>> mysupercrypticemailaddress123213123144@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-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RRT on Sender
Posted by Tellier Benoit <bt...@apache.org>.
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:
> commoncompanymail@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:
>
> bob@mycompany.com --> commoncompanymail@mycompany.com
>
> susie@mycompany.com --> commoncompanymail@mycompany.com
>
> I never want to expose commoncompanymail@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 me@myserver.com map to a user account
> named:
> mysupercrypticemailaddress123213123144@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-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RRT on Sender
Posted by Jerry Malcolm <te...@malcolms.com>.
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:
commoncompanymail@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:
bob@mycompany.com --> commoncompanymail@mycompany.com
susie@mycompany.com --> commoncompanymail@mycompany.com
I never want to expose commoncompanymail@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 me@myserver.com map to a user account
named:
mysupercrypticemailaddress123213123144@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-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: RRT on Sender
Posted by Tellier Benoit <bt...@apache.org>.
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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org