Mailing List Archive

On 2023-04-15, Sebastian Arcus via Exim-users <exim-users@exim.org> wrote:
> On 15/04/2023 13:53, Jeremy Harris via Exim-users wrote:
>> On 15/04/2023 12:53, Sebastian Arcus via Exim-users wrote:
>>> I have a number of Exim servers behind a NAT gateway (actually
>>> connected with vpn's to a cloud vps - but I'm hoping this is not
>>> relevant to this post). I would like the gateway to send incoming port
>>> 25 traffic to the correct Exim server based on SNI in incoming TLS
>>> packets - as different Exim instances serve different email domains.
>>> The setup would look like this:
>>>
>>>                        [Internet]
>>>                            |
>>>                            |
>>>                      (smtp port 25)
>>>                            |
>>>                            v
>>>                            |
>>>                     [Cloud server]
>>>                            |
>>>                            v
>>>                            |
>>>         ----------------------------------------
>>>         |                  |                   |
>>>         |                  |                   |
>>> [Exim server 1]    [Exim server 2]    [Exim server 3]
>>>
>>>
>>> I would have preferred to do this at IP tables level - but apparently
>>> not really possible. It seems the next option would be HAProxy. Has
>>> anyone here used HAProxy or run a setup as above, or know if this is
>>> actually doable? Any suggestions much appreciated.
>>>
>>
>> Exim does talk the inbound-proxy protocol tha HAProxy apparently uses
>> (or can use):
>> https://exim.org/exim-html-current/doc/html/spec_html/ch-proxies.html#SECTproxyInbound
>>
>>
>> I can't really help on other HAProxy facilities or config though.
>>
>> Another option for you would be to use Exim itself as the fanout element
>> at your
>> "cloud server".  It has visibility of the SNI and could use that for
>> routing.
>
> Thank you for the suggestions. I have considered using Exim itself as
> the "proxy" at the front. One thing I have to figure out is SPF in
> relation to Spamassassin. I think I would have to run Spamassassin on
> the "proxy" Exim, as otherwise the IP address of the proxy will be added
> to the headers during the delivery/relay process, and will probably
> break the SPF checks in Spamassassin on the final Exim server in the
> chain - I think?

I think you're right exim supports HAPROXY and in the coming release
XCLIENT but (so far as I know), in both cases, only as an end point
not as an originator.


The solution to this may be ARC where the first exim checks the SPF
and DKIM and adds a header saying if they are good or not.


--
Jasen.
???????? ????? ???????

--
## 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/

On 15/04/2023 21:38, Jeremy Harris via Exim-users wrote:
> On 15/04/2023 13:53, Jeremy Harris via Exim-users wrote:
>>
>> Exim does talk the inbound-proxy protocol tha HAProxy apparently uses (or can use):
>>
>> https://exim.org/exim-html-current/doc/html/spec_html/ch-proxies.html#SECTproxyInbound
>>
>
> Thinking further, this (HAProxy with Proxy-protocol as a frontend for an
> MTA,
> with the HAProxy routing based on SNI) has additional complications.
> Because
> the ESMTP connection has to (for port 25) negotiate TLS using STARTTLS,
> you're
> asking that HAProxy run that part of the ESMTP protocol, so that it can
> see the
> SNI.  It'd have to replay that ESMTP startup down the connection to the
> backend,
> as far as the TLS Client Hello - or be a full ESMTP endpoint.  I don't
> know if
> it's that clever.

I think the question has evolved during this thread, and it's become
obvious that HAProxy is not the best way to go about it. I'm not even
sure why I was looking into the whole SNI stuff - as I'm only planning
to use this solution for SMTP (server to server) - not submission SMTP
(client to server). So all outside servers trying to deliver email would
only be connecting to one MX FQDN for multiple recipient domains - the
FQDN of the front-end machine. So in the end SNI shouldn't even come
into it. Sorry for all the confusion.

--
## 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/

On 16/04/2023 11:44, Jeremy Harris via Exim-users wrote:
> On 15/04/2023 23:31, Sebastian Arcus via Exim-users wrote:
>>>  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
>
> No.  A Received: header is always added, cutthrough or store-and-forward.
>
>> (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)
>
> (The original) SA presumably relies on Received: headers to get the
> sending IP; there's
> no setting in the API being used to call it.

One thing I have to try and figure out is how Spamassassin does the SPF
checks. Does it look at all the Received: headers, and if at least one
of them matches one of the SPF records, then it's all fine? Because if
that's how it works, SA checks should pass even if done on the back-end
Exim server.

>
> The RSPAMD variant call does, however - so if there were enough call for it
> a feature could be added to Exim to set that from the config; that in turn
> could use on the backend Exim info added to the message by private
> agreement with the
> frontend (eg. an A-R header).
>
> OR:
> you could use the SA feadture "ignore_received_spf_header", do the SPF
> checks on the
> frontend, and add that header to transfer the info
>
> you could use the rspamd feature
> https://www.rspamd.com/doc/modules/external_relay.html
>
> OR:
> you could just run SA on the frontend
>

--
## 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/

On 15/04/2023 23:16, Fabio Martins wrote:
> solution inline
>
> On 2023-04-15 17:05, Sebastian Arcus via Exim-users wrote:
>> On 15/04/2023 17:00, Fabio Martins wrote:
>>> I believe you are trying to use the same IP address for the 3 exim
>>> instances, otherwise the solution would be quite simple binding each
>>> instance to the proper IP address. Right? Or do you have 3 different
>>> public IP addresses?
>>
>> That's correct - there is only one IP address on the VPS/proxy - which
>> needs to serve all the Exim servers behind
>>
>
> Ok, so solution will work.
>
>>>
>>> If you have only 1 public IP, does a solution forwarding to a
>>> subdomain via system_aliases+dsearch+local_parts+cron job updating
>>> user list, would satisfy?
>>>
>>> example:
>>>
>>> adam@company1.com -> adam@internal.company1.com
>>> eve@company1.com -> eve@internal.company1.com
>>> keyser@business2.com -> keyser@internal.business2.com
>>> soze@designer3.com -> soze@internal.designer3.com
>>> contact@designer3.com -> contact@internal.designer3.com
>>
>> I can't say that I am really following what you are trying to suggest
>> - but I don't think having emails on subdomains would help with my
>> problem
>>
>>
>
> The subdomain trick is just a way to reach the right Exim box.
>
> Cloud Box configuration:
>
> box1 VPN IP: bind it to IP 172.20.10.1
> box2 VPN IP: bind it to IP 172.20.10.2
> box3 VPN IP: bind it to IP 172.20.10.3
>
> VPN configuration for each client ( adjust IP addresses for your
> configuration ):
>
> Box1 will bind to port 25 on VPN IP 172.20.10.1
> Box2 will bind to port 25 on VPN IP 172.20.10.2
> Box3 will bind to port 25 on VPN IP 172.20.10.3
>
> internal DNS configuration of cloud box ( unbound shall do the trick ):
>
> internal.company1.com MX points to 172.20.10.1
> internal.business2.com MX points tp 172.20.10.2
> internal.designer3.com MX points to 172.20.10.3
>
> --
>
> Exim configuration of Cloud Box:
>
> # mkdir /etc/exim/domainlistbusiness/
> # echo 'adam: adam@internal.company1.com' >>
> /etc/exim/domainlistbusiness/company1.com
> # echo 'eve: eve@internal.company1.com' >>
> /etc/exim/domainlistbusiness/company1.com
> # echo 'keyser: keyser@internal.business2.com' >>
> /etc/exim/domainlistbusiness/business2.com
> # echo 'soze: soze@internal.designer3.com' >>
> /etc/exim/domainlistbusiness/designer3.com
> # echo 'contact: contact@internal.designer3.com' >>
> /etc/exim/domainlistbusiness/designer3.com
>
> # /etc/exim/exim4.conf ( or proper filename in your box ) (only relevant
> lines):
>
> domainlist local_domains =
> company1.com:business2.com:designer3.com:internal.company1.com:internal.business2.com:internal.designer3.com
>
>
> system_aliases:
>   driver = redirect
>   allow_fail
>   allow_defer
>   domains = dsearch,ret=full;//etc/exim/domainlistbusiness
>   local_parts = lsearch;$domain_data
>
>   data = ${lookup{$local_part}lsearch*@{${domain_data}}}
>   file_transport = address_file
>   pipe_transport = address_pipe
>
> --
>
> Exim configuration of VPN Exim Box1 from company1.com ( only relevant
> lines ):
>
> primary_hostname = company1.com
> domainlist local_domains = company1.com:internal.company1.com
>
> ( other VPN boxes you can deduct from above )
>
> --
>
> This dirty / quick trick shall work ok, and its not a complicated setup.

That still seems like quite a complex setup. I was thinking of just
using the Exim routers in the front end machine to choose the correct
back-end machine to forward the email to. Something like:

relay_to_compan1:
driver = manualroute
domains = company1.com
route_list = company1.com 192.168.100.10
transport = remote_relay_company1
host_find_failed = defer

relay_to_compan2:
driver = manualroute
domains = company2.com
route_list = company2.com 192.168.100.11
transport = remote_relay_company2
host_find_failed = defer

Wouldn't the above just work for incoming email?

--
## 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/

On 16/04/2023 11:04, Paul Muster via Exim-users wrote:
> On 15.04.23 21:54, Sebastian Arcus via Exim-users wrote:
>
>> The "back-end" machines are physical machines, on regular
>> ADSL/VDSL/cable/fibre connections at various locations.
>
>> At the moment they send directly to the internet, which requires a
>> static IP and PTR record.
>
>> To solve all of the above issues, I am looking into essentially
>> diverting all the outgoing and incoming smtp traffic of these servers
>> through a single gateway server, which will be a vps/cloud server.
>
> Well, that's off-topic on the Exim-list, but maybe a VPN solution would
> fit better. Put three additional static IPv4 addresses and IPv6 /64 on
> the VPS, build a Wireguard VPN between the VPS and the Exim servers and
> use the VPS as a "proxy" on IP level.

Indeed , that is another option. It would imply purchasing additional IP
addresses for every single back-end machine I want to add to the setup,
and the current VPS provider doesn't not allow that - and then I would
have to move elsewhere, which would further increase costs. But yes, it
should work.

>
> Or move the three Exim servers - as virtual machines - into the
> datacenter where the VPS runs. Running servers on consumer or even cheap
> enterprise access services will not ensure high availability.
>
>
> Regards,
>
> Paul
>

--
## 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/

On 16/04/2023 19:17, Sebastian Arcus via Exim-users wrote:
>
> relay_to_compan1:
>   driver = manualroute
>   domains = company1.com
>   route_list = company1.com 192.168.100.10
>   transport = remote_relay_company1
>   host_find_failed = defer
>
> relay_to_compan2:
>   driver = manualroute
>   domains = company2.com
>   route_list = company2.com 192.168.100.11
>   transport = remote_relay_company2
>   host_find_failed = defer
>
> Wouldn't the above just work for incoming email?

Yes.

And if those transports don't actually need different configs,
you only need one. And then you might consider using multiple
entries in the route_list and only needing one router, too.
--
Cheers,
Jeremy


--
## 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/

On 16/04/2023 20:22, Jeremy Harris via Exim-users wrote:
> On 16/04/2023 19:17, Sebastian Arcus via Exim-users wrote:
>>
>> relay_to_compan1:
>>    driver = manualroute
>>    domains = company1.com
>>    route_list = company1.com 192.168.100.10
>>    transport = remote_relay_company1
>>    host_find_failed = defer
>>
>> relay_to_compan2:
>>    driver = manualroute
>>    domains = company2.com
>>    route_list = company2.com 192.168.100.11
>>    transport = remote_relay_company2
>>    host_find_failed = defer
>>
>> Wouldn't the above just work for incoming email?
>
> Yes.
>
> And if those transports don't actually need different configs,
> you only need one.  And then you might consider using multiple
> entries in the route_list and only needing one router, too.

Excellent - I didn't think about the route_list having multiple entries.
Well - it's a list - it makes sense when you think about it! Thank you
very much.

Thank you everyone who chipped in with suggestions - it sounds like I am
on my way to a suitable solution. I have a little question about the
outgoing side of things - but I will start a new thread as it is quite a
specific issue.

--
## 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/

On Sun, Apr 16, 2023 at 07:11:51PM +0100, Sebastian Arcus via Exim-users wrote:

> One thing I have to try and figure out is how Spamassassin does the
> SPF checks. Does it look at all the Received: headers, and if at
> least one of them matches one of the SPF records, then it's all
> fine? Because if that's how it works, SA checks should pass even if
> done on the back-end Exim server.

I don't think it would work by default. SA has a concept of "trusted"
Received headers (because, of course, in general spammers can and do
forge headers) and by default only the first is trusted, ie. the one
added by the MTA that ultimately called SA. I think there is a way to
tweak the trusted setting, but

- configuration of SA is complex (though not as much as exim, lol)
- I don't know if that would actually change the SPF result.

--
Ian

--
## 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/

c
On 17/04/2023 04:33, Ian Z via Exim-users wrote:
> On Sun, Apr 16, 2023 at 07:11:51PM +0100, Sebastian Arcus via Exim-users wrote:
>
>> One thing I have to try and figure out is how Spamassassin does the
>> SPF checks. Does it look at all the Received: headers, and if at
>> least one of them matches one of the SPF records, then it's all
>> fine? Because if that's how it works, SA checks should pass even if
>> done on the back-end Exim server.
>
> I don't think it would work by default. SA has a concept of "trusted"
> Received headers (because, of course, in general spammers can and do
> forge headers) and by default only the first is trusted, ie. the one
> added by the MTA that ultimately called SA. I think there is a way to
> tweak the trusted setting, but

Thank you very much for that. It would make sense - all Received:
headers before the latest one in the chain could be added by spammers
manually.

I looked it up and it seems that Exim can be told not to add a Received:
header when handling email - by configuring in the corresponding transport:

received_header_text = ""

I'm not entirely happy with the idea of interfering with the record of
message flow - but I guess it remains an option. I might just add a
custom header instead, so that I will know the message has been through
the front-end machine - for diagnostic purposes.

>
> - configuration of SA is complex (though not as much as exim, lol)
> - I don't know if that would actually change the SPF result.

I couldn't agree more. I am permanently scarred emotionally from
installing and configuring SpamAssassin for the first time - and even
after years of working with it I don't feel like I've managed to tame it :-)

--
## 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/

> 17. apr. 2023 kl. 14:44 skrev Sebastian Arcus via Exim-users <exim-users@exim.org>:
>
> I couldn't agree more. I am permanently scarred emotionally from installing and configuring SpamAssassin for the first time - and even after years of working with it I don't feel like I've managed to tame it :-)

Here’s an option.

For each final host, add your proxy to internal_networks in the backends’ SA configurations. That way, you can run SA both on your proxy and on each backend, but when your proxy delivers to a backend, the backend essentially assumes your proxy took care of the filtering because it’s the MX.

—
Jan
--
## 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/

On 18/04/2023 17:45, Jan Ingvoldstad via Exim-users wrote:
>
>
>> 17. apr. 2023 kl. 14:44 skrev Sebastian Arcus via Exim-users <exim-users@exim.org>:
>>
>> I couldn't agree more. I am permanently scarred emotionally from installing and configuring SpamAssassin for the first time - and even after years of working with it I don't feel like I've managed to tame it :-)
>
> Here’s an option.
>
> For each final host, add your proxy to internal_networks in the backends’ SA configurations. That way, you can run SA both on your proxy and on each backend, but when your proxy delivers to a backend, the backend essentially assumes your proxy took care of the filtering because it’s the MX.

Hmm - thank you for that. I didn't know about the internal_networks
option in SA. Sounds like it could be quite useful. Many thanks

--
## 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/