John Glube <jbglube(_at_)sympatico(_dot_)ca> wrote:
"'John Leslie'" <john(_at_)jlc(_dot_)net> [wrrte:]
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).
If we accept the position of separate DNS records for each
protocol, can you elaborate on the controversy as you see
it?
The controversy is pretty quiet actually; but the pain level is
obvious. Any number of people would like to avoid the MARID WG
recommending publication of multiple records.
Prior to the present draft of the Marid protocol, marid -
appropriate DNS records were published using v=spf1 in the
DNS IN TXT file.
A receiving MTA could either with or without Submitter:
* Use these DNS records to run an SPF check, although not
specified in the Marid core protocol;
* If a negative result was returned, reject the message and
send a rejection notice in accordance with the SPF protocol;
This could be done at the DATA stage, so arguably saving
bandwidth?
I'd rather not get into that argument. Regardless of bandwidth
savings, an error returned during the SMTP connection is "better"
because it's more likely to reach a responsible party.
* If a pass or neutral result was returned, proceed to
'swallow' the message and run a Marid core check.
This gave the receiving MTA the benefit of SPF, along with
PRA checks.
Under the present draft of the Marid protocol, marid -
appropriate DNS records should be published using
v=spf2.0/pra in the DNS RR type SPF2 file, although the
^^^^^^^^^^^^
Mark already corrected me on that: there is in fact no "v=".
protocol does allow for TXT type records in the SPF2 file.
Yes, it should be understood that SPF2 is a "text" type, and
most domains will publish TXT RRs as well as SPF2.
However, by changing the version string, although the
receiving MTA may decide to extract the domain in SMTP mail
from and run a check against the SPF record in the DNS IN
TXT file, if the domain has not published an SPF record,
because it is not required:
* Have we lost the potential optimization which was
previously available?
I'm not clear what "optimization" you mean, but we've probably
lost it.
* Does the optimization suggested by Chris in his note to
Margaret, based on his offline discussion with Mark fully
replace this earlier optimization?
I'm not sure I understand what you refer to here. The obvious
sentence is:
]
] The optimization derived from using MAIL-FROM is the opportunity to
] fetch and start testing the record, in the hope that, when the PRA
] is eventually determined, the correct record is found to have been
] used.
This seems to imply that sender-ID checks could be run against
the MAIL-FROM when there is no submitter _before_ accepting the DATA.
I don't believe this is recommended in any of the current MARID I-Ds
(though it isn't actually prohibited).
The potential for saving any appreciable bandwidth escapes me,
unless we're talking about serious tar-pitting, which IMHO is quite
out of scope for MARID discussions.
Somebody may have an opinion on whether this replaces the earlier
optimization, but I certainly don't.
It seems it could, but only if the domain extracted from
the SMTP mail from is the same as the purported responsible
domain as identified in the marid appropriate DNS records?
It's more restrictive than that actually. Only if the PRA turns
out to be exactly the same as the MAIL-FROM are you on safe ground.
(There is some hand-waving about cacheing SPF2 results if no macros
are involved...)
Is this the controversy you speak about, or is it something
else?
No, this is not what I spoke of.
The visible part of the iceberg of controversy is the numerous
occasions where the CSV folks have been asked why the SPF record
isn't "good enough" to serve the function of the CSV SRV record.
Also, there has been _extensive_ discussion of whether we actually
need to change the version string when moving from SPF to caller-ID.
That's the controversy I refer to.
--
John Leslie <john(_at_)jlc(_dot_)net>