Paul Smith wrote:
hmmmmm, if an incoming client issues
So, why would a spammer do that? All they need to do is use a EHLO
parameter that is valid for that IP address, and all your fancy tests
are defeated with 10 seconds work by the spammer.
I'm surprise you are suggesting these spoof attempts doesn't exist in
the real world because of the simplicity or dubious nature. The fact
is, the frequency of HELO/EHLO spoofing of all sorts is very high.
If all you are doing is checking that the EHLO name matches an IP
address (which is all you CAN do), it tells you nothing except that the
EHLO name matches an IP address.
Or doesn't match. Failure Analysis is a major part of our spam system.
Once they have done that, they can
trivially send mail from <user(_at_)winserver(_dot_)com>, and there's nothing
stopping them, unless you have SPF or something set up.
Well, if its a local or hosted domain, we validate the user first
before allowing the session to continue. If its a remote domain, then
its moot point because the client session must be authenticated at
which point, most of the spam checking is bypassed (at the SMTP level).
In which case, how did the EHLO test *really* help?
To stop the obvious spoofing attempts, which do occur at a very high
frequency. I am scratching my head as to why you would be questioning it.
which is our domain and its not part of our IP network, its a clear
LMAP DOMAIN::IP violation, thus rejectable with 100% no false
positions (or true negatives depending on your POV).
No, what if someone else has the 'winservers.com' domain, and mistyped
it into their server, or what if you gave your server to someone else,
and they didn't change it (YOU probably wouldn't do this, but other
companies might give a server to a sister company for instance),
Doesn't matter. Good guys and bad guys are treated the same (from a
SMTP compliancy and technical protocol expectation standpoint).
What is true about this world is that that Good Guys complain, Bad
Guys do not. So if there is a delivery problem because of a
misconfiguration, eventually, it will get fixed with a simple phone
call. We don't expect phone calls from bad guys. :-)
Hector Santos, CTO