Page 1 of 1

Stopping Forged or Spoofed email?

Posted: Thu Aug 22, 2019 7:11 am
by ramakanth
We are using zimbra 8.8.6 version Internal spam emails generating frequently to all the uses.

How to fix this issue.
Please suggest me.


Regards,
Ramakanth

Sent from my BLN-L22 using Tapatalk

Re: Stopping Forged or Spoofed email?

Posted: Thu Aug 22, 2019 9:41 am
by phoenix
That description doesn't really tell us much nor does it describe what you've done to try and find out exactly what's happening and what do you mean by "generating..."?

Re: Stopping Forged or Spoofed email?

Posted: Fri Aug 30, 2019 1:51 am
by ramakanth
Hi,

Issue is mail spoofing. How to avoid mail spoofing in zimbra 8.8.6.




Sent from my BLN-L22 using Tapatalk

Re: Stopping Forged or Spoofed email?

Posted: Fri Aug 30, 2019 2:36 pm
by JDunphy
ramakanth wrote:Hi,

Issue is mail spoofing. How to avoid mail spoofing in zimbra 8.8.6.
If you are digitally signing all your email and use SPF, you can use Spamassassin and look at some rules that fired like: DKIM_VALID_AU (signed by a valid author of a domain) and look inside the message for Return-Path which is the envelope 'from' at the top of every email. Here is one method that is pretty generic and works across most scenarios using SA and Zimbra.

Add this to your /opt/zimbra/data/spamassassin/localrules/sauser.cf after changing the domains in the __SPFSENDER_FROM rule to your domains.

Code: Select all

header __SPFSENDER_FROM From =~ /example\.com|example\.net/i
meta SPOOFED_FROM (__SPFSENDER_FROM && !DKIM_VALID_AU)
score  SPOOFED_FROM 7
describe SPOOFED_FROM Not DKIM signed

header __RETURNPATH_FROM Return-Path =~ /\@example\.com|\@example\.net/i
meta SPOOFED_FROM_1 (!__RETURNPATH_FROM && __SPFSENDER_FROM && !DKIM_VALID_AU)
score  SPOOFED_FROM_1 7
describe SPOOFED_FROM_1 Spoofed Return-Path and From

#whitelist if its from us (optional)
meta J_WHITELISTUS (!SPOOFED_FROM && __RETURNPATH_FROM && DKIM_VALID_AU)
score J_WHITELISTUS -10
describe J_WHITELISTUS Kludge for mime parser FP
Followed by this:

Code: Select all

# su - zimbra
% /opt/zimbra/common/bin/spamassassin --lint
#pickup rule changes
% zmamavisdctl restart
Note: You don't need to wait to see if this works. Saved the spoofed email to a file and run it through SA in debug mode and look at the score and if this rule fired before doing your zmamavisdctl restart and putting it into production.
I have written more on the subject here on how to test your rules and debug them: https://wiki.zimbra.com/wiki/JDunphy-SA-RuleWriting.

PS... You might want to re-think your topic title and re-edit this title because "spam issue" is a little generic. :-) How about something like: "Stopping Forged or Spoofed email?" to help others in the future. After you have a working solution, pre-pend "Solved:" in front of your topic title" by re-editing the topic title again.

Re: Stopping Forged or Spoofed email?

Posted: Fri Aug 30, 2019 2:42 pm
by phoenix
Hi Jim

I've changed the title of this thread to your suggestion. :)

Re: Stopping Forged or Spoofed email?

Posted: Fri Aug 30, 2019 4:30 pm
by JDunphy
phoenix wrote:Hi Jim

I've changed the title of this thread to your suggestion. :)
Thanks Bill.

Here is another answer last year for the original poster (OP) of this topic with a few more answers.
viewtopic.php?f=15&t=65151
Unfortunately, that topic was titled "spam problem". I am seeing a pattern here. :-) :-)

Perhaps others in the community could add the postfix way, and any other methods because allowing spoofed or forged email is too dangerous not to address.

Note: If you don't want it delivered to the junk folder than raise the score past 15 points vs 7. In Practice, that score of 7 quickly goes higher on its own when you factor in ip reputation of the sender (blacklists) and other SA rules that fire... so the net result is any forged spam ends up not delivered when it was spoofed even with a score of 7. The drawback of using the SA method when you are flooded or under attack is it does utilize resources to process any email through SA so other solutions may work better for some environments depending on frequency. We layer our defenses here by using a simple FW rule that watches the number of connections by the MTA over a time interval in our MX's which are not zimbra based. If the hitcount is too high over that time interval for that connecting MTA, we put them in a 4 hr ipset blocklist and if they are legit, they will redeliver when the ip expires out of the ipset. It helps smooth the connections to our zimbra servers by our MX's because we don't have to worry about flooding by botnets for not only spoofed email but other types of attacking bots.

HTH,

Jim