Christmas spam from RESERVED IANA adressblock ?
mysidia at gmail.com
Thu Dec 25 00:33:48 CST 2008
On Wed, Dec 24, 2008 at 11:38 AM, Scott Morris <swm at emanon.com> wrote:
> I would guess (hope?) that most, if not all, providers filter the RFC1918
> space addresses from entering or leaving their networks unchecked. But just
> my two cents there...
All sites (not just providers) should, but many just don't do what they should.
In some cases it may not even be practical for people to do what they should
(due to poor software/hardware, or the poor availability of IPv4 addresses)
RFC1918 addresses should also never be found in mail headers of any
messages being exchanged over the internet.. For the very reason that it
creates this confusion. Another case of many implementations not doing
anything close to what they should.
RFC1918 says on page 4:
" Indirect 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.
Private IPs in mail headers are just fine inside the enterprise, but messages
with headers referencing private IPs should not be exchanged over the
RC1918 specifically says indirect references should not leave the enterprise.
The only thing that would be worse or more confusing to other sites would be to
not add a mail header at all, or to use a real IP address shared by other hosts
that use 1918 addresses on the LAN.
Mail servers that deal with internet mail should always add headers
that contain a distinct public IP address that belongs to that mail server,
for distinctively showing any abuse or mail server problem,
even if all access to that public IP is actually blocked by a firewall.
Not sharing mail server public IPs isn't part of the RFC1918 though,
it's just the right way(TM).
More information about the NANOG