First commit #31

agrinchenko · 2025-10-07T19:35:02Z

Draft for ARC-sealing for review/comments/feedback. Work in progress.

arc/src/main/java/org/apache/james/arc/ArcSealVerifyData.java

chibenwa

This work is wonderful, thanks for putting it together.

I have mostly nits and checkstyles.

However I do believe we need to invest in significant testing with at least a dozen messages and ensure a good overall test coverage,

also while dmarc makes sense as part of arc, but it also makes sense of its own. How about extracting DMARC tooling (record parsing & evaluation) in a standalong dmarc maven module we could depend on?

arc/src/main/java/org/apache/james/arc/ArcSealVerifyData.java

arc/src/main/java/org/apache/james/arc/ARCChainValidator.java

arc/src/main/java/org/apache/james/arc/DNSPublicKeyRecordRetrieverArc.java

arc/src/main/java/org/apache/james/arc/PublicKeyRetrieverArc.java

arc/pom.xml

agrinchenko · 2025-10-08T02:46:40Z

Thanks all for taking time to review and providing your feedback! Keep it coming! I will work on improving the code in the coming days.

arc/src/main/java/org/apache/james/arc/ARCSigner.java

jeantil · 2025-10-08T08:57:39Z

I hope I can convince you not to follow the existing DKIM api which is really not so great. please have a look at the proposed API in #27
if we are going to introduce a completely new feature set we should strive to improve the design

I'm not saying my proposed API design is perfect (by no means) but it should be better than what we have today

arc/src/main/java/org/apache/james/arc/AuthResultsBuilder.java

Co-authored-by: Benoit TELLIER <btellier@linagora.com>

agrinchenko · 2025-10-09T01:48:44Z

This work is wonderful, thanks for putting it together.

I have mostly nits and checkstyles.

However I do believe we need to invest in significant testing with at least a dozen messages and ensure a good overall test coverage,

also while dmarc makes sense as part of arc, but it also makes sense of its own. How about extracting DMARC tooling (record parsing & evaluation) in a standalong dmarc maven module we could depend on?

Thanks for the kind comments, Benoit!

100% agree on need in broad testing covering all possible edge cases that I might have missed. I wish Appendix B in RFC 8617 had more examples as well as signing/public key pairs used in them.

Let me think on making a module out of dmarc. My first instinct says it will probably be a very small module. But if it makes sense to keep is separate, we can make it happen.

…dback - Introduced ArcValidationResult enum - Made ArcSealVerifyData immutable pojo - Removed dependency on geronimo.javamail - Removed dependency on Freemarker and simplified ARC templates - Updated versions in pom to pull them from the parent pom - Fixed missing licensing headers - Applied suggested style fixes

agrinchenko · 2025-10-09T01:54:23Z

I hope I can convince you not to follow the existing DKIM api which is really not so great. please have a look at the proposed API in #27 if we are going to introduce a completely new feature set we should strive to improve the design

I'm not saying my proposed API design is perfect (by no means) but it should be better than what we have today

Sure, I will take a look at the proposed API and see how we can change it.

agrinchenko · 2025-10-09T02:03:45Z

I checked it a new commit with updates. Outstanding on my list:

look into making a module out of dmarc
check proposed API in RFC - Proposal for an updated JDKIM API #27 and see how we can align with it
investigate DMARC strict vs relaxed. Make sure both are supported.
Let me know if I missed anything.

chibenwa · 2025-10-09T07:49:21Z

Let me think on making a module out of dmarc. My first instinct says it will probably be a very small module. But if it makes sense to keep is separate, we can make it happen.

I'd see a point: discoverability.

Just like OpenDmarc and OpenArc are 2 distict projects.

I wish Appendix B in RFC 8617 had more examples as well as signing/public key pairs used in them.

Maybe we could reach the DMARC work group that published the spec and ask if there is a TCK (Technology COmpliance Kit): dmarc@ietf.org ?

I had a look at OpenARC tests but they are thin.

arc/src/main/java/org/apache/james/arc/ARCSigner.java

epinter · 2025-10-09T13:48:57Z

What method can be used to know if the sealer can be trusted ? I didn't see any in the ARCVerifier.

agrinchenko · 2025-10-09T14:20:29Z

What method can be used to know if the sealer can be trusted ? I didn't see any in the ARCVerifier.

The logic to validate previous ARC sealers is included in the ARCChainValidator class. This is the entry point for it
public ArcValidationResult validateArcChain(Message message). If our instance is between 1 and 50 we go into validatePreviousArcHops where we recompute the hashes on previous AMS and AS headers and check them using sealers' public keys pulled from DNS.

epinter · 2025-10-09T14:31:24Z

What method can be used to know if the sealer can be trusted ? I didn't see any in the ARCVerifier.

The logic to validate previous ARC sealers is included in the ARCChainValidator class. This is the entry point for it public ArcValidationResult validateArcChain(Message message). If our instance is between 1 and 50 we go into validatePreviousArcHops where we recompute the hashes on previous AMS and AS headers and check them using sealers' public keys pulled from DNS.

My usage of ARC was limited, but as far as I know, no ARC sealer can be trusted. I think it was designed to be an opt-in feature. Only accept ARC headers from previously trusted (and configured) servers. Like Microsoft does, you need to configure the sealer there. A sealer can be a malicious actor with a valid signature modifying messages, and your server will deliver an authenticated phishing or spam. These things must be treated with caution. The RFC 8617 is experimental.

From rfc8617#section-7.1: "If ARC-enabled ADMDs are trusted, Authenticated Received Chains can
be used to bridge administrative boundaries."

The section rfc8617#section-9.4 (Message Sealer Suspicion), says sealers must be treated with suspicion.

agrinchenko · 2025-10-09T14:51:18Z

Let me think on making a module out of dmarc. My first instinct says it will probably be a very small module. But if it makes sense to keep is separate, we can make it happen.

I'd see a point: discoverability.

Just like OpenDmarc and OpenArc are 2 distict projects.

I wish Appendix B in RFC 8617 had more examples as well as signing/public key pairs used in them.

Maybe we could reach the DMARC work group that published the spec and ask if there is a TCK (Technology COmpliance Kit): dmarc@ietf.org ?

I had a look at OpenARC tests but they are thin.

Yes, discoverability makes sense. I can move it into it's own module under james-jdkim. A few additional things to consider before we do that:

what about SPF, does it make sense to put it in its own module too? I am not opposed to it and think logically it might make sense if we decide to separate DMARC.
sounds like @epinter is working on DMARC library, so may be it would make more sense to integrate with it?

chibenwa · 2025-10-09T15:52:19Z

what about SPF, does it make sense to put it in its own module too? I am not opposed to it and think logically it might make sense if we decide to separate DMARC.

SPF is already a standalong library of its own. I'll scope it as "let's keep this a dependency of DMARC"

CF what about SPF, does it make sense to put it in its own module too? I am not opposed to it and think logically it might make sense if we decide to separate DMARC.

sounds like @epinter is working on DMARC library, so may be it would make more sense to integrate with it?

If @epinter agrees I think a dmarc library in Java fully deserve to be in the Apache James umbrella.

No objections to depend on it though.

epinter · 2025-10-09T16:32:54Z

what about SPF, does it make sense to put it in its own module too? I am not opposed to it and think logically it might make sense if we decide to separate DMARC.

SPF is already a standalong library of its own. I'll scope it as "let's keep this a dependency of DMARC"

CF what about SPF, does it make sense to put it in its own module too? I am not opposed to it and think logically it might make sense if we decide to separate DMARC.

sounds like @epinter is working on DMARC library, so may be it would make more sense to integrate with it?

If @epinter agrees I think a dmarc library in Java fully deserve to be in the Apache James umbrella.

I agree.

No objections to depend on it though.

I think the development of this PR doesn't need to stop because of dmarc. Now it is just a method call to check alignment, it will be easy to replace with a call to a future library.
I plan a very simple API, something like public DmarcResult verify(String rfc5322domain, Identifier... identifiers).

- Rewired DMARC into separate module - Added relaxed header alignment for DMARC using PSL list - Removed commons-codec dependency

…ld error

… error

…enkins build

agrinchenko · 2025-10-17T22:54:36Z

Hey guys!

I committed changes with DMARC in a separate module and also implemented both strict and relaxed header checking against PSL list.

The Jenkins build fails though because MockPublicKeyRecordRetrieverDmarc test class that is in DMARC module is being used by test classes in the ARC module. It needs to build apache-dmarc-library-0.6-SNAPSHOT-tests.jar first so that ARC tests can find it. Tried changing a few things in POM, and they did not help. Will appreciate any suggestions. Works fine on my local.

…rent pom'

chibenwa · 2025-10-21T16:12:54Z

I have limited bandwith because of over-committing on another project.

I will take time for a complete review of this work this weekend.

agrinchenko · 2025-10-22T13:49:55Z

Thanks, Benoit! No rush..

arc/src/main/java/org/apache/james/arc/ArcValidationResult.java

chibenwa

I do think we could benefit from updating the documentation (src/site ?) for mentionning arc and dkim support + giving some little code examples.

I (tried to) refrain from doing too much code style related comments but I'd be happy, if you accept, to propose you a changeset to polish a bit this work (i'd PR your branch).

arc/src/main/java/org/apache/james/arc/AuthResultsBuilder.java

dmarc/src/main/java/org/apache/james/dmarc/DMARCVerifier.java

arc/src/main/java/org/apache/james/arc/ArcSignatureRecordImpl.java

epinter · 2025-10-26T15:17:58Z

dmarc/src/main/java/org/apache/james/dmarc/PublicSuffixList.java

+
+    private PublicSuffixList() {}
+
+    public static boolean isPublicSuffix(String domain) {


The PSL can't be used just to know if contains a suffix, it's missing exceptions and wildcard. Many valid domains will not be found.

Thanks for the feedback. I will take a closer look at PSL exceptions and wildcards, I think I just learned something new about PSL.

Thanks for the feedback. I will take a closer look at PSL exceptions and wildcards, I think I just learned something new about PSL.

If you need, here is my library:

https://central.sonatype.com/artifact/dev.pinter.psl/publicsuffixlist

Thanks again, for the pointer to your lib! Nice work! I think it does actually more than what I need for the relaxed domain checking. I took another try at rewriting my initial PSL code to add ability to handle wildcards and exceptions. Checked in.

dmarc/src/main/java/org/apache/james/dmarc/PublicSuffixList.java

epinter · 2025-10-26T15:23:22Z

dmarc/src/main/test/java/org/apache/james/dmarc/PublicSuffixListTest.java

+import static org.junit.Assert.assertTrue;
+
+public class PublicSuffixListTest {
+


If a PSL implementation is to be included here, I think a lot more tests will be needed. My implementation has more than 130 tests. A fail in PSL lookup can make invalid dmarc to pass.

Good to know you have PSL implementation with 130 tests already! I would be glad to integrate with your work and delegate the relaxed org domain determination to your code. Let me know! Essentially I would need to be able to supply FQDN and receive either (1) a relaxed version of it (i.e. PSL public suffix + 1 part to the left of it) or (2) same FQDN if nothing is found in PSL.

Nice work you have on PSL! I think your library does more than what I need for the purposes of relaxed domain alignment. As a first step I rewrote initial PSL code I had to handle wildcards and exceptions, also added more test cases.

- Added ARC validation outcome with details on the failure - Refactored logic such as `computeBTag` into separate methods - Added hard fail whenever multiple From headers detected - Rewrote tag extraction logic to do it all in one pass for efficiency - Simplified getTimeMeasure to use standard Java - Removed unnecessary Overrides

First commit

4919e37

chibenwa reviewed Oct 7, 2025

View reviewed changes

arc/src/main/java/org/apache/james/arc/ArcSealVerifyData.java Outdated Show resolved Hide resolved

chibenwa reviewed Oct 7, 2025

View reviewed changes

chibenwa requested a review from jeantil October 7, 2025 21:12

jeantil reviewed Oct 8, 2025

View reviewed changes

arc/src/main/java/org/apache/james/arc/ARCSigner.java Show resolved Hide resolved

epinter reviewed Oct 8, 2025

View reviewed changes

arc/src/main/java/org/apache/james/arc/AuthResultsBuilder.java Outdated Show resolved Hide resolved

agrinchenko and others added 4 commits October 8, 2025 19:23

Update arc/src/main/java/org/apache/james/arc/ArcSealVerifyData.java

8030d6a

Co-authored-by: Benoit TELLIER <btellier@linagora.com>

Update arc/src/main/java/org/apache/james/arc/ARCChainValidator.java

d00de6b

Co-authored-by: Benoit TELLIER <btellier@linagora.com>

Update arc/src/main/java/org/apache/james/arc/ARCChainValidator.java

46fbebb

Co-authored-by: Benoit TELLIER <btellier@linagora.com>

Update arc/src/main/java/org/apache/james/arc/ARCChainValidator.java

f0dab44

Co-authored-by: Benoit TELLIER <btellier@linagora.com>

epinter reviewed Oct 9, 2025

View reviewed changes

arc/src/main/java/org/apache/james/arc/ARCSigner.java Show resolved Hide resolved

agrinchenko added 6 commits October 17, 2025 16:22

Rework DMARK and reduce dependencies

7f152c9

- Rewired DMARC into separate module - Added relaxed header alignment for DMARC using PSL list - Removed commons-codec dependency

Adding DMARC pom.xml that was missing in the previous commit

223644e

Remove maven compiler plugin in DMARC pom.xml causing build to fail

b8ad316

Add to the maven-compiler-plugin in DMARC pom.xml to fix the auto bui…

29b1384

…ld error

Add to the maven-compiler-plugin in ARC pom.xml to fix the auto build…

b598dbf

… error

Updating ARC pom to make sure it can see DMARC test dependencies on J…

2fb59c4

…enkins build

Fixing the Jenkins build. Realigning to JDK 11

795054b

Add missing license info. Reorder 'dmarc' and 'arc' modules in the pa…

50afaf9

…rent pom'

chibenwa reviewed Oct 26, 2025

View reviewed changes

arc/src/main/java/org/apache/james/arc/ArcValidationResult.java Show resolved Hide resolved

chibenwa reviewed Oct 26, 2025

View reviewed changes

epinter reviewed Oct 26, 2025

View reviewed changes

dmarc/src/main/java/org/apache/james/dmarc/PublicSuffixList.java Outdated Show resolved Hide resolved

epinter reviewed Oct 26, 2025

View reviewed changes


		private PublicSuffixList() {}

		public static boolean isPublicSuffix(String domain) {

		import static org.junit.Assert.assertTrue;

		public class PublicSuffixListTest {

First commit #31

Are you sure you want to change the base?

First commit #31

Uh oh!

Conversation

agrinchenko commented Oct 7, 2025

Uh oh!

Uh oh!

chibenwa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

agrinchenko commented Oct 8, 2025

Uh oh!

Uh oh!

jeantil commented Oct 8, 2025

Uh oh!

Uh oh!

agrinchenko commented Oct 9, 2025

Uh oh!

agrinchenko commented Oct 9, 2025

Uh oh!

agrinchenko commented Oct 9, 2025

Uh oh!

chibenwa commented Oct 9, 2025

Uh oh!

Uh oh!

epinter commented Oct 9, 2025

Uh oh!

agrinchenko commented Oct 9, 2025

Uh oh!

epinter commented Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

agrinchenko commented Oct 9, 2025

Uh oh!

chibenwa commented Oct 9, 2025

Uh oh!

epinter commented Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

agrinchenko commented Oct 17, 2025

Uh oh!

chibenwa commented Oct 21, 2025

Uh oh!

agrinchenko commented Oct 22, 2025

Uh oh!

Uh oh!

chibenwa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

epinter Oct 26, 2025

Choose a reason for hiding this comment

Uh oh!

agrinchenko Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

epinter Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

agrinchenko Nov 4, 2025

Choose a reason for hiding this comment

Uh oh!

epinter commented Oct 9, 2025 •

edited

Loading

epinter commented Oct 9, 2025 •

edited

Loading