Kaz's questions

I'm skimming through some IPv6 related RFCs. Some claim that a prefix should be written outside of the square brackets, whereas others have it tacked on to the address directly.

Specifically, RFC4291, section 2.3 has it like this:

For example, the following are legal representations of the 60-bit
prefix 20010DB80000CD3 (hexadecimal):

   2001:0DB8:0000:CD30:0000:0000:0000:0000/60
   2001:0DB8::CD30:0:0:0:0/60
   2001:0DB8:0:CD30::/60

But then RFC4038, section 5.1:

Therefore, the IP address parsers that take the port number separated
with a colon should distinguish IPv6 addresses somehow.  One way is
to enclose the address in brackets, as is done with Uniform Resource
Locators (URLs) [RFC2732]; for example, http://[2001:db8::1]:80.

Some applications also need to specify IPv6 prefixes and lengths:
The prefix length should be inserted outside of the square brackets,
if used; for example, [2001:db8::]/64 or 2001:db8::/64 and not
[2001:db8::/64].  Note that prefix/length notation is syntactically
indistinguishable from a legal URI; therefore, the prefix/length
notation must not be used when it isn't clear from the context that
it's used to specify the prefix and length and not, for example, a
URI.

Are they both right?

Does IPv6 address parsing have to support the additional complexity of the prefix being either on the address directly, or else outside of the square brackets that are used for URL embedding?

The requirement in RFC4038 5.1 looks like an intellectual gaffe. Why would the slash not stay with the address and instead go outside of the nicely enclosing, disambiguating square brackets, where it then creates ambiguity due to that character being a path component separator in URLs?

Is it not the case that the problem described by the closing sentences above:

[T]herefore, the prefix/length
notation must not be used when it isn't clear from the context that
it's used to specify the prefix and length and not, for example, a
URI.

is solved by putting the slash inside, like in RFC4291?

I run a very good anti-spam setup, except for one nagging little problem: Google.

Some legitimate users use Google's mail service with custom mail domains. In other words, they do not use a [email protected] sending identity, but their own.

I find that almost all SMTP traffic from a mail*.google.com host which is not from a @gmail.com sender, however, is spam. There is not a lot of it, but it's a nuisance.

These mails with custom domains don't seem to have any clue as to the Google identity of the originating user, so it is impossible to report the user to Google. You also obviously can't just blacklist Google servers because it's a very popular e-mail service with a large number of legitimate users.

(Of course, a [email protected] sender could also spam, but that doesn't seem to be a big problem at all; I can't remember the last time I saw a spam that directly identified a gmail account in any way. That makes me unconcerned about @gmail.com senders.)

Is there some good way to block the spam (ideally reject it at the SMTP level, without even looking at headers), while avoiding false positives: blocking non-spamming owners of custom mail domains who use Google for sending mail?