[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] [Commented] (JAMES-3944) RRT: forward features and outgoing emails
From:       "Benoit Tellier (Jira)" <server-dev () james ! apache ! org>
Date:       2023-10-27 6:46:00
Message-ID: JIRA.13553099.1696580796000.183912.1698389160051 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/JAMES-3944?page=com.atlassian.jira.plugin. \
system.issuetabpanels:comment-tabpanel&focusedCommentId=17780188#comment-17780188 ] 

Benoit Tellier commented on JAMES-3944:
---------------------------------------

Note: cloning the email means that loops cannot be simply handled within RRTs.

**Why**

The forward loop occurs when user A forward the email to user B, user B forward the \
email to user C, user C forward email to user A and this happen forever.

**How**

Potential solution: set an attribute in the email to store all forwarded users. Use \
this list to check if a specific user has been forwarded or not

**Integration test cases**

-  User A setup filter forward to user B. User B setup filter forward to user C. User \
C setup filter forward to user A. Send an email to user A, user C should not send the \
                email to user A.
-  User A setup regular forward (RRT) to user B. User B setup regular forward to user \
C. User C setup regular forward to user A. Send an email to user A, user C should not \
                send the email to user A.
-  User A setup filter forward to user B. User B setup regular forward to user C. \
User C setup filter forward to user A. Send an email to user A, user C should not \
send the email to user A.

> 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 bob@my-domain.tld set up a forward for alice@external-domain.tld
> WHEN cedric@another-external-domain.tld sends a mail to bob@my-domain.tld
> MAIL FROM: <cedric@another-external-domain.tld>
> RCPT TO: <bob@my-domain.tld>
> THEN James RRT rewrites the transport envelop as:
> MAIL FROM: <cedric@another-external-domain.tld>
> RCPT TO: <alice@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: <bob@my-domain.tld>
> RCPT TO: <alice@external-domain.tld>
> {code}
> Then we would comply with the SPF / DKIM policies...
> h3. Test cases
> Case 1: Simple foward
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to alice@mydomain.tld
> WHEN cedric@mydomain.tld sends a mail to bob@mydomain.tld
> THEN the transport envelope becomes:
> MAIL FROM: bob@mydomain.tld
> RCPT TO: alice@mydomain.tld
> {code}
> Case 2: Part of the recipient have fowards
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to alice@mydomain.tld
> WHEN cedric@mydomain.tld sends a mail to bob@mydomain.tld and delphine@mydomain.tld
> THEN the transport envelope becomes (2 mails instead of one):
> MAIL FROM: bob@mydomain.tld
> RCPT TO: alice@mydomain.tld
> AND
> MAIL FROM: cedric@mydomain.tld
> RCPT TO: delphine@mydomain.tld
> {code}
> Case 3: Several recipient have forwards
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to alice@mydomain.tld
> AND RRT: delphine@mydomain.tld forwards mails to edgard@mydomain.tld
> WHEN cedric@mydomain.tld sends a mail to bob@mydomain.tld and delphine@mydomain.tld
> THEN the transport envelope becomes (2 mails instead of one):
> MAIL FROM: bob@mydomain.tld
> RCPT TO: alice@mydomain.tld
> AND
> MAIL FROM: delphine@mydomain.tld
> RCPT TO: edgard@mydomain.tld
> {code}
> Case 4: Chaining forwards
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to alice@mydomain.tld
> AND RRT: alice@mydomain.tld forwards mails to edgard@mydomain.tld
> WHEN cedric@mydomain.tld sends a mail to bob@mydomain.tld
> THEN the transport envelope becomes:
> MAIL FROM: alice@mydomain.tld
> RCPT TO: edgard@mydomain.tld
> {code}
> Case 5: Handling Alias for people having forwards
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to alice@mydomain.tld
> AND ALIAS: bob-alias@mydomain.tld for bob@mydomain.tld 
> WHEN cedric@mydomain.tld sends a mail to bob-alias@mydomain.tld
> THEN the transport envelope becomes:
> MAIL FROM: bob@mydomain.tld
> RCPT TO: alice@mydomain.tld
> {code}
> Case 6: handling group registration for people having forwards
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to alice@mydomain.tld
> AND bob@mydomain.tld is part of group@mydomain.tld
> WHEN cedric@mydomain.tld sends a mail to group@mydomain.tld
> THEN the transport envelope becomes:
> MAIL FROM: bob@mydomain.tld
> RCPT TO: alice@mydomain.tld
> {code}
> Case 7: Handling Alias for forwads target
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to alice-alias@mydomain.tld
> AND ALIAS: alice-alias@mydomain.tld for alice@mydomain.tld 
> WHEN cedric@mydomain.tld sends a mail to bob@mydomain.tld
> THEN the transport envelope becomes:
> MAIL FROM: bob@mydomain.tld
> RCPT TO: alice@mydomain.tld
> {code}
> Case 8: handling group registration for forwads target
> {code:java}
> GIVEN RRT: bob@mydomain.tld forwards mails to group@mydomain.tld
> AND alice@mydomain.tld is part of group@mydomain.tld
> WHEN cedric@mydomain.tld sends a mail to bob@mydomain.tld
> THEN the transport envelope becomes:
> MAIL FROM: bob@mydomain.tld
> RCPT TO: alice@mydomain.tld
> {code}
> Also Validate that validRCPTHandler accepts bob@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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]