[JAMES-3944] RRT: forward features and outgoing emails

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.7.0, 3.8.0, 3.7.1, 3.7.3, 3.7.4, 3.8.1, 3.7.5
• Component/s: RRT
• Assignee: Unassigned
• Reporter: Benoit Tellier
• Created: 06/Oct/23 08:26
• Updated: 27/Oct/23 06:45
• Resolved: 12/Oct/23 16:43

Description

The issue

GIVEN [e-mail] set up a forward for [e-mail]
WHEN [e-mail] sends a mail to [e-mail]
MAIL FROM: <[e-mail]>
RCPT TO: <[e-mail]>
THEN James RRT rewrites the transport envelop as:
MAIL FROM: <[e-mail]>
RCPT TO: <[e-mail]>
AND would attempt the delivery to the remote server with such a transport envelop

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...

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 :

MAIL FROM: <[e-mail]>
RCPT TO: <[e-mail]>

Then we would comply with the SPF / DKIM policies...

Test cases

Case 1: Simple foward

GIVEN RRT: [e-mail] forwards mails to [e-mail]
WHEN [e-mail] sends a mail to [e-mail]
THEN the transport envelope becomes:
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Case 2: Part of the recipient have fowards

GIVEN RRT: [e-mail] forwards mails to [e-mail]
WHEN [e-mail] sends a mail to [e-mail] and [e-mail]
THEN the transport envelope becomes (2 mails instead of one):
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]
    AND
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Case 3: Several recipient have forwards

GIVEN RRT: [e-mail] forwards mails to [e-mail]
AND RRT: [e-mail] forwards mails to [e-mail]
WHEN [e-mail] sends a mail to [e-mail] and [e-mail]
THEN the transport envelope becomes (2 mails instead of one):
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]
    AND
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Case 4: Chaining forwards

GIVEN RRT: [e-mail] forwards mails to [e-mail]
AND RRT: [e-mail] forwards mails to [e-mail]
WHEN [e-mail] sends a mail to [e-mail]
THEN the transport envelope becomes:
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Case 5: Handling Alias for people having forwards

GIVEN RRT: [e-mail] forwards mails to [e-mail]
AND ALIAS: [e-mail] for [e-mail] 
WHEN [e-mail] sends a mail to [e-mail]
THEN the transport envelope becomes:
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Case 6: handling group registration for people having forwards

GIVEN RRT: [e-mail] forwards mails to [e-mail]
AND [e-mail] is part of [e-mail]
WHEN [e-mail] sends a mail to [e-mail]
THEN the transport envelope becomes:
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Case 7: Handling Alias for forwads target

GIVEN RRT: [e-mail] forwards mails to [e-mail]
AND ALIAS: [e-mail] for [e-mail] 
WHEN [e-mail] sends a mail to [e-mail]
THEN the transport envelope becomes:
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Case 8: handling group registration for forwads target

GIVEN RRT: [e-mail] forwards mails to [e-mail]
AND [e-mail] is part of [e-mail]
WHEN [e-mail] sends a mail to [e-mail]
THEN the transport envelope becomes:
    MAIL FROM: [e-mail]
    RCPT TO: [e-mail]

Also Validate that validRCPTHandler accepts [e-mail] 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)

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...

Checklist

• [ ] Documentation for the new mailet
• [ ] Clear upgrade instructions
• [ ] Sample config is updated

TLDR: good luck!

Issue Links

• links to: GitHub Pull Request #1750