Re: [exim] Proxy smtp connections to multiple Exim servers b…

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)