On 31 Mar 2016, at 10:50, Matus UHLAR - fantomas wrote:
On 30 Mar 2016, at 9:48, Matus UHLAR - fantomas wrote:
On 30.03.16 06:18, redtailjason wrote:
[....]
The headers you have posted show mail that only goes through
internal IPs and localhost, that mail doesn't seem to come from
outside.
On 31.03.16 09:23, Bill Cole wrote:
I believe that this is not correct.
I have looksed at all headers in the original mail, they were
localhost or
from private range 192.168.0.0/16
it also looks that it comes from EPSON scanner, and has .tiff
attachment
that is quite common for scanned documents.
It is meant to seem that way. This is a very common flavor of spam
these days, although no well-run system accepts it.
Unfortunately...
[...]
Received: from [1.22.69.90] (Unknown_Domain [192.168.1.175])
by MAILSECURITY010.redtailtechnology.com (Symantec Messaging
Gateway) with
SMTP id 69.3E.24467.E9DBBF65; Wed, 30 Mar 2016 04:50:54 -0700 (PDT)
1.22.69.90 is a known recently active spambot:
http://www.abuseat.org/lookup.cgi?ip=1.22.69.90 and it seems like
that spambot is using a proper IP literal of its own IP as its HELO
argument, but is actually appearing to be 192.168.1.175. This is
possible in some environments that use firewalls which NAT inbound
connections so that they seem to come from the firewall itself.
Well, if this is the case, I'm done with it. Are you going to help
anyone
with that dumb network copnfiguration, that makes it very hard to
fight
spam?
Well, he DID mention that he just had the "primary SpamAssassin guy"
leave unexpectedly, maybe that guy did networking too and wasn't very
good at it, or he flipped an obscure setting on a networking device on
his way out the door as sabotage. Only people with broken stuff need
fixing help anyway...
[...]
I agree. But I would first check if that's really the NAT nonsense
(hide
real IP, so we can't find it in blacklists...)
Yes, it's very annoying. Some years back (10?) it was the default config
for F5 Big-IP load balancers and I had to throw a major fit to get the
MTA's at my employer out from behind that junk to where DNS would (and
did) do their load balancing without an extra layer of complexity.
Perhaps it is relevant to note that the OP's domain has a single MX and
when I connected to port 25 on it this morning it bannered as
MAILSECURITY009.redtailtechnology.com and I went no further, but note
that the OP shows a MAILSECURITY010.redtailtechnology.com handling mail.
Odd, that...
Just now I did this:
$ telnet mail1.redtailtechnology.com 25
Trying 65.74.131.101...
Connected to mail1.redtailtechnology.com.
Escape character is '^]'.
220 MAILSECURITY005.redtailtechnology.com ESMTP Symantec Messaging
Gateway
ehlo dynnat.scconsult.com
250-MAILSECURITY005.redtailtechnology.com says EHLO to
192.168.1.175:44719
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE 62914560
250 PIPELINING
quit
221 2.3.0 MAILSECURITY005.redtailtechnology.com closing connection
Well, there's your problem right there: there's a gang of Symantec
Messaging Gateway devices (probably at least 10 of them, maybe MANY
more) that think they only ever get mail from 192.168.1.175, which is
obviously whitelisted because it's an internal RFC1918 IP and your
inside machines like desktops and the laptops people take home and let
their kids play on NEVER get infected (ummm...) I bet 192.168.1.175 is
the inside interface on a load balancer. Maybe even a F5 Big-IP, as I
understand they still are quite popular.
To the Original Poster:
Hey, Jason: STOP DOING THAT, IT'S VERY VERY BAD.
DNS round-robin is generally all you need to balance load reasonably
across a reasonable number of inbound MTAs. If you really need that
third digit to name all your gateways, I know a guy who came up with a
way to make scores of MXs swarm like bees in DNS for XO back when it was
Concentric and I can probably hook you up with him, although he's
probably not cheap. If all you have is a dozen, 4 equal-cost MX's
pointing to names with 3 different A records will do the trick, if you
keep the TTL's shortish.
