Thread Info
  • State Not Answered
  • Replies 13 replies
  • Subscribers 0 subscribers
  • Views 7332 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?
  • 0
    I've since found out that creating a content filter exception rule in the mail scanning rules will allow the mail to come through...
  • 0 in reply to Intellium
    Final conclusion is that the default scanning rules create this issue for every Office 365 customer.

    The only usable rule is the RBL (premium) rule. Using the SPAM engine in the rules cause the sender to always receive an internal server error response and no mail will be delivered, quarantined or even logged anywhere...

    I have had to pretty much disable all mail scanning due to this.
  • 0 in reply to Intellium
    Final conclusion is that the default scanning rules create this issue for every Office 365 customer.

    The only usable rule is the RBL (premium) rule. Using the SPAM engine in the rules cause the sender to always receive an internal server error response and no mail will be delivered, quarantined or even logged anywhere...

    I have had to pretty much disable all mail scanning due to this.


    Hi,

    Are you facing this issue with Secure SMTP scanning ? Is it possible to share TCPDUMP  or confirm if server is requesting for the client certificate or not ?

    Regards,
    Sneha
  • 0 in reply to snehagohil
    Hi,

    Are you facing this issue with Secure SMTP scanning ? Is it possible to share TCPDUMP  or confirm if server is requesting for the client certificate or not ?

    Regards,
    Sneha


    Hi,

    I know that when I completely disable SMTP and SMTPS scanning, everything works correctly. I've since removed all the default rules and used only the RBL (premium) scan. This worked for a few days and today I got notified by the customer that started receiving the same bounce again. In response to this I removed the RBL scan completely which didn't help. Next I added them as a trusted domain, which seems to have worked (for now). This was specific to this customer however, as my test account in office365 worked fine.

    I've looked at the packet capture stuff in the diagnostic area but am a bit confused as to create a proper trace. Furthermore I find it difficult to properly diagnose this as I know the appliance and office365 are talking to eachother, but I can't seem to find an SMTP transaction log to see what actually happens... On the UTM this would have been easier to diagnose. Any tips on what to do ?
  • 0 in reply to Intellium
    Hi,

    I know that when I completely disable SMTP and SMTPS scanning, everything works correctly. I've since removed all the default rules and used only the RBL (premium) scan. 


    Sneha:  Traffic goes to SMTP Proxy only if SMTP or SMTPS scanning is enable in business application policy rule. So if it is disable mail proxy will not come in path. 

    I wanted to know your deployment detail here. 

    Office 365 generally uses SMTPS and with SMTPS scan it request for the client certificate which is not possible to support by mail proxy so currently it is not working with Copernicus Mail Proxy also.


     This worked for a few days and today I got notified by the customer that started receiving the same bounce again. In response to this I removed the RBL scan completely which didn't help. Next I added them as a trusted domain, which seems to have worked (for now). This was specific to this customer however, as my test account in office365 worked fine.

    I've looked at the packet capture stuff in the diagnostic area but am a bit confused as to create a proper trace. Furthermore I find it difficult to properly diagnose this as I know the appliance and office365 are talking to eachother, but I can't seem to find an SMTP transaction log to see what actually happens... On the UTM this would have been easier to diagnose. Any tips on what to do ?


    Step to capture Debug Logs and File dump on Advance Shell.

    1. echo > /log/awarrensmtp.log
    2. tcpdump host  -s 0 -w /tmp/data/smtp.pcap -b  --> For file dump
    3. service awarrensmtp[:D]ebug -ds nosync --> To run SMTP proxy in debug mode
    4. Send Mail from customer account having issue
    5. service awarrensmtp[:D]ebug -ds nosync --> to stop debug mode
    6. cp /log/awarrensmtp.log /tmp/data/awarrensmtp.log
    7. Download capture and Log file using browse ; access https://:4444/documents/awarrensmtp.log , https://:4444/documents/smtp.pcap 
    8. Remove file rm -rf /tmp/data/awarrensmtp.log , rm -rf /tmp/data/smtp.pcap

    You cal also refer Log Viewer logs. 

    Regards,
    Sneha
  • 0 in reply to snehagohil
    Sneha:  Traffic goes to SMTP Proxy only if SMTP or SMTPS scanning is enable in business application policy rule. So if it is disable mail proxy will not come in path. 

    I wanted to know your deployment detail here. 

    Office 365 generally uses SMTPS and with SMTPS scan it request for the client certificate which is not possible to support by mail proxy so currently it is not working with Copernicus Mail Proxy also.




    Step to capture Debug Logs and File dump on Advance Shell.

    1. echo > /log/awarrensmtp.log
    2. tcpdump host  -s 0 -w /tmp/data/smtp.pcap -b  --> For file dump
    3. service awarrensmtp[:D]ebug -ds nosync --> To run SMTP proxy in debug mode
    4. Send Mail from customer account having issue
    5. service awarrensmtp[:D]ebug -ds nosync --> to stop debug mode
    6. cp /log/awarrensmtp.log /tmp/data/awarrensmtp.log
    7. Download capture and Log file using browse ; access https://:4444/documents/awarrensmtp.log , https://:4444/documents/smtp.pcap 
    8. Remove file rm -rf /tmp/data/awarrensmtp.log , rm -rf /tmp/data/smtp.pcap

    You cal also refer Log Viewer logs. 

    Regards,
    Sneha


    Did some testing and it seems that it indeed failed on the SMTPS part...  

    DEBUG     Aug 18 15:58:25 [3942624064]: Calling SSL_read().

    INFO      Aug 18 15:58:25 [3942624064]: SSL_read() failed: SSL_ERROR_SYSCALL

    ERROR     Aug 18 15:58:25 [0x2000000e]: client read error: Connection reset by peer

    INFO      Aug 18 15:58:25 [0x2000000e]: dying because io_handler said so


    After disabling SMTPS scanning the message is delivered correctly.
  • 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.
  • 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
Unfiltered HTML