Thread Info
  • State Not Answered
  • Replies 13 replies
  • Subscribers 0 subscribers
  • Views 7341 views
  • Users 0 members are here
Options
Suggested

[BUG] Problem receiving mail from Office 365 customer

Intellium
Hi,

I've been trying to figure out whats wrong here for 2 days now and I just can't seem to get any further.

I have a customer who's been trying to mail me for 2 days now. All messages he sends to me, bounce back with a message from Sophos stating "Internal Server Error". Nothing more... This customer is located in the Office 365 cloud however. All other mail (every other customer, gmail, hotmail, linkedin, etc) is all being delivered without error. 

I've been scouring the logs, but the Web Interface never lists the sender in any of the logs. Had to go to the appliance to the 'awarrensmpt.log' to actually find a reference. There I find 4 log entries : 

ERROR     Aug 13 13:11:33 [3942988608]: add_notification(): created notification '0xb0000003' to '@' on ':25'

ERROR     Aug 13 13:11:33 [3942988608]: process_forward_queue(): popped notification '0xb0000003' to '@' on ':25'

ERROR     Aug 13 13:11:34 [3942988608]: checkup_mx(): created notification '0xb0000003' to '@' on ':25'

ERROR     Aug 13 13:11:34 [3944258368]: forward_mail(): forwarding notification '@' on ':25'


It seems something happens to the mail and the customer gets the mentioned notification... I however can't figure out what is going wrong, where and why... 

Anybody able to shed some light on this?
Parents
  • 0
    Hello,

    99% office-365 might have asking for client certificate (can you pls. attach packet capture to conform that) during mail exchange with your client (your MTA/mail client), depends on where you placed Copernicus. 

    Below thing things works due to, 

    1) In case of plain firewall rule (traffic not coming to proxy), things works as no mail traffic coming to proxy and office might getting real client's certificate record. And keep office's SSL configuration happy. 

    2) In case where only SMTP enabled and SMTPS not enabled, here proxy don't offer STARTTLS capability to client (your MTA/your mail client) and whole mail exchange happen without SSL, and that's why no room to misbehave SSL.

    While, You keep turn SSL (SMTPS) on with business rule, proxy start offering STARTTLS as capability to client that motivate your client(s) (your MTA/Mail cleint) to start negotiate SSL. Appears, office-365 (in most cases) ask for client certificate, But as proxy act as trusted man in middle for SSL traffic, it has to present its own certificate. That lead office-365 to terminate SSL connection.

    Thanks,
    Saurabh
  • 0 in reply to SPandya
    After disabling the SMTPS scanning, mail seemed to work correctly for this Office 365 customer. We did a few tests and mail was delivered. 

    Today, same issue again. Didn't change a thing in the config. Tried adding them back to the trusted domains, still no go... I'm investigating further...

    I can't attach the .pcap as the file extension is not allowed and it's too big to attach otherwise.
Reply
  • 0 in reply to SPandya
    After disabling the SMTPS scanning, mail seemed to work correctly for this Office 365 customer. We did a few tests and mail was delivered. 

    Today, same issue again. Didn't change a thing in the config. Tried adding them back to the trusted domains, still no go... I'm investigating further...

    I can't attach the .pcap as the file extension is not allowed and it's too big to attach otherwise.
Children
  • 0 in reply to Intellium
    Had to remove the one and only scanning rule left (RBL premium) to make it work again.... This is with SMTPS disabled(!). The only way to reliably get all my customers mail, is by disabling the entire mail proxy...

    Barring the SSL issue... Why is this happening? This is also for this one customer...
  • 0 in reply to Intellium
    Had to remove the one and only scanning rule left (RBL premium) to make it work again.... This is with SMTPS disabled(!). The only way to reliably get all my customers mail, is by disabling the entire mail proxy...

    Barring the SSL issue... Why is this happening? This is also for this one customer...


    HI,

    If office 365 works on SMTPS and SMTPS scanning is off then mail traffic will not submit to mail proxy. 

    So Can you please confirm on which protocol it negotiate and please provide mail proxy debug logs to get more clarity on this.

    Regards,
    Sneha
  • 0 in reply to snehagohil
    Office 365 was using SMTPS (with my test account).

    I'm sorry to say I had to ditch the copernicus appliance and restore the UTM appliance. There is just so much that isn't working... Logging is also a pain which makes troubleshooting very hard to do. And then there is the missing features...

    I'm happy to report that upon restoring the UTM appliance, mail worked correctly (with SMTPS) for all customers. VPN issues are gone, logging is once again visible and actionable... Perhaps when Copernicus vX releases and matures we can have another look.
Unfiltered HTML