Outbound - Fallback to MX's IPv4 when the MX's IPv6 is bogus #3314
Labels
Comments
This is how I expect outbound to work. What version of Haraka are you running? |
|
Hello @msimerson, On this particular server we are running Kind regards |
3 tasks
msimerson
added a commit
that referenced
this issue
Apr 22, 2024
Fixes #3314 Conceptually, the big changes in this PR do the following: 1. outsource outbound DNS to haraka-net-utils 2. improve outbound logging by using logger in *only* 2 common ways: `logger.info(obj, message)` or `this.loginfo(self, msg...)` 3. In outbound, the control flow is much more linear: - run get_mx hooks - if no plugin offered a MX, get from net_utils.get_mx (which now includes implicit MX) - pass list of MXes to found_mx, which sorts the MXes - net_utils resolves all MX hostnames to IPs (IPv4, IPv6, all at once, for speed) - each MX IP is tried in turn until one succeeds or the list is exhausted 4. Injecting logging functions into classes (Connection, Plugin, HMailItem) is now done via logger.add_log_methods ## Changes: - outbound: minor es6 updates - outbound: logging improvements - was: [-] [core] [outbound] Failed to get socket: Outbound connection error: Error: connect ECONNREFUSED 172.16.16.14:25 - now: [A63B62DF-F...] [outbound] Failed to get socket: connect ECONNREFUSED 172.16.16.14:25 - outbound: remove log prefixes of `[outbound] `, no longer needed - shorter logger syntax: logger.loginfo -> logger.info - logger(connection, plugins, hmail), refactor copying in log functions - logger: don't load outbound (race condition). Instead, set name property - outbound: delete try_deliver_host. Use net_utils to resolve MX hosts to IPs - outbound: remove config setting ipv6_enabled - fix(logger): refactor add_log_methods, don't set extra `loglog*` names - doc(connection): update rfc7001 URL
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
Is your feature request related to a problem? Please describe.
I noticed that when a recipient MX has both IPv6 and IPv4 entries, and that the IPv6 entry is bogus, Haraka doesn't try to connect to the IPv4 address.
Example of bogus MX:
Describe the solution you'd like
For a given MX having both IPv4 and IPv6 entries, first try IPv6 and if it can't connect, fallback to IPv4 before tempfailing and announcing "Tried all MXs"
Describe alternatives you've considered
To avoid the issue I locally overwrote the target MX IP address (through our unbound resolver) to remove the IPv6 entry so the outgoing mail can be delivered.
Additional context
Of course it would be much better that the remote MX admin fix their IPv6 issue, but still, that could be handful to fallback to IPv4 to avoid having to locally patch how the MX resolves.
The text was updated successfully, but these errors were encountered: