On Fri, 2004-09-17 at 13:22 -0400, Meng Weng Wong wrote:
isn't that why the standards track is a standards track and
not a standards point?
if we expect it will take 1 to 3 years for the world to
upgrade, maybe we can take 1 to 3 years to move from
proposed standard to draft standard to standard.
An excellent idea. Then shall we settle upon the following:
While SRS is not officially documented or is merely a proposed standard,
the language should be that you 'MUST NOT' publish a record ending in
'-all' for a domain which does actually send mail.¹
When SRS becomes part of a draft standard _and_ is widely implemented,
that can be relaxed to 'SHOULD NOT'. Finally when SRS becomes part of a
real standard, the restriction can be relaxed entirely.
That's my preference -- to save unnecessary amounts of email being
traded back and forth, let me save time and draw up a table of what I'll
admit up-front that I'll reluctantly fall back to under pressure :)
SRS status Preference Acceptable
--------------------------------------------
I-D or less MUST NOT MUST NOT
RFC MUST NOT SHOULD NOT
Proposed Std. MUST NOT SHOULD NOT
Draft Std. MUST NOT SHOULD NOT
Draft++ SHOULD NOT MAY
Standard. MAY MAY
Note the 'Draft++' state indicates a state where SRS is both a Draft
Standard and _also_ is found to have widespread implementation.
Also note that the same set of requirements is appropriate for PRA
w.r.t. the addition of whatever replaces the Resent-From: header.
However -- unless I'm mistaken, the MARID drafts don't actually document
SRS, while they do document the requirement to add a header when
forwarding. So the language in the marid-pra draft would be tied to its
_own_ progression through the standards-track, while the language in the
marid-mailfrom draft would be tied to the progress of something else
which does not yet exist. While that's unfixed, we remain on the first
line of my table above.
I consider the lack of documentation of SRS (or indeed of any other
mechanism which must be implemented to correct the flawed assumptions of
the original SPF) to be a serious technical omission in the current
marid-mailfrom draft.
The PRA folks have documented the required fix for _their_ flawed
assumptions, and once the choice of header is fixed it's not so onerous,
so it stands a reasonable chance of getting deployed and hence fixing
their assumptions. The mailfrom folks desperately need to catch up.
--
dwmw2
¹ I'd also accept qualifying this with "unless the previous mechanisms
do not depend on the deployment of SRS". For example, if I were using a
stunt DNS server in conjunction with the 'exists' mechanism and my
existing BATV implementation, or if I were using marid-mailfrom simply
to publish a list of 'acceptable' localparts for my domain without any
IP-based restrictions, then the
use of '-all' would make sense even today.