Kevin A. McGrail wrote:
Philip:
Some follow-up on your work because it mimics a lot of mine (and much
of that worked helped greatly by Joseph Brennan, Les Miksell, Mark
Damrose, Matthew van Eerde and Jan Pieter Cornet).
A) localhost tests will fail for people using norton antivirus.
B) all/many windows hosts will use helo's that do not include dots.
They simply supply the machine windows network name.
Because of A & B and at Joseph's recommendation, you have to do an
"is_authorized_user" test and avoid the tests on those. You mention
that below but perhaps I missed the logic in your attached file.
(A) can be defeated by making the code aware of NAV being installed...
Or it can be commented out.
(B) That's not a restriction of Windows, I believe. That's a limitation
of certain Windows UA's. I'm working on a patch to Thunderbird, that
should work on XP as well.
I believe that if you aren't using Microsoft networking and/or Active
Directories, then you can set the computer name to an arbitrary string,
including dots...
Can anyone verify that please?
You're correct: I haven't yet added the test for authorized users...
It's on my todo list.
Second, I've worked on a test for valid_mx's that might be a better
place to start. I didn't see the necessity to use Net::CIDR::Lite for
the tests:
http://www.peregrinehw.com/downloads/MIMEDefang/contrib/check_mx_stub.pl.
Perhaps you are going in a different direction but it might be of
interest.
I am not sure your [$hostip] vs $helo test with brackets will work.
I've seen too many firewalled servers give answers that break this.
Well, think about that for a moment.
If you're behind a firewall or you're NATting, then you're only going to
generate a bad address in the HELO in an outgoing transaction.
If you're sending out email, then you need to generate a name by which
you're reachable... i.e. a domain name, not an IP address (which will
have only local significance).
So any machine that generates an outgoing transaction with HELO
192.168.1.10 (for instance) is misconfigured and not globally
identifiable anyway...
Unless you're saying that the firewall rewrites the actual argument
following the HELO message... How exactly do these bad boys misbehave?
Here's the filter_sender I've been working on for quite a while now:
[snip]
if ($helo =~ /^\[?(localhost|127.0.0.1)\]?$/i && $ip ne '127.0.0.1') {
Why would localhost be bracketed?
md_syslog('warning', "Rejecting $sender because $helo ($ip) is
invalid localhost.");
return('REJECT', "Rejecting $sender because $ip is not localhost.");
}
if ($helo =~ /^([mx record names and machine aliases here seperated
by pipes])$/i and ($ip !~ /[your localnetwork such as
209\.225\.49\.\d{1,3}]/ and $ip ne '127.0.0.1')) {
Why testing for $ip ne '127.0.0.1' again here? Maybe these two tests
should be bracketed by this, or else do early acceptance of sessions
from that address?
md_syslog('warning', "Rejecting $sender because $helo ($ip) is
invalidly trying to use our machine or MX name.");
return('REJECT', "$ip / $helo is not valid.");
}
if ($helo =~ /^\[?209\.225\.49\.\d{1,3}\]?$/ && ($ip !~
/209\.225\.49\.\d{1,3}/)) {
md_syslog('warning', "Rejecting $sender because $ip is not
authorized to use helo of $helo.");
Ummm.... that message could be a little more clear. I'd say that $ip
is lying about who he is.
return('REJECT', "Rejecting $sender because $ip is not $helo.");
}
if ($helo =~ /^friend$/) {
Hmmm.... Any identifier that isn't dotted would seem to be bogus
(unless you want to make an exception for localhost). I've seen other
hosts say "HELO xyzzy", etc.
md_syslog('warning', "Rejecting $sender because invalid helo of
$helo.");
return('REJECT', "$helo is not valid.");
}
if (length($helo) < 3 or $helo !~ /\./ && $ip ne '127.0.0.1') {
Same comment applies: pretest for 127.0.0.1 and handle it earlier. It
will simply the logic.
-Philip
_______________________________________________
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
