3
Outbound email trying IPv4 addresses before IPv6
Problem reported by Dennis A. - 1/25/2019 at 4:04 AM
Submitted
When sending outbound email with SmarterMail, it looks like SM uses the IPv4 address of the receiving party first, and if that fails, tries the IPv6 address. This can be seen in the following log:

[2019.01.15] 11:20:28.602 [04168] MxRecord count: '1' for domain '<REDACTED>'
[2019.01.15] 11:20:28.618 [04168] Attempting MxRecord Host Name: '<REDACTED>', preference '10', Ip Count: '2'
[2019.01.15] 11:20:28.618 [04168] Attempting to send to MxRecord '<REDACTED>' ip: '195.<REDACTED>'
[2019.01.15] 11:20:28.618 [04168] Sending remote mail to: <REDACTED>
[2019.01.15] 11:20:28.774 [04168] Attempting to send to MxRecord '<REDACTED>' ip: '2001:<REDACTED>'
[2019.01.15] 11:20:28.774 [04168] Sending remote mail to: <REDACTED>
[2019.01.15] 11:25:29.355 [04168] MxRecord count: '1' for domain '<REDACTED>l'
[2019.01.15] 11:25:29.355 [04168] Attempting MxRecord Host Name: '<REDACTED>', preference '10', Ip Count: '2'
[2019.01.15] 11:25:29.355 [04168] Attempting to send to MxRecord '<REDACTED>' ip: '195.<REDACTED>'
[2019.01.15] 11:25:29.355 [04168] Sending remote mail to: <REDACTED>
[2019.01.15] 11:25:29.542 [04168] CMD: RCPT TO:<<REDACTED>> NOTIFY=never
[2019.01.15] 11:25:29.605 [04168] RSP: 250 2.1.5 <<REDACTED>>... Recipient ok
[2019.01.15] 11:25:29.745 [04168] Delivery for <REDACTED> to <REDACTED> has completed (Delivered)

In this case, there was some TLS negotiation issue, because of which SmarterMail tried to fall back to the IPv6 address, so it is capable of connecting over IPv6. But if I look at my regular mail traffic, it seems like all emails are tried over IPv4 first. Look at this example for Gmail:

[2019.01.25] 11:37:26.737 [54858] Delivery started for <REDACTED> at 11:37:26 AM
[2019.01.25] 11:37:29.753 [54858] Added to SpamCheckQueue (0 queued; 1/30 processing)
[2019.01.25] 11:37:29.753 [54858] [SpamCheckQueue] Begin Processing.
[2019.01.25] 11:37:29.753 [54858] Removed from SpamCheckQueue (0 queued or processing)
[2019.01.25] 11:37:32.768 [54858] Added to RemoteDeliveryQueue (1 queued; 0/50 processing)
[2019.01.25] 11:37:32.768 [54858] [RemoteDeliveryQueue] Begin Processing.
[2019.01.25] 11:37:32.768 [54858] Sending remote mail for <REDACTED>
[2019.01.25] 11:37:32.768 [54858] Spam check results:
[2019.01.25] 11:37:32.768 [54858] MxRecord count: '5' for domain 'gmail.com'
[2019.01.25] 11:37:32.768 [54858] Attempting MxRecord Host Name: 'gmail-smtp-in.l.google.com', preference '5', Ip Count: '2'
[2019.01.25] 11:37:32.768 [54858] Attempting to send to MxRecord 'gmail-smtp-in.l.google.com' ip: '74.125.143.27'
[2019.01.25] 11:37:32.768 [54858] Sending remote mail to: <REDACTED>@gmail.com
[2019.01.25] 11:37:32.768 [54858] Initiating connection to 74.125.143.27
[2019.01.25] 11:37:32.768 [54858] Connecting to 74.125.143.27:25 (Id: 1)
[2019.01.25] 11:37:32.768 [54858] Binding to local IP 37.<REDACTED>:0 (Id: 1)
[2019.01.25] 11:37:32.784 [54858] Connection to 74.125.143.27:25 from 37.<REDACTED>:56303 succeeded (Id: 1)

Doing a DNS lookup for gmail-smtp-in.l.google.com shows that the host definitely has an IPv6 address (which I can also ping from the server):
IPv6: 2607:f8b0:400d:c0f::1b
IPv4: 74.125.143.27

So SmarterMail doesn't even try to resolve to an IPv6 address first.

Is it possible to change this behavior? I would expect SM to look at IPv6 first, and if that fails, fallback to IPv4, just like most software/OSes do.

Thanks!
SM version is 6948

Reply to Thread