Messaging Gateway

Howdy folks,

Symantec recommends that the SMG be installed on the gateway before all other MTAs and people at my work place decided to go aganist that for some reason.

As a result we are always under spam fire.

I am considering using third party RBLs now for further blocking SPAM right at the gateway, and needed an explanation as to whether the SMG deployed after the MTA would still be able to detect the incoming blacklisted IP address.

As of now the message audit logs shows that all our email comes from just 2-3 IPs which are the IPs belonging to our SMTP providers IP.

Thanks for reading.

Appreciate any input.

Hi,

As the sending 2-3 IPs belong to your provider none of the RBLs will help you, regardless if its symantecs global bad senders or third party.

Thats why your anti spam gateway should always receive the mails directly.

Approx 94-98% of the connections have a bad reputation. They get dropped because of symantecs global bad senders, bad ips or connection classification, etc

If the decision has something todo with bandwith ask your provider about qos, traffic shaping, etc

Regards

Thomas

But that would be just the connection IP which the SMG can't see, right?

The bad IP is still visible in the msg received headers alongwith my provider's IP address.

Can't the SMG be able to scan that part and match it to the RBL.

Also I have been adding lot of blacklisted IPs from the msg headers to the local bad senders list, will that work?

As for the decision of the deployment it's been so ever since, the response I get is "because we can't run our own MX server" something like that, I don't know what that even means.

Thanks for the reply.

> But that would be just the connection IP which the SMG can't see, right?

Yes

> The bad IP is still visible in the msg received headers alongwith my provider's IP address.

> Can't the SMG be able to scan that part and match it to the RBL.

Based on my knowledge its not possible. As 3rd party RBLs, as global bad senders are on the (i call it) firewall-level and therefore can reject the connection there's no way to tell smg to check the headers. Its only possible at content rules, but by that you must have already have accepted the mail and there are no RBLs to check against.

> Also I have been adding lot of blacklisted IPs from the msg headers to the local bad senders list, will that work?

No

> As for the decision of the deployment it's been so ever since, the response I get is "because we can't run our own MX server" something like that, I don't know what that even means.

... you do run your own smtp server, your smg, which then transfers the mails to your mail-bakcend. The mx record gets the sender to the right destination - in your case currently pointing to the provider. They have to store and forward all your mail (and probably will get some money for that). If you tell your provider to change the ip-address in the mx-record to point to the official ip-address of your smg your almost done. Just take care of spf, helo fqdn, ptr of your smgs-ip etc

Thomas

When I check msg audit logs for verdict "ip on local bad senders list" it shows me a few results, shouldn't that be empty in case of my deployment?

Also if third party RBL is configured, would the email be rejected even if the IP is listed just once?

> When I check msg audit ...

Depending on your firewall settings. If you dont have a ids/ips and your smg is reachable from the internet on port 25 usually spammers, port scanners, etc will find it within minutes (hours) and try to explore it. So you will get hit if these robots find a open port 25 and you'll receive spam ...

In your config i would deny every other ip except those from your isp.

> Also if third party RBL is configured, would the email be rejected even if the IP is listed just once?

Yes. RBL is just a DNS lookup for the connectin ip. If its listed the connection gets rejected, etc - depending on your settings at reputation | third party bad senders | actions. More on RBLs -> https://tools.ietf.org/html/rfc5782

Thomas

heyy

That sounds genius, didn't even think about it, so you saying I can should simply make a incoming rule on the fw or the ips (we have both) to only allow the 4 or so email service provider IP addresses and block everything rest for port 25.

Will this have any effect on the spam quanity then?

Because for normal email to get by the senders will reach the service provider anyway and so can the spammers.

> So you will get hit if these robots find a open port 25 and you'll receive spam ..

we have a problem with spoofed spam as well where our domain is spoofed, is this because the bots can reach the smg at port 25? But from my deployment isn't this what being prevented, my smg doesn't even have a public address, it just receives email from the service provider.

Hi,

You should always only allow the connection which are neccessary. If nobody exept the isp needs to connect to smg why are the ports open?

> Will this have any effect on the spam quanity then?

Probably not. As the bad guys dont connect to smg its not possible to use global bad senders etc.

> we have a problem with spoofed spam...

Why? Activate spf and later on think of dkim. In addition hopefully you have added your own domains at local bad sender domains!

To avoid backscatters add spf and batv, to avoid classic mail spoofing add your domains to local bad senders and last but not least activate address resolution incl dha.

Thomas

HI,

I considered adding my domain to local bad senders, we have some bulk emailing ids which use our own domain to send us incoming emails and they are being used by third party.

And enabling spf will have the same problem that those third parties will fail the spf test.

Hi,

Bulk emailing - thats bad, very bad - try to change that. But remember, envelope from and from are checked against local bad senders.

Spf - would not be a problem, just add them

Otherwise i have no solution to get rid of spoofing

Thomas

The bulk email firm's IP address won't pass the spf test for my domain is what i am thinking.

The bulk emailing is some auto generated emails, no body even seems to know how it's being used and all where over here.

For now I have planned to block spoofed emails using content filtering rule which checks both the envelope and from for my own domain and also checks a dictionary with legitimate email ids which we use and we pass the email through if it's from one of those ids in the dictionary or hold it otherwise.

If the deployment was correct then I think the spoofing wouldn't be an issue in the first place and most of these IPs which spoof our domain are probably on every blacklist there is.

SPF: Just add the Bulk-Servers IP or, if they provide an spf "include bulk-mail-domain" to your spf-record.

By using content rules you have to adopt the rules constantly ... lot of work ;-) but possible.

As more and more trojans etc hook on to real account (eg replying to real mails) its easy for them to spoof if providers dont check the sender, and some dont.

Because of that address spoofing is still common and you only can use as many techs as possible to find most of them.

Thomas