Benoit Tellier created JAMES-3944:
-------------------------------------
Summary: RRT: forward features and outgoing emails
Key: JAMES-3944
URL: https://issues.apache.org/jira/browse/JAMES-3944
Project: James Server
Issue Type: Improvement
Components: RRT
Affects Versions: 3.7.0, 3.8.0, 3.7.1, 3.7.3, 3.7.4, 3.8.1, 3.7.5
Reporter: Benoit Tellier
h3. The issue
{code:java}
GIVEN b...@my-domain.tld set up a forward for al...@external-domain.tld
WHEN ced...@another-external-domain.tld sends a mail to b...@my-domain.tld
MAIL FROM: <ced...@another-external-domain.tld>
RCPT TO: <b...@my-domain.tld>
THEN James RRT rewrites the transport envelop as:
MAIL FROM: <ced...@another-external-domain.tld>
RCPT TO: <al...@external-domain.tld>
AND would attempt the delivery to the remote server with such a transport
envelop
{code}
The problem lies down to the fact that James is not authorised to send email
for arbitrary domains. James can only send emails for *my-domain.tld* where the
SPF and DKIM settings are set solely for this domain.
When James attempt to deliver a mail from *another-external-domain.tld* all the
SPF and DKIM checks are turning into red...
h3. The (functional) solution
Outgoing forwards senders (MAIL FROM) needs to be rewritten into the original
recipient.
In the above example if we end up with :
{code:java}
MAIL FROM: <b...@my-domain.tld>
RCPT TO: <al...@external-domain.tld>
{code}
Then we would comply with the SPF / DKIM policies...
h3. Test cases
Case 1: Simple foward
{code:java}
GIVEN RRT: b...@mydomain.tld forwards mails to al...@mydomain.tld
WHEN ced...@mydomain.tld sends a mail to b...@mydomain.tld
THEN the transport envelope becomes:
MAIL FROM: b...@mydomain.tld
RCPT TO: al...@mydomain.tld
{code}
Case 2: Part of the recipient have fowards
{code:java}
GIVEN RRT: b...@mydomain.tld forwards mails to al...@mydomain.tld
WHEN ced...@mydomain.tld sends a mail to b...@mydomain.tld and
delph...@mydomain.tld
THEN the transport envelope becomes (2 mails instead of one):
MAIL FROM: b...@mydomain.tld
RCPT TO: al...@mydomain.tld
AND
MAIL FROM: ced...@mydomain.tld
RCPT TO: delph...@mydomain.tld
{code}
Case 3: Several recipient have forwards
{code:java}
GIVEN RRT: b...@mydomain.tld forwards mails to al...@mydomain.tld
AND RRT: delph...@mydomain.tld forwards mails to edg...@mydomain.tld
WHEN ced...@mydomain.tld sends a mail to b...@mydomain.tld and
delph...@mydomain.tld
THEN the transport envelope becomes (2 mails instead of one):
MAIL FROM: b...@mydomain.tld
RCPT TO: al...@mydomain.tld
AND
MAIL FROM: delph...@mydomain.tld
RCPT TO: edg...@mydomain.tld
{code}
Case 4: Chaining forwards
{code:java}
GIVEN RRT: b...@mydomain.tld forwards mails to al...@mydomain.tld
AND RRT: al...@mydomain.tld forwards mails to edg...@mydomain.tld
WHEN ced...@mydomain.tld sends a mail to b...@mydomain.tld
THEN the transport envelope becomes:
MAIL FROM: al...@mydomain.tld
RCPT TO: edg...@mydomain.tld
{code}
Case 5: Handling Alias for people having forwards
{code:java}
GIVEN RRT: b...@mydomain.tld forwards mails to al...@mydomain.tld
AND ALIAS: bob-al...@mydomain.tld for b...@mydomain.tld
WHEN ced...@mydomain.tld sends a mail to bob-al...@mydomain.tld
THEN the transport envelope becomes:
MAIL FROM: b...@mydomain.tld
RCPT TO: al...@mydomain.tld
{code}
Case 6: handling group registration for people having forwards
{code:java}
GIVEN RRT: b...@mydomain.tld forwards mails to al...@mydomain.tld
AND b...@mydomain.tld is part of gr...@mydomain.tld
WHEN ced...@mydomain.tld sends a mail to gr...@mydomain.tld
THEN the transport envelope becomes:
MAIL FROM: b...@mydomain.tld
RCPT TO: al...@mydomain.tld
{code}
Also Validate that validRCPTHandler accepts b...@domain.tld with a Forward, and
that all kind of RRT can be applied to it (unit tests?)
Also validate that Forwards are still taken into account by RRT loop detection
upon insert (JMAP + webadmin tests? )
Of course those cases can be mixed!
DOD -> Integration tests ;-) (into `/server/mailets/integration-tests` using a
mail repository to capture)
h3. How to implement
It is likely WAY easier to do this in two steps as doing it in one WOULD
REQUIRE A COMPLETE REWRITE OF THE RRT ALGORITHM (really scary)
The idea would be
- To write a mailet dedicated to forwards. Without recursivity, this mailets
looks at each recipient, see if there is a direct forward. If so remove the
recipient, copies the mail, modify recipient and sender and submits a brand new
mail via the mailet context.
- Have an option in RRT to not take forwards into account. This implies that
just next to it there is the ForwardTo mailet...
Note that interactions between RRTs and forwards would be taken into account
naturally with such a set up: recursivity of Forward rewrites and integration
to the RRT rule engine would be taken into account via multiple submissions to
the mailet container...
h3. Checklist
- [ ] Documentation for the new mailet
- [ ] Clear upgrade instructions
- [ ] Sample config is updated
TLDR: good luck!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
