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 _______________________________________________ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
