Odd SPAM not getting scanned by Untangle

[AdamB]

I am still digging into the SPAM issues we are having.

I have discovered that our users are getting a large amount of spam which is not getting scanned by untangle, in fact it looks like its not going through untangle at all as I can't see it in the event viewer.

What's even more interesting is that the receiver is never the actual users account.

From: Replacement Windows <axelh@sketchable.paradan.info>
To: "Recipient" <gifts@grhospice.org>
Message-ID: <DA241743.ECBE.CE6D.DF4E@paradan.info>
X-content: ldGltckBtZWRlbnQuY29t
Content-Type: multipart/related; boundary="db763236927f2272e18c40bc3f041a69"
MIME-Version: 1.0
Date: Thu, 13 Nov 2014 07:04:55 -0800

Im not sure how or why these are getting through, was hoping some of you may have some insight?

[dmorris]

Well the "To" field can be anything. The mail server really cares about the Envelope-To field which is probably one of your local users.

As far as coming in unscanned, it could be many things.

If its TLS and you've bypassed TLS - then it will automatically go through.
If its a port other than 25 it will not be scanned.
If its bypassed or sent to a rack with spam blocker it won't be scanned.

You can look in your email server logs and get the connection information. The just look up that session in the firewall or policy manager event log and see if Untangle saw it at all. Go from there.

[AdamB]

Well the "To" field can be anything. The mail server really cares about the Envelope-To field which is probably one of your local users.

As far as coming in unscanned, it could be many things.

If its TLS and you've bypassed TLS - then it will automatically go through.
If its a port other than 25 it will not be scanned.
If its bypassed or sent to a rack with spam blocker it won't be scanned.

You can look in your email server logs and get the connection information. The just look up that session in the firewall or policy manager event log and see if Untangle saw it at all. Go from there.

We do have port 465 opened inbound which allows us to send mail from our phone mail clients. Could it possibly be coming in over that?

I looked over our bypass list and nothing there which could be doing it.

These are the only ports which are inbound to our webmail server.

Starting Nmap 5.21 ( http://nmap.org ) at 2014-11-13 13:26 EST
Nmap scan report for webmail.medent.com (65.114.41.130)
Host is up (0.045s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
25/tcp open smtp
443/tcp open https
465/tcp open smtps
993/tcp open imaps

[dmorris]

We do have port 465 opened inbound which allows us to send mail from our phone mail clients. Could it possibly be coming in over that?

Possibly, but doubtful. Usually people open 465 for relaying remote clients not accepting mail, as such spammers are unlikely to use it.

Anyway, theres no reason to guess - just look at your logs and determine how it came in.

[sky-knight]

If you allowed unauthenticated senders to send to port 465 that would be true, but that would also be silly. 465 and 587 should be for authenticated clients only.

[AdamB]

Possibly, but doubtful. Usually people open 465 for relaying remote clients not accepting mail, as such spammers are unlikely to use it.

Anyway, theres no reason to guess - just look at your logs and determine how it came in.

Just got off the phone with support. They feel these are coming in over 465 or 993.

[AdamB]

If you allowed unauthenticated senders to send to port 465 that would be true, but that would also be silly. 465 and 587 should be for authenticated clients only.

Good point, just need to pin down a way in zimbra to block unauthenticated users.

[dmorris]

Just got off the phone with support. They feel these are coming in over 465 or 993.

Yeah, but my point is to stop guessing.
Find the mail. Did it come from 1.2.3.4? Look in the event log to see all the sessions from 1.2.3.4. Which port are they going to at the time that mail was received? If its 465 then thats your issue. If not, then its not your issue.

I would troubleshoot first, then change settings to address the problem. Doing the reverse (changing settings in hopes of addressing the undetermined issue) often creates more issues.

[AdamB]

Yeah, but my point is to stop guessing.
Find the mail. Did it come from 1.2.3.4? Look in the event log to see all the sessions from 1.2.3.4. Which port are they going to at the time that mail was received? If its 465 then thats your issue. If not, then its not your issue.

I would troubleshoot first, then change settings to address the problem. Doing the reverse (changing settings in hopes of addressing the undetermined issue) often creates more issues.

Alright, figured it out. These did not come in on 465 or 993. They came in on 25 but they were passed due to being over sized. The reason I couldn't find them is I was looking for the receiver which looks like it was spoofed. Any input on what size messages are to large? We are getting a ton of spam which are "oversized",

[dmorris]

What is your size limit configured to?