[Mimedefang] MX -> 127.0.0.1

[Kevin A. McGrail]

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:<root at planet.mars>"), 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:<nofrom at email>,
> 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:<god at va>
> <<< 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