[Mimedefang] MX -> 127.0.0.1

Jan Pieter Cornet johnpc at xs4all.nl
Tue Oct 25 17:31:26 EDT 2005


On Mon, Oct 24, 2005 at 05:07:40AM -0400, Kevin A. McGrail wrote:
> >So for example, we don't reject
> >outright on private IP space in MX records, as long as there are
> >other reachable addresses too.
> 
> I chose to only check the primary MX because my analysis showed that it was
> likely to be a "good" test to get rid of unwanted junk mail.  I also agree
> with you and do not personally bounce based on privatized IP usage but I
> think I see what you are saying.

Well, it's worth taking an extra look at it, we block just over 2000
mails per day that have MX records only to private IP space (versus
34000 for "localhost" MX, and 65000 for non-resolving MX records).

For example, see geg.com as an example of private IP space MX records.

> >- sendmail (and possibly other MTAs) will actually understand this
> >  grossly wrong MX record:
> >
> >example.com.     IN MX 10 12.34.56.78.
> >
> >  And use the "hostname" there as the IP address. (Of course, if you
> >  want your MTA to help fight for a better world, you'd probably want
> >  to RST your TCP connection to any loser mailing from such a domain
> >  with a christmas tree of death packet. But I digress...)
> 
> Technically, DNS handles this as a CNAME which isn't RFC compliant for email
> but I'm choosing to follow sendmail's lax interpretation to prevent false
> positives.  I believe this will definitely now pass v2 of the check stub.

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" (I think... you have
deeply nested code! It's not illegal to put stuff in subroutines occasionally,
did you know that? :).

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.

> >- if an MX record doesn't resolve at all, you can also consider it
> >  a malicious error (this one is quite common even).
> 
> I'm dropping that at a sendmail level and expect others to do so as well.
> Therefore, I'm considering a non-resolve as an internal problem or timeout
> issue.  Since I set the timeout to only 4 seconds for DNS queries, I aiming
> for a shotgun, get a lot of bad guys approach.

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.

> >- The domain could be in the form [127.0.0.1], causing your MX lookup
> >  to fail (in which case you currently accept).
> 
> Can you give me an example email address that has DNS that does this?

Sure. <postmaster@[127.0.0.1]> should send mail to yourself (or rather
your postmaster, I'm assuming that's you :)

(In doing so... I notice that we aren't even accepting mail addressed
to postmaster@[ip-of-mx-host]... nobody complained so far. But that's
why I cannot give you a real working remote email address of this
form right now).
 
> >- The domain could even be [IPv6:2222::1234:5678:9abc:def0] (but we
> >  currently reject this, it's too obscure).
> 
> Can you give me an example email address that has DNS that does this?

Not a working one, offhand, again, <postmaster@[IPv6:::1]> should reach
yourself, provided you have IPv6 working and your MTA listening on IPv6

> >- This specific syntax:
> 
> >example.com   IN MX 0 .
> >
> >  is commonly understood to mean "this domain does not do email at all",
> > So we currently
> >  only block on "MX 0 ." when it's the only MX record (or only one in
> >  a set of equal preferenced records).
> 
> I've implemented a basic check for this, thanks for the detailed info.  I 
> am only block if the MX at priority 0 is a period (which translates as 
> blank).

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

> >- We explicitly test for lone hostnames and non-existing TLDs to give
> >  understandable error messages. These cases are usually due to
> >  incompetence, and the reject messages are actually read by users.
> 
> I believe sendmails resolution checks will bounce non-existent TLDs but what
> is a lone hostname?

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.

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!

> 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 :)

> http://www.peregrinehw.com/downloads/MIMEDefang/contrib/check_primary_mx_stub-v2.pl

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.

-- 
#!perl -wpl # mmfppfmpmmpp mmpffm <pmmppfmfpppppfmmmf at fpffmm4mmmpmfpmf.ppppmf>
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}->(map{/p|f/i+/f/i}split//,$&)+97):qw(m p f)[map{((ord$&)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$&;$f.eig;                                # Jan-Pieter Cornet



More information about the MIMEDefang mailing list