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

BATV exception not working

Hi Everyone!

we use UTM as our SMTP proxy. One of my colleagues does not receive mails because they get instantly rejected because of BATV. But those mails aren't SPAM or something, they're legitimate. My feeling is that those get the BATV flag because they are actually sent to a mailing list from outside of our organization (which my colleague is subscribed to) and that is creating the problem.

Now I just wanted to create a BATV exception, but this does not work, the exception is ignored. For the exception I set my colleague as receiver, but since the mail is sent to a mailing list this does not work (I think?). But even if I put the mailing list as receiver or sender this does not work.

The only thing working so far is to put the sending server on the exception. But since the mail is sent by Microsoft (Outlook online) there are dozens of servers who might send the mail, so that is not a solution.

How can I set the BATV exception without disabling it all together? And why is the UTM ignoring it when I put my colleague as the receiver?

Here's the SMTP proxy log and some screenshots.

Thanks!

BATV

BATV

exception config

2021:06:02-03:56:12 *****fw01-1 exim-in[12468]: 2021-06-02 03:56:12 SMTP connection from [40.107.101.41]:26592 (TCP/IP connection count = 1)
2021:06:02-03:56:13 *****fw01-1 exim-in[23667]: 2021-06-02 03:56:13 H=mail-mw2nam08on2041.outbound.protection.outlook.com (NAM04-MW2-obe.outbound.protection.outlook.com) [40.107.101.41]:26592 Warning: ****.net profile excludes greylisting: Skipping greylisting for this message
2021:06:02-03:56:13 *****fw01-1 exim-in[23667]: 2021-06-02 03:56:13 H=mail-mw2nam08on2041.outbound.protection.outlook.com (NAM04-MW2-obe.outbound.protection.outlook.com) [40.107.101.41]:26592 Warning: ****.net profile excludes SANDBOX scan
2021:06:02-03:56:13 *****fw01-1 exim-in[23667]: 2021-06-02 03:56:13 [40.107.101.41] F=<> R=<*.********@****.net> Verifying recipient address with callout
2021:06:02-03:56:13 *****fw01-1 exim-in[23667]: 2021-06-02 03:56:13 [40.107.101.41] F=<> R=<*.********@****.net> Accepted: is a bounce
2021:06:02-03:56:14 *****fw01-1 exim-in[23667]: 2021-06-02 03:56:14 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="40.107.101.41" from="" to="*.********@****.net, subject="" queueid="" size="145548" reason="batv" extra=""
2021:06:02-03:56:14 *****fw01-1 exim-in[23667]: 2021-06-02 03:56:14 H=mail-mw2nam08on2041.outbound.protection.outlook.com (NAM04-MW2-obe.outbound.protection.outlook.com) [40.107.101.41]:26592 X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no rejected DATA
2021:06:02-03:56:14 *****fw01-1 exim-in[23667]: 2021-06-02 03:56:14 SMTP connection from mail-mw2nam08on2041.outbound.protection.outlook.com (NAM04-MW2-obe.outbound.protection.outlook.com) [40.107.101.41]:26592 closed by DROP in ACL



This thread was automatically locked due to age.
Parents
  • Hi all,

    so, I had a very long back and forth mail conversation with the Sophos support and now want to conclude this...

    Unfortunately, the problem itself couldn't be solved. The support needed the original BATV-claimed mail for this for analyzing the problem. But the mail's content is sensitive and so it was decided that it's just not worth the trouble. My colleague is the only one having problems with the BATV and they will simply just use an alternative email address to let the mail be send to.

    So the reason why the BATV exception is not working could not be discovered. Maybe it's just a bug in the UTM (we are now using version 9.707-5 and it's still not working).

    What's interesting: If we use a wildcard for the whole domain - like *@example.com - the exception is working without a problem. Maybe that's a solution for someone facing the same problem.

    Thank you everyone for your help and suggestions.

    Markus

Reply
  • Hi all,

    so, I had a very long back and forth mail conversation with the Sophos support and now want to conclude this...

    Unfortunately, the problem itself couldn't be solved. The support needed the original BATV-claimed mail for this for analyzing the problem. But the mail's content is sensitive and so it was decided that it's just not worth the trouble. My colleague is the only one having problems with the BATV and they will simply just use an alternative email address to let the mail be send to.

    So the reason why the BATV exception is not working could not be discovered. Maybe it's just a bug in the UTM (we are now using version 9.707-5 and it's still not working).

    What's interesting: If we use a wildcard for the whole domain - like *@example.com - the exception is working without a problem. Maybe that's a solution for someone facing the same problem.

    Thank you everyone for your help and suggestions.

    Markus

Children
No Data