On 21/05/22 19:09, Jeremy Hansen wrote:
Two MTAs, one is running Ciphermail. The ciphermail host relays mail
to the “permanent home” MTA where mail gets delivered to users and
dovecot runs for retrieval of mail. The hosts are internal only
hosts. SSH port forwarding is being used to basically export port 25
from the Ciphermail host to an externally accessible AWS node. I
guess the idea is if the instance gets compromised, they’re not
actually on the real MTA. This, again, is where I’m saying “don’t do
that” isn’t really in my control and I’d like to just make this work
without trying to alter the overall design.
Hi Jeremy.
Ironically, it looks like the act of 'securing' your MTA by using SSH
tunnelling has actually turned it into an open relay.
This is because the SSH tunnel proxies the connection at the TCP layer,
meaning that from your MTA's perspective, the (internet-originating)
SMTP connections appear to come from the loopback address. This is shown
in the first line of the Ciphermail log:
May 20 23:16:33 cmx01.la1.blah.com postfix/smtpd[285694]: connect from
localhost[127.0.0.1]
Your Ciphermail configuration defines mynetworks as follows:
mynetworks = 127.0.0.0/8, [::1]/128, ${djigzo_mynetworks}
And so when you specify "permit_mynetworks" in
smtpd_/mumble/_restrictions, you are allowing all internet-originating
connections to bypass /all/ of your security checks:
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_relay_restrictions = ${{$compatibility_level} < {1} ? {} :
{*permit_mynetworks*, permit_sasl_authenticated, defer_unauth_destination}}
smtpd_recipient_restrictions =*permit_mynetworks* reject_unauth_destination
${djigzo_rbl_clients} ${djigzo_reject_unverified_recipient?
reject_unverified_recipient}
smtpd_data_restrictions =
smtpd_end_of_data_restrictions =
Sorry, but my only suggestion is "don't do that"! :-(
Nick.
