On Fri, 10 Nov 2006, Richard Laager <[EMAIL PROTECTED]> wrote:
# Check #3
# HELO should not contain "localhost"
How effective is this for you? Do you run into false positives?
It's effective in my situation because the servers that run MIMEDefang
are purely mail relays into/out of the network. Authorized E-Mail clients
(MUSa) authenticate to other, "interior" servers, so there are no purely
client connections. Everything connecting to the relays is an MTA.
Even a misconfigured internal MTA won't be tripped up because internal
relays are exempted from all checks HELO thru RCPT TO. I don't even start
to look at internal relays until after DATA.
There is no reason for a foreign (not on my network) MTA to HELO with
"localhost" anywhere in its HELO string. If they do so, they're either
fraudulent, grossly misconfigured or the admin is RFC Ignorant.
If they're fraudulent, why do I want to talk to them? Or allow them to
waste more of my resources?
If they're grossly misconfigured, then I'm not interested in finding
out what other misconfigurations they have. One of them might be dangerous
to me.
If the admin is RFC Ignorant, well, the error message has the
information they need to become clueful.
# Check #4
# If the HELO is an FQDN, the index and rindex of "." will not
be the same
# This catches the spammer using domain.tld (which will slip
# by Check #2)
I check that the HELO must have a ".", but I haven't gone any further
than that. Does this work well for you? Any false positives?
Not sure what you mean by "false positives". How would you define a
"false positive"?
On Fri, 10 Nov 2006, John Rudd <[EMAIL PROTECTED]> wrote:
Dirk the Daring wrote:
# Check #4
# If the HELO is an FQDN, the index and rindex of "." will not be the
same
# This catches the spammer using domain.tld (which will slip
# by Check #2)
if ( index($helo, ".") == rindex($helo, ".") )
{
# Reject connection - invalid HELO
md_syslog('alert', "Non-FQDN HELO $helo by Host $hostip");
return('REJECT', "INVALID HELO/EHLO: $helo is not FQDN");
}
As I wrote previously, my entire filter is heavily logged. My
analysis of those logs indicates that only about 50% of foreign
mailhosts connecting to my network get past HELO. Based on the
I-think-reasonable assumption that no "legitimate" mail server would be
tripped up by GREETPAUSE, RATECONTROL, CONNCONTROL or the tests I have
in filter_helo, my conclusion is that those 50% are spammers, and I'm
effectively stopping them by the end of HELO.
Given that I don't think check #4 is valid, I'm not sure I believe your
claim. For one, depending on the configuration I'm using, you might end
up rejecting my email, because my mail server's hostname is the
registered domain name (rudd.cc) ... and I'm not a spammer.
Check #4 is quite valid - see below.
As for my numbers, I've done some statistical analysis on my log files
- as I said, my current filter file is heavily logged as I experiment with
different approaches.
One logging feature is a log entry for each connection from a foreign
host (made in filter_relay). I can then track that connection and see how
far it gets. My analysis is that only about 50% of foreign connections
make it past HELO. Since my checks are primarily aimed at obvious fraud, I
conclude that the checks are stopping 50% of the spammers (since
"legitimate" MTAs operating in accordance with RFCs are not troubled).
(I don't recall any prohibition on a host's name being just its
registered domain, domain.tld)
Actually, the RFCs clearly state that acceptable HELOs are the
hostname/FQDN or the IP address.
Specifically, RFC 821, 4.1.1, stated:
The argument field [of the HELO command] contains the host name
of the sender-SMTP.
That's "host name", not "domain name".
And since RFC 2821 supercedes 821, it's text is even more important;
and 4.1.1.1 states:
The argument field [of the HELO or EHLO command] contains the
fully-qualified domain name of the SMTP client if one is
available. In situations in which the SMTP client system does not
have a meaningful domain name (e.g., when its address is
dynamically allocated and no reverse mapping record is available),
the client SHOULD send an address literal....
Again, that's "fully-qualified domain name"..."rudd.cc" is not a
fully-qualified name.
I'm also curious why you're using a lot of index/rindex calls instead of
regular expressions (I'm not enough of an expert to know if one is
honestly faster than the other). For the above one, why not:
Because I'm not a Perl hacker - it seemed to me to be the best way to
do it. I'm defining "best" as 1) reasonably efficient and 2) clearly
readable in the code.
As I stated in my original posting in this thread, I'm not a Perl
coding whiz. I make no claim that my Perl code is anything beyond working.
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
