Thread Info
  • State Not Answered
  • Replies 13 replies
  • Subscribers 0 subscribers
  • Views 7343 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
    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
Reply
  • 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
Children
  • 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.
Unfiltered HTML