Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 6032 views
  • Users 0 members are here
Options
Suggested
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

E-Mails from new Sophos ticket system not reaching our systems ever since the cutover

Harald Pfeiffer

Hello all,

I'm now reaching out to the forums as the case support seems rather superficial here.

Ever since the cutover to the new ticket system we do not receive any emails anymore. I asked for a bit of information about the sender and the sending email servers and so on, and after a brief analysis period Sophos support asked me to check the spam box [sic] and told me the sender is support@sophos.com [sic] (is it the Envelope-From or only the From?)

Does anybody else have issues before? All I can see is huge amounts of qmgr traffic from and to addresses like 01020174b104ac7b-88e6a42b-ea56-4dcc-a88a-b55eda754d1a-000000@feedback-smtp-0001.central.sophos.com, and hosts like mail.delivery-37-eu-central-1.prod.hydra.sophos.com. With all the e-mail any appliance generates (sic), it's hard to distinguish right off the bat.

  1. Where do Sophos support case e-mails come from? Is the address above completely used, what are the sending servers?
  2. Does anybody know how to reach somebody at Sophos who can check _outgoing_ e-mails?
  3. Do Sophos themselves have issues, since forum entry 122707 even ended up in Sophos appliances blocking Sophos support e-mails (maybe, and I'm just assuming, due to unclean migration to Salesforce in terms of DNS etc)?

The only indication I have seen so far, and it is a wild guess because I know of the term "Salesforce", is this:

Sep 21 21:36:20 postfix-inbound/smtpd[15571]: disconnect from smtp07-fra-sp1.mta.salesforce.com[85.222.158.230] ehlo=1 starttls=0/1 commands=1/2
Sep 21 22:42:22 postfix-inbound/smtpd[29362]: SSL_accept error from smtp07-ph2-sp3.mta.salesforce.com[13.110.6.198]: Connection reset by peer

....but I can't even tell whether this is Sophos or something else, since Salesforce has been taking over a *lot* in terms of consulting web-services and e-mail.



This thread was automatically locked due to age.
Parents
  • 0

    Hi ,

    Apologies for the inconvenience caused. Our team is actively working to resolve the issue related to outbound emails being blocked (tracked under ITASSCD-5654).

    Please stay tuned for more info.

    Florentino
    Director, Global Community & Digital Support
    Are you a Sophos Partner? | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the 'Verify Answer' button.
    The Award-winning Home of Sophos Support Videos! - Visit Sophos Techvids
  • 0 in reply to FloSupport

    Hello,

    thanks for passing on the ID. Is there any way to check details through the ID itself, or to pass on any basic technical details to us?

    Right now, there isn't even a way to check what Sophos or their Salesforce config is doing wrong and to possibly whitelist things temporarily to verify the issue at hand. This is a bit meager, given the fact we already reached out to a "technical" support, and nobody ever told us sending servers or something in the likes of that direction.

  • FormerMember
    0 FormerMember in reply to Harald Pfeiffer

    Hi Harald,

    We have found that DMARC policies were blocking the emails, recommendation for Central customers is to set  DMARC action to - >   Conform to sender policy  

    Hope this helps to resolve the issue for you until the fix is in place. 

    Regards, Secil 

  • FormerMember
    0 FormerMember in reply to Harald Pfeiffer

    Hi again Harald,

    We have made changes to the DKIM signature on emails sent from support@sophos.com which should resolve this issue. 

    Regards, Secil 

  • 0 in reply to FormerMember

    Hello Secil,

    DKIM and DMARC failures, curious as those are because either they fit or they cause a mass of -justified- problems, are not the issue here. These failures would be registered in our mail security appliances as bogus mailing or spam if you will, whereas, I repeat, we never receive any email to that point. Which is why I also pointed out an example Salesforce entry from our logs with a broken STARTTLS connection attempt.

    Whenever initial connections are terminated e.g. due to no matching handshake mechanism found, you will not receive even email headers. And it looks like that to me.

    Now what I truly find curious is that, after all this time, nobody can even tell us which e-mail servers Sophos are using. Let alone their TLS parameters and so forth.

    Who is in charge of the servers, who can we talk to who is able to at least basically understand and look into technical details on your end?

    Thanks in advance.

    Cheers

    Harald

  • 0 in reply to Harald Pfeiffer

    Nonetheless, if we want to be sure nothing interfered before mails would have been submitted to our MTA, you can have any Sophos engineer trigger an e-mail from case 03151018, that one deals with our issue and has been answered nowhere near as detailed as you did. That could be used as a practical test whether, currently, the issue persists. Which I assume, but assumptions are not technical facts :-)

    Edit: The last e-mail from the ticket system (it states "20/10/2020 13:10" WITHOUT timezone, so I assume CEST... :-/) did not arrive on our end. Depending on the date and time of the fixes on your end this is either significant or it isn't. Times of changes is something I would also consider technical details, among the other things I indicated in the previous post.

Reply
  • 0 in reply to Harald Pfeiffer

    Nonetheless, if we want to be sure nothing interfered before mails would have been submitted to our MTA, you can have any Sophos engineer trigger an e-mail from case 03151018, that one deals with our issue and has been answered nowhere near as detailed as you did. That could be used as a practical test whether, currently, the issue persists. Which I assume, but assumptions are not technical facts :-)

    Edit: The last e-mail from the ticket system (it states "20/10/2020 13:10" WITHOUT timezone, so I assume CEST... :-/) did not arrive on our end. Depending on the date and time of the fixes on your end this is either significant or it isn't. Times of changes is something I would also consider technical details, among the other things I indicated in the previous post.

Children
Unfiltered HTML