Am 07.09.2011 19:06, schrieb Jeroen Geilman:
On 2011-09-06 13:58, Heiko Wundram wrote:
Am 06.09.2011 13:42, schrieb Noel Jones:
Or use firewall rules to redirect connections from that client to a
different port with different smtpd_sasl_security_options.
Thanks, after an off-list reply suggesting just that I tried that out,
and that works like a charm. Adding the client to mynetworks won't cut
it, as I don't trust the system except for the fact that I can control
the traffic between the system and the smarthost; authentication is a
must so that I can trace whether the host does "bad" things.
You can trace that regardless, since postfix logs what happens.
However, only SMTP AUTH combined with smtpd_sender_login_maps and its
various restrictions allow you to /control/ what happens.
Hooray for the little semantic difference, but I actually meant "trace",
simply because the target machine is not under my control, and as a
terminal server with multiple logins it actually makes a difference
whether I allow all clients using it to relay mail (aka. mynetworks), or
only a specific client after he/she logs in (in this case the client
running the mentioned Java backup software, which sends the mail and for
which I need to enable plaintext auth without TLS, ugh).
As I stated earlier: I trust the network between the client and the
relay, but not the client (or rather, only a "part" of the client, and
I'd like to make sure the relay is conversing with the right "part").
So, trace was actually semantically correct here (in addition to of
course having control, as you said), because with login data given to
the client running the software I can clearly lay the blame in case
something goes wrong, which I couldn't with mynetworks. ;-)
Anyway, a REDIRECT matching the source IP of the client to the
plaintext-allowed Postfix instance running on a different port works fine!
--
--- Heiko.
