Jan:
Thanks again for the detailed response. Responding after a fairly invasive
amount of updates to the v2 code. I've tried to fix each scenario you
identified and added much more informative debug information.
http://www.peregrinehw.com/downloads/MIMEDefang/contrib/check_primary_mx_stub-v2.pl
If anyone has any comments on email address they think should pass or fail
that don't act as expected, please send them to me.
For example, see geg.com as an example of private IP space MX records.
Based on the statistics you gave, adding a loop to test all of the exchanges
for privatized MX seems like a good idea and it ends the argument of whether
or not to ban private IPs since now we are checking all of the MX records.
It passes because the "A" query of that "name" gives an error
(NXDOMAIN), and when that happens you get to the point in the code
where it says "#THE ANSWER COULDN'T BE RESOLVED"
You are right. I have switched from using the Net::DNS::Resolver query
method to the send method. This allows me to use the undefined $packet as
an error requiring a pass and the lack of answers as an error requiring a
fail. Excellent catch and as you'll see below, it caught more errors than
just this!
(I think... you have
deeply nested code! It's not illegal to put stuff in subroutines
occasionally,
did you know that? :).
I really have looked at how to put some of these things in subroutines but
believe that the nesting problem would be there regardless. I think I would
simply be able to shortened some of the content in the nesting.
I really am trying to simplify it but it's a lot of cases to allow for.
Hopefully,
the test framework I put in place will help identify problems though.
But you might want to bounce in case that record doesn't resolve, but
still allow mail from the occasional idi...eh...MCSE behind the buttons
who accidentally puts an IP address in the MX record.
Are you recommending to bounce or not to bounce for an IP in an MX record.
I've made this a configurable option if I understand what you are saying.
I don't believe sendmail can reject that case. I'm not talking about the
domain not resolving at all, I'm talking about the case where the domain
itself doesn't resolve (like "MAIL From:<[EMAIL PROTECTED]>"), but where
the domain resolves and has MX records, but those MX records do not
resolve.
See for example: tennesseen.com or 8888.com
We count about 65000 per day of these mails, about twice as much as
localhost MX.
Good point and the major code change from using the method 'query' to method
'send' with Net::DNS::Resolver caught this error as well.
> >- The domain could be in the form [127.0.0.1], causing your MX lookup
> > to fail (in which case you currently accept).
> >- The domain could even be [IPv6:2222::1234:5678:9abc:def0] (but we
> > currently reject this, it's too obscure).
I have looked into this and based on AOL's policy not to accept @[IP
address], I am following suit and blocking these type of sender domains.
Real domains are reasonably cheap and easy to setup so it's a simple
requirement to meet to actually be able to send email.
Re: Dropping Blank MX with Priority 0
Hmm, you might want to be relaxed about the priority. Even though
in http://www.ietf.org/internet-drafts/draft-delany-nullmx-00.txt
Mark Delany specifies a priority of 0, he's now using a priority of
1 himself in the yahoo.com zones. See for example the domain:
web54410.mail.yahoo.com
I don't see the priority 1 on web54410.mail.yahoo.com's MX record?
A hostname without a domainname, so, anything that isn't a FQDN. For
example, someone is repeatedly trying to mail us as MAIL
From:<[EMAIL PROTECTED]>,
which we don't accept.
Good point, added that test.
Note that I only give this error after checking if accidentally this
isn't a tld with MX records. Yes, those exist... the primary MX of va. is
lists.vatican.va, and it just told me:
>>> RCPT To:<[EMAIL PROTECTED]>
<<< 250 Ok
Interesting... not only does God exist (and proves He exists, hmm, He
apparently hasn't read THHGTTG very well), but He's connected to the
internet!
Chuckle :-) I added this as a test which passed.
> Feedback on this code appreciated. Would especially appreciate email
> address that should be used to test the code either in a pass or fail
> capacity.
Take all domains mentioned above as testcases :)
I did, thanks.
You are in various places calling type-specific methods on Net::DNS::RR
objects, without verifying their types first (first in the "sort MX by
preference" bit). If there's a DNS server out there giving unexpected
answers, your code will crash.
Thanks, I believe I have fixed this.
Regards,
KAM
_______________________________________________
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
