This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

420:Socket error from Virginmedia SMTP

Hello,

I have previously received emails from this particular sender and then this weekend he said to me, your emails are being rejected.  He is on virginmedia in the uk.

He has subsequently sent me the failure message to my work email:

    Subject: Delivery Status Notification

    This is the mail system at host know-smtprelay-4-imp.

    I am sorry to have to inform you that your message, "Your address...", could not be delivered to recipient@mydomain.co.uk.

    The remote mail system said;

    420:Socket error

    The original message is attached.

I have a feeling this is to do with the virgin media smtp servers are trying to use The SSL or TLS protocols that have been disabled in v.17

Nothing is being shown up in the email logs to even suggest a connection has been attempted.

Current XG version: 17.0 GA

Mail settings: MTA Mode

Any help would be greatly appreciated.

Thanks

Ian



This thread was automatically locked due to age.
  • Virgin media can’t be the only smtp sender that has resulted in this problem in v17?

    Or have I missed the cause of this?

    I am still receiving numerous other emails through the MTA without issue.

    Thanks again

    Ian

  • any ideas?

     

    I have tried adding the VirginMedia SMTP Sending IP Addresses into the "Skip TLS Negotiation Hosts/Nets" in the Email General Settings Tab but still no luck.

  • Just found another set of emails which are not coming though.

     

    There must be a way of just disabling SSL / TLS on incoming emails if it is going to cause this many issues?

  • Any thoughts on this?

    It seems that in the persuit for security (which I do not disagree with) raw functionality seems to have been compromised.

    From my investigations, the two companies outgoing mail servers were unable to send emails using TLS higher than V1.0.

    That then results with the following theoretical consideration, “What is better when receiving emails?”

      1. Turning off ALL enabled encryption options and only using unencrypted SMTP connections to guarantee emails are delivered from all valid users.

      2.  Enabling the less-secure SSL / TLS protocols that existing ISPs still use to guarantee emails are delivered from as many users as possible and are sent using a more secure method in comparison to unencrypted SMTP

      3.  Only enable the most secure of receiving protocols such that all emails delivered to the server are either delivered  using the secure smtp or (should) fail back to the unencrypted smtp connection.

    Considering the above 3 scenarios (and assuming the TLS negotiation is done correctly), it seems that turning off available encryption options would actually reduce the security and protection of emails.  This is because whilst it forces some systems to use the ‘correct’ levels of security, it forces others to fail-over to even lower levels of security and to actually send unencrypted.

    Therefore the question above should be what is worse, an email sent using an encryption method with a security flaw that some can crack, or email without encryption such that anyone can crack it (or not, as cracking is not required).

    Personally, I think this is something that will differ from application application, where some environments there is no tangible benefit from emails being received over an encrypted SMTP connection, all the way through to some environments where emails should only be received using a secure encrypted SMTP connection.

    I would suggest this would be best as an available option in the MTA configuration page so admins can make the decision based on their requirements.

    For me at the moment as I need to receive these particular emails and given the size of me vs the size of the sending companies and the available incoming smtp options I have, I have had to revert to using a front end SMTP server (that doesnt support SSL/TLS and so has them turned off)  which is checking DNSBL, SPF and forwarding to the XG appliance.  It is not anywhere near ideal, but at least I receive the critical emails!

    Thanks for making what is generally an exceedingly good firewall available to home users for free, and I hope this helps in making it better in future.