[
https://issues.apache.org/jira/browse/JAMES-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3944:
----------------------------------
Description:
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!
was:
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!
> 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
>
> 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]
