PTR records for IPv6

[flavio-cluenet at zipman.it]

Lorenzo Colitti wrote:
> To 2001:db8:cafe::. Then we can modify SMTP servers and spam systems to
> look at only the first 64 bits and we sort of have parity to what we
> have today.

No, it's not the same. It would be as having a wildcard on a class C
address space: a non sense on IPv4 and little sense with IPv6.

> Of course, if people put multiple customers on the same /64 then those
> customers can influence each other's reputations. But this is no
> different to what happens today to customers on the same public IPv4
> address (e.g., shared hosting, SMTP relay).

I think it's really different. Having more services or more customers on
a single IPv4 address is a "workaround" to eliminate the need of
multiple (now rare) addresses, while more customers on a /64, each one
with it's own IPv6, is common and can even be considered a "best practice".

For example in one of my postfix installations I use one IPv6 for each
of the hosted mail domain, and I absolutely don't want that the
reputation of one domain can influence the reputation of the others
(otherwise I'd have used a single IPv6 address and a simpler setup).
The antispam systems must take into account such (common) setups.

DNSBLs already provides means to list single IPs or entire networks both
for IPv4 and IPv6.

Wildcard PTR can (and should) be used by providers on the nets assigned
to customers, just to simplify the task to identify the connections
(exactly the same that happens today with the *.dynamic.* names assigned
to dialup, adsl, etc.).
On service networks instead each service should have a correct PTR and
wildcards should be avoided.

Going back to the topic, when it comes to SMTP (rfc5321) the existance
of PTR is not strictly required, but, as stated in 4.1.1, in absence of
reverse mapping the client should use an address literal in the
helo/ehlo phase instead of an fqdn.

-- 
Flavio Visentin

A computer is like an air conditioner,
it stops working when you open Windows