Hi Folks,
circling back to this:
Turns out XCLIENT didn't work for my needs. The backend MTA feature I was after to was to check that authenticated username is present in the From: header. Since XCLIENT does not do an actual auth, it did not fit the purpose.
Solution turned out to be pretty easy, as are most things after you figure them out.
I am running a separate instance of dovecot for each submission port, 587 and 465. In each of the instance config files, I removed the userdb and passdb stanzas and replaced them with a single passdb stanza as documented in auth-static.conf.ext found in the example-config directory in the doc folder. This causes the authentication to happen on the backend MTA.
I am not sure if it was working before, but it seems now that the login_trusted_networks is not passing the IP address through the dovecot submission services to the backend MTA. Piping logfiles from dovecot and the MTA into sort works around that issue, though, so I will make a separate post if and when required.
On 2023-05-25 08:28, Aki Tuomi wrote:
On 25/05/2023 02:01 EEST Computerisms Corporation bob@computerisms.ca wrote:
Hi Dovecot Gurus,
I have been playing around with the submission service. I have managed to get all the things working that I want working with two exceptions. I have not found (or possibly I have overlooked) solutions in the documentation or discussions on the 'net.
First; I would like to be able to authenticate against my backend MTA using the user-supplied credentials. I have tried setting submission_relay_user as %u and submission_relay_password as %w, but these seem to be passed through as literal strings, and of course my backend MTA has no idea who %u is.
I found a post from 2019 that indicates passing the submission_relay_user/password to the backend is not a supported function, but hoping that maybe that is outdated info.
I also found:
https://doc.dovecot.org/3.0/configuration_manual/authentication/proxies/
Which seems to indicate it could pass credentials to a non-Dovecot MTA backend, but I am not really clear from the docs on how to set that up, and I did not find any relevant examples to work from. Seems like it would be setting up a Director service, maybe? I have done that before and I do manage multiple email servers, but none of them is clustered or configured to be interoperable, so not sure if this is a viable approach.
Second; I am wondering about the possibility of having multiple submission_relay_host entries. For example if I have dovecot submission services running on my standard port 587 and 465 connect to a relay on the same box through localhost, but could I have another submission service running on another port, say 5587, and relay all traffic received on that port through a completely different host?
I am thinking I could set that up by running a separate instance of dovecot for just that service, but maybe there is a more suitable way? I don't have a solid use-case for this in mind at the moment, but given that I do manage multiple email servers, I am thinking that if this is possible it might provide some useful corner-case configurations down the road.
Thank you for reading my post, any thoughts, information, or pointers to relevant documentation would be most appreciated.
-- Bob Miller 867-334-7117 www.computerisms.ca
Hi!
Which version of Dovecot are you running? The /3.0/ documentation is for unreleased version of Dovecot.
Also, since you are already authenticating the user on the submission service, why not use submission xclient to pass the user etc. information to the backend MTA instead of re-authenticating the user?
Aki