https://bugs.exim.org/show_bug.cgi?id=1141
--- Comment #23 from Dave <exim-cc0@???> ---
(In reply to Jeremy Harris from comment #22)
> Please describe the full sequence of operations leading to your problem.
Okay, to start at the beginning, I'm employing an exim config that varies the
hostname on source IP,
outgoing mails are configured to emerge from the same host IP they were
received on.
The below aren't the hostnames or IP addresses in use, this is to just give the
general idea.
It will unfortunately take some time to set up a test config suitable for
demonstrating the issue in isolation:
primary_hostname = smtp.riker.local
local_interfaces = 0.0.0.0
smtp_active_hostname =
${lookup{$received_ip_address}iplsearch{ip-to-host}{$value}{$primary_hostname}}
# (other config to masquerade as given hostname, eg TLS keys/certs,
$smtp_active_hostname in received_header_text etc)
transports:
...
remote_smtp:
driver = smtp
interface = ${lookup{$smtp_active_hostname}lsearch{host-to-ip}{$value}}
multi_domain = false
...
The two lists represent one to one maps, the primary hostname is contained in
the list. There are no unrepresented values.
ip-to-host:
127.0.0.1: smtp.riker.local
127.0.0.2: smtp.picard.local
127.0.0.3: smtp.troi.local
host-to-ip:
smtp.riker.local: 127.0.0.1
smtp.picard.local: 127.0.0.2
smtp.troi.local: 127.0.0.3
Now, the problem is that an outgoing message was seen emerging from a source
interface it "shouldn't have been able to", and indeed appears to be impossible
given the above config.
Note that the interface that was used wasn't the primary hostname, so fallback
cannot be used to explain the behaviour. There were no rewrites or new messages
generated by routers.
The ephemeral port used by the interface (it's low, modified ephemeral range)
matched an immediately preceding outgoing mail to the same destination in the
logs, so the presumption is that exim erroneously reused the same transport
connection where the source interface should have varied.
This then naturally lead to SPF failure, as SPF record for the sender is
limited to the IP it is expected to send from (verified correct).
Also note multi_domain should be false, which also appears to be erroneous
reuse:
Heavily redacted example from logs (and source IPs search/replaced to fit with
example above). Note that the message from j@??? reuses the transport
connection to gmail just used by the mail from m@???, when the source
interface is expected to be 127.0.0.1, not 127.0.0.2:
2024-07-02 xx:xx:27 xxxxxx-xxxxxxxxxxx-3fjd <= j@??? H=(XXXXXXXX) [X.X.X.X]
I=[127.0.0.1]:25 P=esmtpa A=fixed_login:auth="j@???" domain=a.com
user=a.com_j S=81732 id=XXXXXXXXXXXX@??? T="Redacted Subject" from <j@???>
for a@???
2024-07-02 xx:xx:36 yyyyyy-yyyyyyyyyyy-2liX <= m@??? H=XXXXXXXX.net
(smtpclient.apple) [X.X.X.X] I=[127.0.0.2]:25 P=esmtpsa
X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no A=fixed_plain:auth="m@???"
domain=b.net user=b.net_m S=343596 id=XXXXXXXXXXXX@??? T="Redacted Subject"
from <m@???> for c@??? h@???
2024-07-02 xx:xx:36 yyyyyy-yyyyyyyyyyy-2liX => c@??? F=<m@???>
R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [64.233.184.27]:25
I=[127.0.0.2]:9305 TFO X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes K C="250
2.0.0 OK XXXXXXXXXXXX.193 - gsmtp"
2024-07-02 xx:xx:37 xxxxxx-xxxxxxxxxxx-3fjd ** a@??? F=<j@???>
R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [64.233.184.27]:25*
I=[127.0.0.2]:9305 X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no: SMTP error from
remote mail server after end of data: 550-5.7.26 Your email has been blocked
because the sender is unauthenticated.\n550-5.7.26 Gmail requires all senders
to authenticate with either SPF or DKIM.\n550-5.7.26\n550-5.7.26
Authentication results:\n550-5.7.26 DKIM = did not pass\n550-5.7.26 SPF
[a.com] with ip: [X.X.X.X] = did not pass\n550-5.7.26\n550-5.7.26 For
instructions on setting up authentication, go to\n550 5.7.26
https://support.google.com/mail/answer/81126#authentication XXXXXXXXXXXX.193 -
gsmtp
2024-07-02 xx:xx:37 zzzzzz-zzzzzzzzzzz-2yBW <= <> R=xxxxxx-xxxxxxxxxxx-3fjd
U=exim P=local S=3498 T="Mail delivery failed: returning message to sender"
from <> for j@???
2024-07-02 xx:xx:37 xxxxxx-xxxxxxxxxxx-3fjd Completed QT=10s
2024-07-02 xx:xx:40 yyyyyy-yyyyyyyyyyy-2liX => h@??? F=<m@???>
R=dnslookup T=remote_smtp H=outlook-com.olc.protection.outlook.com
[52.101.11.6]:25 I=[127.0.0.2]:43763 X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=yes
K C="250 2.6.0 <XXXXXXXXXXXX@???> [InternalId=XXXXXXXX,
Hostname=XXXXXXXX.eurprd08.prod.outlook.com] 355747 bytes in 0.468, 740.902
KB/sec Queued mail for delivery"
2024-07-02 xx:xx:40 yyyyyy-yyyyyyyyyyy-2liX Completed QT=4s
This is an infrequent occurence, even at relatively high throughput, DKIM
wasn't used here, and likely masks many potential failures.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
