John Glube <jbglube(_at_)sympatico(_dot_)ca> wrote:
* Based on the newest drafts, is it correct to state that
Sender-ID will only read the spf/pra02 version string.
Except for the spelling, which is "v=spf2.0/pra", yes.
* Prudent senders will therefore have to publish a v=spf1
version string in the TXT record and spf/pra02 in the DNS
RR type SPF2.
I have no opinion on whether spf1 check_host() will ever read something
other than TXT records; but this is a likely scenario, yes.
* Will Submitter compliant Senders only use Sender, or will
you want to include SMTP Mail From in case the receiver
can't read Submitter and is only using SPF?
These seem to me to be quite separate issues; but no doubt some will.
* Would the best practice be to have the domain in Sender
and SMTP mail from the same?
I have no opinion.
* What about CSV?
There, I _have_ an opinion. ;^)
Should prudent senders also be publishing the version
string for CSV?
So far, I've been telling people to stay tuned: I'm not yet sure
whether the format of CSV publishing in draft-ietf-marid-csv-csa-01.txt
will be the final output of this Working Group.
But once we agree on the final format, yes, operators of MTAs should
IMHO be publishing CSV as well as Sender-ID.
CSV will verify that the MTA is specifically authorized to act as
a SMTP client, in such a manner that reputation services can closely
track whether the domain publishing CSV record(s) has policies and
practices which minimize email problems such as spam and viruses; and
reputation reports can quickly reflect both problems and their
resolutions.
So, IMHO, anyone wishing to publish Sender-ID records _should_ also
be publishing CSV (once we've agreed upon it, of course).
How will Submitter compliant senders relate to receivers
for example who are using CSV and SPF, but not Sender-ID
for licensing reasons?
At first blush, I'd assume they'll simply continue publishing CSV
and "v=spf1". (It's nearly certain there _will_ be such receivers.)
I raise these questions as:
* The WG has apparently decided to go down the consecutive
as opposed to the concurrent path.
This is clearly what the Chairs are asking us to do.
* This means each protocol will use its own version string,
as opposed to one version string serving all protocols.
That seems hard to avoid...
* We are now confronted which inter-operability issues, so
making things even more complex.
IMHO, inter-operability is probably easiest this way.
* These are questions which need to be answered.
I really don't think the answers I've given are controversial.
What is controversial is that we find ourselves complicating the
task of publishing MARID-appropriate DNS records (which is quite
contrary to the original aim of SPF).
In my view, while it is all very nice to say:
* Sender-ID will only read sender-id records and CSV will
only read CSV records,
We need to ensure a sender can transmit to someone who is
relying on any one or more of:
SPF, ...
Sender-ID and CSV, ...
Otherwise we will end up with a mess.
The current path, with three different records being published, is
fully workable; and IMHO is nothing to be ashamed of as Working Group
output.
--
John Leslie <john(_at_)jlc(_dot_)net>