Hector Santos wrote:
Paul Smith wrote:
Not sure I understand that.
It is totally valid to do:
The EHLO name bears no resemblance to the sender's email address. Doing
an SPF on the EHLO name is pointless, as all that tells you is that the
sending host is 'mail.spammer.com'.
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. This might be
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. 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. In which case,
how did the EHLO test *really* help? The SPF test on its own would have
achieved the same.
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), or what
if that was an example in documentation somewhere, and so on. You get
false positives. You only get 100% no false positives if you can be 100%
sure that (a) everyone else knows what they are doing, and (b) no one
else makes a mistake. Good luck with that.
If (as is more likely) a mail server is set up to send EHLO
server.company.local, and you reject it (against RFC 5321) then you will
get lots of false positives, just because a 5 user company with SBS
doesn't understand SMTP.
VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows