[
https://issues.apache.org/jira/browse/JAMES-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3944.
---------------------------------
Resolution: Fixed
> 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
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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}
> Case 7: Handling Alias for forwads target
> {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 8: handling group registration for forwads target
> {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]
