Re: Make CSV backwards compatible with SPF?

Matthew Elvey <[email protected]> wrote:
> 
> Perhaps a CSV that was backwards compatible with a simple subset of
> SPF1 records would be useful. 

   I don't wish to support or oppose this; but some discussion might
be helpful.

   Hopefully we can agree (for purposes of this discussion anyway)
that the subset should be small. At first blush, there are exactly
two useful cases:

- "+a -all"

- "-all"

   The first says that the exact list of address records (ipv4 or ipv6)
are all authorized to act as MTAs using this domain string as the
EHLO parameter; the second says that no host is authorized to use this
domain string as the EHLO parameter.

   In the first case, another DNS query for the address records would
be needed, which immediately raises two questions:

- is the response going to fit in a UDP reply?
  If not, we add a lot of complexity, and problems with (poorly configured)
  firewalls could be an issue.

- is the response going to return a complete list of address records,
  or are we facing a specialized DNS server which returns partial lists?
  If so, the situation is hopeless: we'd need to forbid this.

   IMHO, the "+a -all" case is a bad deal for CSV unless we define that
the response MUST be the complete set and MUST fit in a standard-size
UDP reply.

   The second case looks more useful: people _could_ publish wildcard
TXT records to forbid a wide variety of subdomains as EHLO parameters.
My personal thinking is that what we actually want is better accomplished
by wildcard suggested-service PTR records; but I don't want to rule out
other options.

   It's worth noting that CSV doesn't _need_ a way to publish prohibitions
in order to accomplish its purpose. There _will_ be many domains without
CSV policy published: if these domains only use IP address ranges with
no history of email abuse, there's no reason they _need_ CSV authentication,
authorization, and accreditation. CSV's great benefit is its ability to
quickly disseminate accreditation information which is both positive and
dependable.

   I agree there will be domains that want to make the prohibition of
use of any subdomains as EHLO strings; and it _might_ be conceptually
easier for managers of those domains to understand the use of SPF1 -all
records for that purpose.

   (My thinking for such domains has been to _not_ publish a CSV SRV
record, but publish a wildcard CSV PTR record with a target which will
recommend _against_ trusting MTAs using that EHLO string.)

--
John Leslie <[email protected]>