On 15/04/2023 23:19, Andrew C Aitchison wrote:
On Sat, 15 Apr 2023, Sebastian Arcus via Exim-users wrote:
On 15/04/2023 21:20, Evgeniy Berdnikov via Exim-users wrote:
On Sat, Apr 15, 2023 at 08:44:08PM +0100, Sebastian Arcus via
Exim-users wrote:
These are all separate servers belonging to different organisations.
They
each host their own mail domain and users. This can't be changed. I
am not
looking to do load balancing. I am looking to share the public IP
address
and PTR record these servers use for incoming and outgoing smtp
connections.
This formulation is significantly different from the original one,
which
was about SNI and all that. This task has no relation to SNI, TLS,
etc.
With wrong questions you have minimal chances to get relevant answers.
You are correct - thinking some more about it, all outside connections
would be connecting to the same FQDN. SNI would play no part in it.
Sorry for the confusion. It seems that using Exim as a front end
relaying to back-end servers seems to be the right solution.
I see this front-end machine as a backup MX server. That way the real
machines will get the mail most of the time, but if/when the real
machine has a new ip address that doesn't match the MX, the front-end
machine will
receive the mail and pass it on to the corrected IP.
That is not such a bad idea actually. One thing I'm not sure about is
the SPF checks in Spamassassin. For email coming through the front-end
machine, there should be no Spamassassin checks done on the back-end
machine, as they would fail the SPF checks. However, when email comes
directly to the back-end machines, Spamassasin should be run on the
email. Maybe I could have some conditions in the ACL to detect how the
email arrived and skip Spamassassin checks on email which came through
the front-end machine.
BTW, using single public IP/gateway you create a single point of
failure
for all domains/organizations.
That is also very true, and I have considered it. On balancing the
advantages and disadvantages of the setup, it will be a risk I will
have to accept. Or possibly end up with two of these cloud / front-end
servers setup as the 2 MX's for all domains.
If the real server and the front-end machine are both in the MX records,
provided that you still control the IP addresses, losing either machine
wont stop the mail from getting through.
That could work as well. I suppose Exim could queue the email if it
can't contact the back-end server, until it comes back online. Another
good idea - thank you.
I don't know what sort of latency there will be between these machines,
but you might be able to use cutthrough delivery from the front-end to the
real server, which might allow you to reject rather than bounce some of
the time; it might even help with your SPF dilemma ?
That was my intention - so that the back-end machines can verify if the
recipient exists. Are you saying that when using cutthrough delivery,
this doesn't add an extra header to the email message - so this way it
wouldn't mess up the SPF checks on the back-end machine? (I was assuming
that the front-end machine would add another header to the incoming
email, which would make it appear to be one of the sending servers -
which I then assumed would fail the SPF checks on the back-end machines)
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
