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 [email protected] set up a forward for [email protected]
WHEN [email protected] sends a mail to [email protected]
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
THEN James RRT rewrites the transport envelop as:
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
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: <[email protected]>
RCPT TO: <[email protected]>
{code}
Then we would comply with the SPF / DKIM policies...
h3. Test cases
Case 1: Simple foward
{code:java}
GIVEN RRT: [email protected] forwards mails to [email protected]
WHEN [email protected] sends a mail to [email protected]
THEN the transport envelope becomes:
MAIL FROM: [email protected]
RCPT TO: [email protected]
{code}
Case 2: Part of the recipient have fowards
{code:java}
GIVEN RRT: [email protected] forwards mails to [email protected]
WHEN [email protected] sends a mail to [email protected] and
[email protected]
THEN the transport envelope becomes (2 mails instead of one):
MAIL FROM: [email protected]
RCPT TO: [email protected]
AND
MAIL FROM: [email protected]
RCPT TO: [email protected]
{code}
Case 3: Several recipient have forwards
{code:java}
GIVEN RRT: [email protected] forwards mails to [email protected]
AND RRT: [email protected] forwards mails to [email protected]
WHEN [email protected] sends a mail to [email protected] and
[email protected]
THEN the transport envelope becomes (2 mails instead of one):
MAIL FROM: [email protected]
RCPT TO: [email protected]
AND
MAIL FROM: [email protected]
RCPT TO: [email protected]
{code}
Case 4: Chaining forwards
{code:java}
GIVEN RRT: [email protected] forwards mails to [email protected]
AND RRT: [email protected] forwards mails to [email protected]
WHEN [email protected] sends a mail to [email protected]
THEN the transport envelope becomes:
MAIL FROM: [email protected]
RCPT TO: [email protected]
{code}
Case 5: Handling Alias for people having forwards
{code:java}
GIVEN RRT: [email protected] forwards mails to [email protected]
AND ALIAS: [email protected] for [email protected]
WHEN [email protected] sends a mail to [email protected]
THEN the transport envelope becomes:
MAIL FROM: [email protected]
RCPT TO: [email protected]
{code}
Case 6: handling group registration for people having forwards
{code:java}
GIVEN RRT: [email protected] forwards mails to [email protected]
AND [email protected] is part of [email protected]
WHEN [email protected] sends a mail to [email protected]
THEN the transport envelope becomes:
MAIL FROM: [email protected]
RCPT TO: [email protected]
{code}
Also Validate that validRCPTHandler accepts [email protected] 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: [email protected]
For additional commands, e-mail: [email protected]
