[Mimedefang] MX -> 127.0.0.1

[Kevin A. McGrail]

> Sorry, I'm coming a little late to this discussions, but I have
> a few hopefully useful suggestions.

Wow, what a great response, no apologies needed.  I'll go through it point
by point!

> Actually, "use Net::DNS;" should be at the top of your file, it doesn't
need
> to be in a subroutine (in fact, it's better not to). "use" is a compile-
> time statement, not a runtime statement.

>From my perspective, it's really just a coding-standard but understand what
you are saying and will move on.

> 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.

> - in case there's no MX record, you can just take the domain itself
>   as a degenerate form of MX host, and look for the A record of that.
>   This behaviour is actually a backward-compatible form of mail sending
>   from before MX records were invented. It's still used occasionally.

I actually allowed this with the implicit acceptance of unchecked answers
but I have added a check for the implicit A record as MX

> - 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.

> - you don't handle domains with mail exchanges only reachable via IPv6.

Since I am implicitly accepting unchecked answers, I believe this is OK.
However, I have no access to IPv6 and no way to work on this.

> - 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.

> - 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?

> - 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?

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

> - 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?

I've started adding error messages so they can be passed back to the user.

> - We test the MX records per preference level, in order. The first set
>   to return an "OK" status aborts the search. At the "most preferred"
>   (lowest-numbered) level, we do allow for private IP space or
>   non-existing hostnames, but the overall check will only succeed if
>   there is another set of lower-preference MX records with valid IP
>   addresses.
>
>   The idea here is that this setup would "commonly work" and we're able
>   to connect back to some MX records to deliver bounces, if any.

If you were to fail on internal network tests, this is the only way to go.

> - Finally, we test inside filter_sender, HOWEVER we don't generate
>   an error until filter_recipient, and we explicitly exclude a few
>   recipients (like abuse@) just in case our logic is wrong or someone
>   really feels they should be able to mail us from a domain with
>   invalid MX records.

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.

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

Regards,
KAM