[Mimedefang] filter snippet to reject sender addresses with bad MX entries?
Albert Croft
acroft at cyber-wizard.com
Sun Apr 3 07:29:13 EDT 2005
Kevin:
I appreciate the feedback. Those were some of the kinds of insights I
was seeking.
As far as a gateway machine as viewed from an internal network, it is
understandable that the internal machines might be provided a DNS view
containing addresses in the privativized ranges, but as those ranges are
not to be visible to the outside world [1, 2], I would think that the MX
provided for a domain to the outside shorld point to a valid IP address.
However, I know the real-world sometimes doesn't agree with the written
standard, and thus will look seriously at setting up a rule or logging
in some form to record statistics to see how much impact it may have
should I do something along these lines.
In addition, in testing the address you commented on, you also provided
me a test case that showed a fault in my code for the case of a
non-existing hostname. Thank you for your time, and the insights you
provided.
-Albert C.
-----
[1] RFC-1700 states that 127.0.0.0/8 refers to an "[I]nternal host loop
back address. Should never appear outside a host," and that 0.0.0.0/8
refers to a "[s]pecified host on this network" and "[c]an only be used
as a source address." ( ftp://ftp.rfc-editor.org/in-notes/rfc1700.txt ,
pages 3, 4 )
[2] RFC-1918 states that "[b]ecause private addresses have no global
meaning, routing information about private networks shall not be
propagated on inter-enterprise links, and packets with private source or
destination addresses should not be worwarded across such links" and
that "[I]ndirect references to such addresses should be contained within
the enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private addresses.
In particular, Internet service providers should take measures to
prevent such leakage." ( ftp://ftp.rfc-editor.org/in-notes/rfc1918.txt ,
page 4 )
>Message: 8
>Date: Sat, 2 Apr 2005 10:51:43 -0500
>From: "Kevin A. McGrail" <kmcgrail at pccc.com>
>Subject: Re: [Mimedefang] filter snippet to reject sender addresses
> with bad MX entries?
>
>Albert:
>
>While I am fairly certain the action below is justified by a strict
>interpretation of the RFC, I think you will find that in practice it will
>have too high of a false positive except perhaps on the 127.0.0.0 test.
>
>However, one more caveat, I believe some customer support companies use the
>127.0.0.0 trick when they send out things like
>do_not_reply at dontreply.ebay.com. Again a false positive concern.
>
>I can't comment on the local network 0.0.0.0/8 as I have no idea about that
>network space having never used it, at least knowlingly.
>
>Finally, I've seen (and setup) many a gateway that uses DNS to route mail
>using MX records that included privatized ranges. This is, in fact, one of
>the default recommendations for Symantec AV for SMTP and it's predecessors
>which are in fairly wide use.
>
>Therefore, I would recommend using this type of test to add a header that
>you make a rule in SpamAssassin for and then track the impact it would have
>on the mail.
>
>Regards,
>KAM
>
>
More information about the MIMEDefang
mailing list