https://bugs.exim.org/show_bug.cgi?id=1141
--- Comment #23 from Dave <[email protected]> --- (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 [email protected] reuses the transport connection to gmail just used by the mail from [email protected], 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 <= [email protected] H=(XXXXXXXX) [X.X.X.X] I=[127.0.0.1]:25 P=esmtpa A=fixed_login:auth="[email protected]" domain=a.com user=a.com_j S=81732 [email protected] T="Redacted Subject" from <[email protected]> for [email protected] 2024-07-02 xx:xx:36 yyyyyy-yyyyyyyyyyy-2liX <= [email protected] 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="[email protected]" domain=b.net user=b.net_m S=343596 [email protected] T="Redacted Subject" from <[email protected]> for [email protected] [email protected] 2024-07-02 xx:xx:36 yyyyyy-yyyyyyyyyyy-2liX => [email protected] F=<[email protected]> 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 ** [email protected] F=<[email protected]> 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 [email protected] 2024-07-02 xx:xx:37 xxxxxx-xxxxxxxxxxx-3fjd Completed QT=10s 2024-07-02 xx:xx:40 yyyyyy-yyyyyyyyyyy-2liX => [email protected] F=<[email protected]> 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 <[email protected]> [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): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
