[jira] [Commented] (JAMES-4171) Submission only server

    [ 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)