[SHAME] Spam Rats

Mailman List Mirror (Read Only)
41

Hi Julian,

A couple of thoughts for you:

1. Spam Rats is a non-entity and anyone blocking email solely on Spam
Rats' information is a fool. You can't be responsible for what every
damn fool does on the Internet, so if the problem is that the customer
sending small amounts of mail has run afoul of a single fool, you
should consider limiting your efforts to helping the customer get in
touch with that fool.

2. If the customer sending small amounts of email decides that
blocking of multiple mail destinations is because of Spam Rats,
they're almost certainly mistaken. Not about being blocked, but about
the cause. Find out what's really going on.

3. If the customer is sending mail without a valid PTR record then
they're probably on lists similar to rfc-ignorant as well. Check in to
it. And help them fix the PTR record.

4. If the customer is sending enough email to find multiple folks
relying on Spam Rats' information and they're doing it without having
asked for valid PTR records, that's enough of a red flag that it's
time for you to scrutinize just what email your customer is sending.

Regards,
Bill Herrin

42

FYI - I have a PTR for all IPs. Just general practice.

All IPs actually in use, or all possible IPs in a network? If the
latter, then it's not gunna fly for IPv6. Not at all. Not unless you
synthesise the responses - in which case there is no point to requiring
them anyway.

Regards, K.

$GENERATE, as someone else pointed out, solves that problem for you?
(Does it scale for IPv6? I can't recall - but surely this could be
scripted too.)

Mental exercise...

$GENERATE is a run-time macro which is parsed to create in-memory
PTR records for all included entries. The end result in memory is
identical to having typed in all of the PTR records in a zone file.

If you're running a 64 bit architecture, you can, theoretically, address
a 64-bit memory space. However, that would require each in-memory
PTR record to fit in 1 byte and you would have no room remaining
for little silly inconsequential things like forward zones, the DNS server
software, the operating system, the network stack, etc.

This assumes, of course, that you have maxed out your RAM to a full
18,000+ petabytes (which I tend to doubt).

If not, then, you don;t even have enough RAM for 1 byte per PTR record.

I know PTR records can theoretically be pretty compressible, but I doubt
you can get below 1 byte/record even with the best of compression algorithms.

Real time synthesis (synthesis on request) according to something similar
to $GENERATE might be feasible, but $GENERATE as implemented
does not scale to IPv6.

I though the point of doing so was to establish with some degree of
accuracy that there were 'real people' behind the administration of said
IP, and that there was a somewhat increased level of accountability as a
result - which suggests there is infact a point.

I'll leave the flaws in that theory as an exercise to the reader.

Owen

43

*.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se.

...will work just fine, for instance.

Since there is no AAAA record for a.node.on.vlan344.namn.se., this
won't work fine in any rDNS check I'm aware of.

You are aware that useful rDNS has to have matching forward DNs, right?

44

IMHO mail is one of the easiest "first things" to turn on for IPv6.

You can certainly turn it on, and it will work at the current toy
scale, but nobody has a clue how we're going to scale IPv4 spam
management up for large scale IPv6. Anything that's obvious won't
work.

45

It isn't a complete solution by itself, but SPF hardly breaks a sweat with IPv6 and helps with maintaining domain-name based blacklists.

46

IMHO mail is one of the easiest "first things" to turn on for IPv6.

You can certainly turn it on, and it will work at the current toy
scale, but nobody has a clue how we're going to scale IPv4 spam
management up for large scale IPv6. Anything that's obvious won't

it works just fine.

I've been receiving spam over v6 for about 12 years at this point.

47

Unused space generally gets a $generate type generic scripted runs which
could be whatever, like ip-ad-dr-ess.example.com

Nothing that actually stores actual RRs will scale to the number of
addresses available in IPv6.

If you want a PTR for every possible address in your network, or even
just every possible address in a single /64 subnet then you are SOL as
far as IPv6 is concerned. The only way to do it is to fake it - for
example by synthesising responses on the fly. You can't cache the
synthesised responses either, that would be inviting a DoS.

I said this would be "pointless" because if providing RRs were as simple
as synthesising one on request, then the presence of a PTR record would
no longer be a meaningful indicator of cluefulness (not that it is now
IMHO, but opinions clearly differ on that).

As for v6 how popular do you see it getting for mail?

Well - at least as popular as IPv4 - eventually :slight_smile:

Regards, K.

48

Mail is all this discussion is in the context of

49

Date: 10 Jan 2013 20:57:25 -0000
From: "John Levine" <johnl@iecc.com>
Subject: Re: [SHAME] Spam Rats

>*.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se.
>
>...will work just fine, for instance.

Since there is no AAAA record for a.node.on.vlan344.namn.se., this
won't work fine in any rDNS check I'm aware of.

it works just fine, as long as there is one AAAA for that name (even in a
different netblock), and -that- adderess has rDNS matching the AAAA

You are aware that useful rDNS has to have matching forward DNs, right?

"Not exactly." <grin>

The 'usual' test is 'rev->fwd-rev' and compare the results of the two 'rev'
look-ups. This allows a host with multiple interfaces to have -one- name
for all interfaces.

50

Mail is all this discussion is in the context of

51

I believe it's relatively common for mail servers to just check the
existence of a PTR record without any further sanity checking, e.g.
Postfix's reject_unknown_reverse_client_hostname smtpd_client_restrictions
option.

Tony.