[
https://issues.apache.org/jira/browse/JAMES-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18057633#comment-18057633
]
Jean Helou commented on JAMES-4171:
-----------------------------------
>> Interesting, it means that the default configuration results in DSN sent by
>> james for unauthenticated users.
>No
> Currently we mixes MX + Submission role
> [email protected] is able to send an email to [email protected] using
> submission port.
Ok I think I understand where you are coming from
You are saying that because of [rfc6409#section-3.1|
https://www.rfc-editor.org/rfc/rfc6409#section-3.1] all authentication should
be refused on port 587 since this port number is explicitly reserved for
submission only. This makes it weird to add a parameter to the
{code}<auth>{code} section since that section applies to all port numbers but I
understand how it's easier to implement.
If we wanted to properly align with the RFC we would need to differentiate
relay/mixed-use ports from submission ports (since they are RFC specified) and
have different default behaviors as well as preventing incorrect configuration
>> By sane behavior by default I mean reject non-authenticated users trying to
>> relay to non local recipients at the SMTP layer.
>This is already the case.
>From your earlier comment it is the case but it results in a james generated
>DSN.
At the moment the sane version of the mixed behavior you speak of is enforced
by a properly configured mailetcontainer ( either that or that configuration in
the mailet container is useless).
The mailet container checks whether the user is authenticated or not, then
whether the recipient is local or not and decides if relaying is denied (cf my
initial configuration quote).
When I proposed to enforce the ban on all unauthenticated traffic in the
mailetcontainer you answered that when handled by the mailet container it would
result in a james generated DSN. So I don't see why the relay denying process
would not result in a DSN ...
what am I missing ? if the unauthenticated relaying is caught earlier should we
not plug your usecase there (and probably cleanup the mailetcontainer config )
If I'm not missing anything I could connect to someone´s james MX instance on
port 25, and try asking it to relay a mail from [email protected] to
[email protected] ? this would result in the MX instance accepting my message
then generating a DSN to [email protected] which could be a great way to make a
host kill its own sender reputation
so we probably need to address this in the SMTP layer too
> Submission only server
> ----------------------
>
> Key: JAMES-4171
> URL: https://issues.apache.org/jira/browse/JAMES-4171
> Project: James Server
> Issue Type: Improvement
> Components: SMTPServer
> Reporter: Benoit Tellier
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h3. Context
> I end up having to provide a submission only server for one of my customer.
> Problem: James bundles together the MX and submission role thus always accept
> email of remote users addressed to local users.
> This unorthodox behaviour is not a problem when combining both roles (though
> surprising!) however not being able to say "only authenticated users here"
> prevents implementing the aformentionned use case
> h3. Proposal
> Add auth.required configuration option in SMTP
> If true, then discard unauthenticated senders.
> This shall be the documented + recommended value however for
> retro-compatibility I propose to keep the legacy value as a default value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
