Multipop outbound connection IP Address (127.0.... | MDaemon Technologies Community Forum
  1. Forum
  2. MDaemon
  3. Multipop outbound connection IP Address (127.0.0.1)

Multipop outbound connection IP Address (127.0.0.1)

  • S

    Multipop outbound IP address connection uses 127.0.0.1 instead of the assigned bound ip address under IMAP & POP3 

    We've had a similar issue with SMTP (out) connection (see previous post "SMTP (out) communication".  In this case our 127.0.0.1 was changed and bound to our internal clustered ip assigned to Mdameon application.

    So, where in the system can we bind our Multipop connection? 

     

    Multipop Log

    Wed 2023-08-09 08:28:47.683: [00007276] Session 00007276; child 0005
    Wed 2023-08-09 08:28:47.683: [00007276] Attempting MultiPOP connection to secure.emailsrvr.com for t**d@h**.local
    Wed 2023-08-09 08:28:47.683: [00007276] Match to IPCache.dat file:
    Wed 2023-08-09 08:28:47.683: [00007276] *  D=secure.emailsrvr.com TTL=(1) A=[146.20.161.10]
    Wed 2023-08-09 08:28:47.685: [00007276] Waiting for socket connection...
    Wed 2023-08-09 08:28:47.703: [00007276] *  Connection established 127.0.0.1:51900 --> 146.20.161.10:110
    Wed 2023-08-09 08:28:47.703: [00007276] Waiting for protocol to start...
    Wed 2023-08-09 08:28:47.729: [00007276] <-- +OK Server ready proxy19.mail.iad3b.rsapps.net
    Wed 2023-08-09 08:28:47.729: [00007276] --> STLS
    Wed 2023-08-09 08:28:47.753: [00007276] <-- +OK Begin TLS negotiation now.
    Wed 2023-08-09 08:28:47.821: [00007276] SSL negotiation successful (TLS 1.2, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
    Wed 2023-08-09 08:28:47.822: [00007276] SSL certificate is not valid (CRYPT_E_NO_REVOCATION_CHECK)

    0 likes
  • S

    Any update?  So, where in the system can we bind our Multipop connection?

    0 likes
  • J

    Hello Scott,

    It should use the same binding as you would use with SMTP connections.

    When I tested this using my MDaemon 23.0.2 server, I had "This domain recognizes only connections made to these IPs" enabled for my domain with "192.168.1.20" set as the IP address.

    Here is the result of the MultiPOP connection that was made to "192.168.1.30":
    Wed 2023-08-16 17:55:25.734: Session 00004341; child 0001
    Wed 2023-08-16 17:55:25.734: Attempting MultiPOP connection to 192.168.1.30:110 for test@company.test
    Wed 2023-08-16 17:55:25.735: Waiting for socket connection...
    Wed 2023-08-16 17:55:25.743: *  Connection established 192.168.1.20:54741 --> 192.168.1.30:110


    For my next test, I had "This domain recognizes only connections made to these IPs" enabled for my domain with "192.168.1.21" set as the IP address.

    Here is the result of the MultiPOP connection that was made to "192.168.1.30":
    Wed 2023-08-16 17:55:45.750: Session 00004345; child 0001
    Wed 2023-08-16 17:55:45.750: Attempting MultiPOP connection to 192.168.1.30:110 for test@company.test
    Wed 2023-08-16 17:55:45.751: Waiting for socket connection...
    Wed 2023-08-16 17:55:45.753: *  Connection established 192.168.1.21:58499 --> 192.168.1.30:110


    For my last test, I had "This domain recognizes only connections made to these IPs" disabled for my domain with "192.168.1.21" set as the IP address.  In the Outbound Binding Settings, I set "IPv4 Address" to "192.168.1.20".

    Here is the result of the MultiPOP connection that was made to "192.168.1.30":
    Wed 2023-08-16 18:12:43.766: Session 00004352; child 0001
    Wed 2023-08-16 18:12:43.766: Attempting MultiPOP connection to 192.168.1.30:110 for test@company.test
    Wed 2023-08-16 18:12:43.767: Waiting for socket connection...
    Wed 2023-08-16 18:12:43.768: *  Connection established 192.168.1.20:53322 --> 192.168.1.30:110


    Prior to running these tests, I noticed that when I had my domain's IP address set to "192.168.1.20" with "This domain recognizes only connections made to these IPs" enabled, it showed "127.0.0.1" as the IP address used for the outbound connection.

    Here is the result of the MultiPOP connection that was made to "192.168.1.30":
    Wed 2023-08-16 17:49:44.573: 05: Session 00004330; child 0001
    Wed 2023-08-16 17:49:44.573: 05: Attempting MultiPOP connection to 192.168.1.30:110 for test@company.test
    Wed 2023-08-16 17:49:44.574: 05: Waiting for socket connection...
    Wed 2023-08-16 17:49:44.581: 05: *  Connection established 127.0.0.1:52261 --> 192.168.1.30:110

    I ran Wireshark at the time I ran that test, and it showed that the IP address used for the outbound connection was "192.168.1.20".

    I would need to run more tests to determine what the difference was that caused MDaemon to log "127.0.0.1" as the IP address used for the outbound connection.

    If you run that test again with Wireshark performing a capture, even though the log reports "127.0.0.1" as the IP address used for the outbound connection, what IP address does Wireshark show?

    Regards,
    Jared Charles

    0 likes
  • S

    My system is setup to only accept connections to our virtual ip address (192.168.21.251) for the mail server.  The VM it resides has a network card ip of 192.168.21.179. After tracing traffic going out our MultiPOP from 127.0.0.1 (which is exactly as your tests show) the ip address is recorded as 192.168.21.179.


    So, why isn't the system correctly binding to the address specificed (192.168.21.251)?

     

    Additionally, because of the incorrect ip address (127.0.0.1 see below) the certificate verification can not be directed back to the mailserver and therefore is failing.

    Thu 2023-08-17 12:22:13.619: 05: [00073260] *  D=secure.emailsrvr.com TTL=(1) A=[184.106.54.10]
    Thu 2023-08-17 12:22:13.620: 05: [00073260] Waiting for socket connection...
    Thu 2023-08-17 12:22:13.630: 05: [00073260] *  Connection established 127.0.0.1:60644 --> 184.106.54.10:110
    Thu 2023-08-17 12:22:13.630: 05: [00073260] Waiting for protocol to start...
    Thu 2023-08-17 12:22:13.697: 02: [00073260] <-- +OK Server ready proxy6.mail.ord1d.rsapps.net
    Thu 2023-08-17 12:22:13.697: 03: [00073260] --> STLS
    Thu 2023-08-17 12:22:13.732: 02: [00073260] <-- +OK Begin TLS negotiation now.
    Thu 2023-08-17 12:22:13.824: 01: [00073260] SSL negotiation successful (TLS 1.2, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
    Thu 2023-08-17 12:22:13.825: 01: [00073260] SSL certificate is not valid (CRYPT_E_NO_REVOCATION_CHECK)
    0 likes
  • S

    Any updates?

    0 likes
  • J

    @Scott 

    Hello Scott,

    I have been running several tests over the past few days to see if there is any way to make this work, but whenever I connect to an external MultiPOP host, MDaemon consistently uses the primary local IP address that I have defined in Windows as the bound IP address, rather than the one I have set for the domain in MDaemon or the one that I have set in the "Binding" settings.

    All of the outbound SMTP tests I performed used the local IP address that I had set in MDaemon; only MultiPOP connections appear to be affected by this binding problem.  So, based on all of the results, I believe this is a bug, and I have submitted this to our developers for further review.

    Regarding the "SSL certificate is not valid (CRYPT_E_NO_REVOCATION_CHECK)" error:
    This is actually an issue unrelated to the MultiPOP binding problem, and it should be fixed in the next release of MDaemon.

    Regards,
    Jared Charles

    0 likes
  • S

    Very good.  Thank you for your help.  

    Will I be updated when both fixes are available?

    0 likes
  • J

    Hello Scott,

    I will let you know if a fix becomes available.  In the meantime, I would recommend checking the release notes of the next version of MDaemon.

    0 likes
  • S

    I see version 23.5 was just posted, will this update correct the problem I reported?

    0 likes
  • S

    I see version 23.5 was just posted, will this update correct the problem I reported?

    0 likes
  • J

    Hello Scott,

    Our developer was unable to reproduce the problem, so I ran several more tests on the same machine where I was experiencing the problem.  Eventually, after doing more research, I was able to get IP binding to work.  I believe it started returning the correct IP address after I reset my routing table using this command:

    netsh interface ip delete destinationcache

    Once I ran that command, I was unable to access any websites, so I restarted the server, and then I was able to access the web again.  After that, I tested IP binding, and then it worked.  However, I am not sure what to expect if you decide to try this on your own server.

    0 likes
  • S

    Ran the command: netsh interface ip delete destinationcache

    Restarted Mdaemon and found the same problem (see below)

    Tue 2023-10-10 12:53:50.921: [00508048] *  Connection established 127.0.0.1:54123 --> 184.106.54.10:110

    0 likes
  • S

    Currently the system will not bind to any physical or virtual IP address unlike SMTP (In/out) (as an example) which works correctly.  As you know there isnt a parameter(s) to configure binding Multipop, so I really don't know why or how it works in your lab or how to controll the binding process.

    Please provide more details how to address this issue or if it will be addressed at all.

     

    0 likes
  • J

    Hello Scott,

    I will see if I can break this on my test machine and then run some further tests to see if there is another way to address this problem.

    When you experienced this same problem with SMTP connections, it appears that you fixed it by doing the following: "I made the choice to uninstall, reinstall and then recovered the configurations. Additionally, I cleaned up the network card using a utlity that restored its original integrity on both the virtual and physical server."

    Could you tell me specifically what you did in that instance that you believe fixed that problem?

    0 likes
  • S

    "I will see if I can break this on my test machine and then run some further tests to see if there is another way to address this problem."

    I would believe the larger question should be, where in the system do you have parameters that governs this functionality.


    Under Server Settings -> DNS -> Binding || you bind to an ip address provided


    No one has pointed out where we can configure the ip address for Mulitpop.

    0 likes
  • J

    @Scott 

    Hello Scott,

    The binding parameters are the same for SMTP and MultiPOP. The MultiPOP connection is an outbound connection, so the Outbound Binding settings apply to it as well.

    I finally figured out what was causing my MultiPOP connections to go through my primary IP address assigned in Windows instead of the IP address I had set in the Outbound Binding settings. It was the "Scan Inbound Emails" option in the "Email Guardian" settings of Avast AntiVirus. For some reason, that feature forces the outbound MultiPOP traffic through my primary IP address. That explains why outbound binding has always worked with my SMTP connections.

    I found an old post of yours where you stated, "Local firewall and Avast dont show anything being block."  So, if you are still running Avast, perhaps it is causing your issue as well.

    0 likes
  • S

    Avast was checked before starting this ticket and yes the setting(s) remain the same.

     

    Please note, our SMTP is working correctly because it is bound to our internal ip address of 192.168.21.251

    Example of SMTP (OUT)

    Mon 2023-10-30 09:01:45.786: [00661469] Resolving MX record for MMS.ATT.NET (DNS Server: 208.67.220.220)...
    Mon 2023-10-30 09:01:45.836: [00661469] *  P=010 S=000 D=MMS.ATT.NET TTL=(5) MX=[att-e2xms-east.mx.a.cloudfilter.net]
    Mon 2023-10-30 09:01:45.836: [00661469] *  P=010 S=001 D=MMS.ATT.NET TTL=(5) MX=[att-e2xms-west.mx.a.cloudfilter.net]
    Mon 2023-10-30 09:01:45.836: [00661469] Attempting SMTP connection to att-e2xms-east.mx.a.cloudfilter.net
    Mon 2023-10-30 09:01:45.836: [00661469] Match to IPCache.dat file:
    Mon 2023-10-30 09:01:45.836: [00661469] *  D=att-e2xms-east.mx.a.cloudfilter.net TTL=(1) A=[3.215.148.199]
    Mon 2023-10-30 09:01:45.838: [00661469] Waiting for socket connection...
    Mon 2023-10-30 09:01:45.860: [00661469] *  Connection established 192.168.21.251:57679 --> 3.215.148.199:25
    Mon 2023-10-30 09:01:45.860: [00661469] Waiting for protocol to start...
    Mon 2023-10-30 09:01:46.167: [00661469] <-- 220 att-e2xms-ibgw-5002a.ext.cloudfilter.net cmsmtp ESMTP server ready
    Mon 2023-10-30 09:01:46.167: [00661469] --> EHLO mail.hsmc-ul.com
    Mon 2023-10-30 09:01:46.186: [00661469] <-- 250-att-e2xms-ibgw-5002a.ext.cloudfilter.net hello [216.57.120.170], pleased to meet you
    Mon 2023-10-30 09:01:46.186: [00661469] <-- 250-SIZE 30000000
    Mon 2023-10-30 09:01:46.186: [00661469] <-- 250-ENHANCEDSTATUSCODES
    Mon 2023-10-30 09:01:46.186: [00661469] <-- 250-8BITMIME
    Mon 2023-10-30 09:01:46.186: [00661469] <-- 250-STARTTLS
    Mon 2023-10-30 09:01:46.186: [00661469] <-- 250 OK
    Mon 2023-10-30 09:01:46.186: [00661469] --> STARTTLS
    Mon 2023-10-30 09:01:46.204: [00661469] <-- 220 2.0.0 Ready to start TLS
    Mon 2023-10-30 09:01:46.248: [00661469] SSL negotiation successful (TLS 1.2, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
    Mon 2023-10-30 09:01:46.249: [00661469] SSL certificate is valid (matches att-e2xms-east.mx.a.cloudfilter.net and is signed by recognized CA)

    0 likes
  • J

    Hello Scott,

    When you said that you checked Avast, are you referring to its logging, or are you saying that you already disabled the "Scan Inbound Emails" option in the "Email Guardian" feature?  If you already tried disabling that option, had you tried completely disabling "Email Guardian"?  Have you tried disabling Avast entirely?

    Have you tried using a TCP monitoring tool to see if you can determine whether anything is scanning port 110 at the moment when the MultiPOP connection is triggered?

    As a test, I enabled the "Scan Inbound Emails" option in Avast, downloaded and launched "LiveTcpUdpWatch" from Nirsoft, and then set it to capture both TCP and IPv4 traffic.  When I triggered the MultiPOP connection, I saw the "AvastSvc.exe" process listed in LiveTcpUdpWatch accessing port 110.  Perhaps doing the same might help you identify an application that is scanning port 110.

    0 likes
  • S

    After I read your email I didn't believe Avast would effect Multipop, but I turned off two flags:

    1. Scan.... Pop3 and imap4

    2. Scan... SMTP

     

    Then force Multipop to pull mail.  

    Wow.  There it was 192.168.21.251.   Great Job. Thank you very much.

    Wed 2023-11-08 09:08:38.663: [00733743] Session 00733743; child 0005
    Wed 2023-11-08 09:08:38.663: [00733743] Attempting MultiPOP connection to secure.emailsrvr.com for ****@****.local
    Wed 2023-11-08 09:08:38.665: [00733743] Resolving A record for secure.emailsrvr.com (DNS Server: 208.67.220.220)...
    Wed 2023-11-08 09:08:38.699: [00733743] *  D=secure.emailsrvr.com TTL=(2) A=[184.106.54.10]
    Wed 2023-11-08 09:08:38.699: [00733743] Attempting MultiPOP connection to 184.106.54.10:110 for todd@hsmc.local
    Wed 2023-11-08 09:08:38.701: [00733743] Waiting for socket connection...
    Wed 2023-11-08 09:08:38.734: [00733743] *  Connection established 192.168.21.251:56544 --> 184.106.54.10:110
    Wed 2023-11-08 09:08:38.734: [00733743] Waiting for protocol to start...

     

    0 likes
  • J

    You're welcome, Scott.  I'm glad to hear that disabling those options fixed the problem.  Let me know if you have any further questions regarding this issue.

    0 likes
Please login to reply to this topic!

Participants