[Mimedefang] filter snippet to reject sender addresses with bad MXentries?
Kevin A. McGrail
kmcgrail at pccc.com
Sat Apr 2 10:51:43 EST 2005
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
----- Original Message -----
From: "Albert Croft" <acroft at cyber-wizard.com>
> Recently, I set up a sendmail/MIME-Defang/SpamAssassin/Razor installation
> to act as a spam gateway/filter for several domains. From time to time I
> have noticed emails using sender addresses whose MX point to addresses in
> the localhost (127.0.0.0/8 ) or localnetwork ( 0.0.0.0/8 ) ranges,
> RFC-1918 private network space, or other address space that should not be
> appearing. I would like to reject these as early as possible, and have
> been looking for code to do so since my earlier posting to the list
> (18-March-2005).
>
> I had hoped there would be a good example of code to do this already, and
> if so, I would appreciate it if someone could point me in that direction.
> In the mean time, I hacked together the following variation of the code
> segment from the CheckforMX entry on the Wiki, and would appreciate any
> feedback regarding the code segment (as I have NOT had the opportunity to
> test it completely, or to put it into operation yet).
More information about the MIMEDefang
mailing list