PTR records for IPv6

[Phil Pennock]

On 2013-09-02 at 04:53 +0200, flavio-cluenet at zipman.it wrote:
> 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.

To an extent, it is.  The IPv6 approach avoids NAT in scenarios where
NAT would be the norm in IPv4.

I see Lorenzo's point and am mulling the implications of changing Exim
so that, when matching forward/reverse DNS, *if* the forward address has
an AAAA record where the last 64 bits are zero, and treating the record
as a /64 mask yields a match against the IP input into the reverse DNS
lookup, then this should be treated as a match.

Are there any real-world addressing examples where the lowest 64 bits
are zero but the address is of a host, not a network?  Absent that, the
_intent_ of such an AAAA record is clear, even if DNS purists might take
umbrage.

It only ever conveys the policy intent of the origin netblock owner, and
recipient systems will still do things like look for fixed patterns and
reject hosts with certain sub-strings in DNS and whatever other
heuristics are currently in vogue.  I'd have to provide an option to
turn the support _off_, but I'm not spotting any major issues yet.

> 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.

So you continue to use _distinct_ matching forward/reverse DNS, and are
unaffected by the change.  Besides, large provider reputation systems
already consider "network neighborhood" and, if they don't see enough
mail from your v4 /32, will use the reputation of the larger block.  The
only way to counter that is to provide more intrinsically attached
identifiers which reputation can hang off: so use DKIM.

Where your mail-server is, and what the other systems in your /24 are
doing, _already_ affects your deliverability unless you're managing to
send so much ham (and only ham) that you stand out as a shining example.

-Phil