Block Emails for particular domain

Under Antispam Tab -> Sender Blacklist,

Add the desired mail address to block.

Use *@example.com to block all addresses for tha domain

Dear Oldeda.

How you are fine and doing well,

I have done this job but whenever i generate report of spammer or senders we are not able to generate any sort of spam report or any visibility of catch a spam.
we have been receiving spams from qq domain we don't have any log in Sophos though we have logs in our email server filled with qq domain's spams.

Would be glad if a guide us in configuration.

1.*@qq.com

2.qq.com

EMail has two different pieces of "FROM" information.  The first and most obvious is the "From:" message header, which is part of the message content and is displayed to the user.   The second one is an internal Authenticated-As / Envelope-From identifier, which is technically part of the SMTP protocol exchange and not part of the message.   Many spam filters insert the Authenticated-As / Envelope-From information into the message headers, but they do not do it inconsistently and it is not required.   Bounce messages do not have the Authenticated-As information because they were sent by automation rather than a user.

Many others on this forum have complained about the difficult of filtering on the "From"Header.   UTM, and the Exim system inside it, seems to only filter on the Authenticated-As information. 

The one exception to this appears to be the "Strict SPF" option.   SPF is intended only for comparing the Authenticated-As information to the source IP.   I think "Strict SPF" applies the SPF check to the From Header as well as the Authenticated-As information.  It is not well explained in the documentation; others will have to comment on whether I understand the setting correctly or not.

I think you're thinking of Forward-Confirmed reverse DNS (FCrDNS), Doug.

RFC 7208 notes:

11.2. SPF-Authorized Email May Contain Other False Identities

   The "MAIL FROM" and "HELO" identity authorizations do not provide
   assurance about the authorization/authenticity of other identities
   used in the message.  It is entirely possible for a malicious sender
   to inject a message using his own domain in the identities used by
   SPF and have that domain's SPF record authorize the sending host, and
   yet the message can easily list other identities in its header.
   Unless the user or the MUA takes care to note that the authorized
   identity does not match the other more commonly presented identities
   (such as the From: header field), the user might be lulled into a
   false sense of security.

Cheers - Bob

Yes, oops, and bummer.   I was working from home while temporarily blacklisted from work and my WebAdmin console, so I did not check my facts.   I know that I have seen the "Strict SPF" concept somewhere, but I guess it was not here.

Yes, oops, and bummer.   I was working from home while temporarily blacklisted from work and my WebAdmin console, so I did not check my facts.   I know that I have seen the "Strict SPF" concept somewhere, but I guess it was not here.