David MacQuigg <dmquigg-clear(_at_)yahoo(_dot_)com> wrote:
The main issue is whether we should include an MTA action other than
'ACCEPT', 'REJECT', or 'TEMPFAIL'. I guess I should have said that this
routine is to be called *after* it is known that the sender offers CSV
authentication. In that case it makes sense to reject when the promised
CSV records are not there.
My preference would be to have this routine return the "unknown"
result, documenting that an "unknown" result for a domain which promises
to maintain CSV records should probably be cause to reject the email.
(This, of course, creates an overlap with weight==3...)
That still leaves the "weight==3" case, which I did not know about, and
don't understand. If a sender can't make a clear statement as to the
authorization of all servers with A records under a name that he chose, I
don't see any value in having CSV records for those servers.
From the standpoint of the CSV spec, it's legitimate to say that the
HELO name is authorized, even if the full list of IP addresses cannot
be returned in a single DNS response. An example would be special-purpose
DNS servers which return different lists (not just differently-ordered)
lists depending on topology, time-of-day, or other criteria.
We certainly did not intend to recommend such a practice; and I would
certainly agree it does not meet the reasonable expectations of a promise
to publish CSV for a domain -- since there are a number of simple ways
to avoid situations like this. The CSV _spec_ nonetheless intends to
absolutely minimize the changes to current email policies (which in many
cases are IMHO excessively bureaucratic).
Thus it would be entirely reasonable for _you_ to recommend rejection
of email from a sending SMTP client using a HELO string which leads to
a weight==3 SRV response.
We can certainly add an "unknown" action to our list, and let receivers
decide what to do,
That is my recommendation.
but I would much rather have a simple script returning a clear
recommended action. SPF suffers from this kind of ambiguity, and I
thought CSV was supposed to avoid it.
It is impossible to avoid all ambiguity in email. CSV is supposed to
enable unambiguous declarations, not require them.
If a sender promises CSV, then can't be definite about his CSV
authorizations, he shouldn't get any advantages from "offering" CSV.
The spec cannot assume the sender has promised anything. The situation
becomes entirely different when such a promise exists; but this is
out-of-band to CSV. It is better, IMHO, for a "CSV implementation" to
return the "unknown" result.
Note also that all *actions* are ultimately the choice of the receiver.
I totally agree. I just find it easier to keep "implementations" of
CSV within the paradigm of CSV, which intends to offer a benefit to
those who publish CSV, not a punishment to those who don't.
--
John Leslie <john(_at_)jlc(_dot_)net>