[
https://issues.apache.org/jira/browse/JAMES-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-4032.
---------------------------------
Resolution: Fixed
> Improve external forward handling
> ---------------------------------
>
> Key: JAMES-4032
> URL: https://issues.apache.org/jira/browse/JAMES-4032
> Project: James Server
> Issue Type: Improvement
> Components: RRT
> Affects Versions: 3.8.1
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.9.0
>
> Attachments: image-2024-04-26-12-03-58-932.png,
> image-2024-04-26-12-04-10-017.png, image-2024-04-26-12-13-43-910.png,
> image-2024-04-26-12-14-35-358.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Email deliverability is a tricky topic and yesterday I got one more example
> for this...
> (The trick is to de able to improve deliverability while still being secure)
> h3. The issue
> The overall scenario outline is:
> {code:java}
> GIVEN two local users al...@me.org and b...@me.org on a james based
> instalation
> AND al...@external.org on another email supplier
> AND al...@external.org forwards its mail to al...@me.org.
> AND this server preserves and resend as is the SMTP transport envelope
> WHEN b...@me.org sends an email to al...@external.org
> THEN james server rejects the incoming mail from external.org as it requires
> authentication
> to use local addresses in MAIL FROM
> AND a bounce would be generated by external.org for the original sender as
> the email could not be forwarded.
> {code}
> Example of such "external mail providers": orange.fr SFR professional
> services.
> See fwd1.png
> !image-2024-04-26-12-04-10-017.png!
> h3. Why authentication is currently required in such cases
> In order to maximise delivrability, James accepts any email for local users
> on port 25 (spam filtering may be applied as part of the reception chain)
> However a common attack is email spoofing: a remote attacker with not
> whatsoever access sends an email pretending to be a local user. Without
> further checks he could submit email as a local user without being
> authenticated.
> To prevent this behaviour James implements `verifySenderIdentity`
> configuration parameter in smtpServer.xml configuration file. If using a
> local mail from the current behaviour is to actualy mandate authentication.
> Anybody else than the user could thus NOT be using this MAIL FROM.
> This prevents the following schario: fwd2.png
> !image-2024-04-26-12-03-58-932.png!
> However this causes the issue discussed above.
> h3. Related deliverability concerns
> h4. Receiving external forwards orginating from external mail servers
> b...@external1.org sends a mail to al...@external2.org which forwards mails
> as described above to al...@me.org.
> On the last hop james accepts the email as the MAIL FROM (b...@external1.org)
> is a remote one: verifySenderIdentity is not triggered for external senders.
> On the spam filtering side:
> - SPF checks fails (as external2.org did send a mail in external1.org name
> which it is not allowed to do
> - But DKIM tests pass
> - Which should be enough for the spam filtering stack not to flag the
> message too violently...
> This current behaviour is considered lenient enough. White listing could
> further be added for trusted domains if need be.
> h4. Handling correctly forwards emition
> We tackled the very same issue on the emition side: the goal was to improve
> james forwarded email deliverability.
> GIVEN b...@me.org forwards its email to b...@external.org
> WHEN t...@other.org sends a mail to b...@me.org
> THEN me.org would rewrite the MAIL FROM field and use b...@me.org when
> forwarding to b...@external.org
> Thus SPF check passes.
> See https://issues.apache.org/jira/browse/JAMES-3944
> h3. Proposed solution
> We could experiment turning off sender verification hop on MAIL FROM
> Instead we would verify the DKIM signature of the email before spooling it.
> That way:
> - We would have signed legitimate traffic forwarded back to us and would
> accept it
> !image-2024-04-26-12-14-35-358.png!
> - And we would still reject spoofing attempts as an attacker cant craft a
> DKIM signature.
> !image-2024-04-26-12-13-43-910.png!
> GIVEN that dkim signature of outgoing email is not setted up by default this
> behaviour shall be disabled by default.
> h3. Proposed changes
> Implement a VerifySenderIdentity SMTP message hook that:
> GIVEN an unauthenticated sender
> It performs a verification of non relaying (ie all rcpts are local)
> And would verify the DKIM signature of the mail.
> Path to the DKIM public key needs to be provided.
> This shall be contributed as part of the DKIM extention.
> h3. Additional concerns
> Given the Mail Exchange service (MX) and Mail Submission Agent (MSA) being
> collocated - the default james architecture,
> Then a common misconfiguration is not to configure TLS for SMTP and just have
> regular users just try to send mails unauthenticated through SMTP.
> This behaviour is classical from MacOS native client.
> Current `verifySenderIdentity` behavior rejects such misconfigured client
> from the MAIL FROM. Which is convenient. Fail fast:
> - The error is more explicit: AUthentication required
> - No message payload had been transfered.
> Ideally we would like to preserve this behaviour.
> The way to achieve this would be to have a "relaxed" mode to
> verifySenderIdentity instead of "strict" and "disabled"
> This relaxed mode would enforce the current behaviour if it determise the
> other party to be a MX. We can base ourselves on the structure of the EHLO
> sent: is this a valid domain?
> - If the heuristic determines this is a MX we accept the mail that would be
> dkim tested
> - if the heuristic fails, we reject the mail from this step as today as non
> MX clients are misconfigured local users.
> Note that classifying a local user (heuristic false positive) only delay the
> inevitable error: acceptable, and a heuristic false negative is no worse than
> the current issue described.
> The configuration of verifySenderIdentity would then accept the following
> value:
> - true. Unchanged existing option. Verify strictly the sender identity. Same
> as strict.
> - false. Unchanged existing option. Do not verify sender identity at all.
> Same as disabled.
> - strict. Verify strictly the sender identity. Same as true.
> - disabled. Verify strictly the sender identity. Same as false.
> - relaxed. Verify strictly the sender identity if the remote party is
> determined to not be a MX. Same as false. Further checks are required, like
> inspecting DKIM signing, in order to prevent spoofing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
