Messaging Gateway

Hi,

Recently I am getting a user complains that the mail sender and receipts is the same person.
By right my user does not send the mails but he manages to receive it.

In this way, I believe this is causing by the spoofing but any preventation way that I can implement in our environment to further protection.

Temporarily we are still in v8.0.3 and plan to move on v9.
There are no LDAP as the current environment has some constraint from implementing it and cannot configure the compliance rules for inbound sender XXX@abc.com and action to block it.

SBG v9 can greatly improve the problem but no matter how it is still not the best way in protecting as we want like permanent solution rather than the probe accounts detect then just update the spam definition which might be late while all my users manage to get the spoof/spam mails already.

Please kind advise on this.

Thank you

Avatar,

     Is there a reason you can't block th eemails by domain?  Are they all showing they are from your domain or different domains?  The great thing about the Appliance is the number of ways you can block email.  Is there a commonality between messages?  Can you block by IP?

In another thread, Symantec suggested...

You can block messages coming to your organization from senders (spammers) outside your organization pretending to be from your domain.  Here is a KB article that provides some suggestions:

http://service1.symantec.com/support/ent-gate.nsf/docid/2008111714541154

the 1st suggestion is to block all inbound with a from of your domain, but that will only work if you don't have a 3rd party sending mail on the domain's behalf.

Avatar i have some additional question in order to check that your SBG is well configure.
1. Is the SBG directly receiving SMTP from the internet router/Firewall. You should have to accept incoming email from all external IP's if thats the case.
2. Is you are using SBG for outbound mail ( you should if not ), and configure your SBG only to accept SMTP outbound from your Mail server not internal computers.
3. Configure your router / firewall only to allow SMTP out to your SBG outbound interface.

hope this helps.

Hi John,

Because we have the third party sending emails so we cannot block the emails address.
Meanwhile the IP address has been classified as Global Bad Sender but this is not the permanent way to prevent. If the spammer is using other IP address then I will get this mails again.

Hi Phhowe17,

Due to the third party server we cannot block by this way. Any other way?

Hi Luis,

Yes all the mails are from the firewall. The SBG did also send the mails to external. Yes all the mails to external and external to internal will pass through the SBG but I still manage to receive this kind of mails.

Create a rule that say if Inbound mail is from your domain, delete it.  You should be able to create it under Content Filtering Policies.

Hi,

What about the second option in the link Phhowe17 provided? This might work for you if you know which 3rd party companies (and their IPs) you have authorised to send email using your domain name.

Amanda

Mrmuggyd - that won't work, because he has a external party sending on behalf of his domain.
Avatar - setup  DNS SPF  text records for the IP that are allowed to send for your domain.  See this tool: http://old.openspf.org/wizard.html

In SBG - under Spam, Sender Authentication,  Enabled, Add your domain, and select an action.  I recommend something non-destructive like "add a header".  You can then use Message Audit Logs to find e-mails that failed the check (Verdict = Sender Authentication Failed).

Once you are comfortable with the results you can change the settings to something more agressive.

There is a gotcha here - if someone goes to a website (a magazine, FedEx, etc) and uses the "Send to a friend" type link that asked for the sender's e-mail address and the user uses his work e-mail address, this policy will block those types as well.

Hi phhowe17,

If not wrong, my current setting has enable this. Anything else can do in this problems?

Not really.