Closed chibenwa closed 4 months ago
A regular RCPT line with parameters:
RCPT TO:<rcpt@localhost> NOTIFY=SUCCESS,FAILURE,DELAY ORCPT=rfc822;orcpt@localhost
I was able to reproduce this with the following RCPT line:
RCPT TO: <"any> ,= ,= "@ccc.fr>
which did yield:
java.lang.IllegalArgumentException: Multiple entries with same key: ,= and ,=
at com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:378)
at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:372)
at com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:246)
at com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:133)
at com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:95)
at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:572)
at com.google.common.collect.ImmutableMap$Builder.buildOrThrow(ImmutableMap.java:600)
at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:587)
at org.apache.james.protocols.smtp.core.RcptCmdHandler.parseParameters(RcptCmdHandler.java:230)
at org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:219)
at org.apache.james.protocols.smtp.core.RcptCmdHandler.callHook(RcptCmdHandler.java:55)
at org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.processHooks(AbstractHookableCmdHandler.java:117)
at org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:75)
at org.apache.james.protocols.smtp.core.AbstractHookableCmdHandler.onCommand(AbstractHookableCmdHandler.java:50)
at org.apache.james.protocols.api.handler.CommandDispatcher.dispatchCommandHandlers(CommandDispatcher.java:165)
As it turns out, there is a parser differential between RcptCmdHandler::doFilterChecks and RcptCmdHandler::callHook which interprets things in the mail address as parameters (obviously wrong).
Double parsing BTW looks useless in addition of being dangerous and can likely be avoided.
(And yes, investigating a bit was definitively worth it!)
No idea what the line looks like, looks like syntactically invalid. Better investigate a bit?