As there was no other feedback regarding this matter, as it seems Benoit
and myself reached a consensus on the first solution, I created a JIRA
ticket accordingly: https://issues.apache.org/jira/browse/JAMES-3579.
Rene.
On 05/05/2021 18:28, Tellier Benoit wrote:
Hello René,
Thanks for raising the topic here.
Le 05/05/2021 à 16:31, Rene Cordier a écrit :
Hello guys,
[...]
1. If authRequired is set to false, we should reject verifyIdenty=true,
as it makes no logical sense. People might need to update their James
running installation though (but easy)
By far my prefered option.
Yes some people need to reconfigure smtpserver.xml but at least we don't
take implicit decisions.
2. If authRequired is set to false, we can silently ignore
verifyIdentity is set to true.
The option that I like the least... It IMO gives a false sense of safety
(you might believe senders are verified but they actually are not).
3. We keep this current behavior, but need to change the documentation
accordingly and add a warning log as well during James startup.
This look fine to me. Verifying senders implies forcing local users to
authenticate (overwise the work-around is too simple...). However from
an admin perspective it would be harder to diagnose some SMTP
transaction being rejected compared to a server not starting.
I personally prefer the first one, as this is the way it's documented
for now and I found it more logical. However, it's completely opened to
discussion (thus the mail).
Depending on the feedback, will create the according JIRA fix ticket.
I think we can reuse JAMES-3525 as it is closely related...
Cheers,
Benoit
Thank you all, have a good day!
Rene.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
