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 [email protected]. But it is a very common misspelling to leave out
the 2nd "L". So people repeatedly send email to [email protected]. 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 [email protected] 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:
[email protected]. 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:
[email protected] --> [email protected]
[email protected] --> [email protected]
I never want to expose [email protected] 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 [email protected] 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: [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]
---------------------------------------------------------------------
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]
