ietf-dkim
[Top] [All Lists]

[ietf-dkim] We need a BCP (was: lookalike domains ...)

2008-05-02 03:13:22
On Thu, 01 May 2008 16:09:53 +0100, Steve Atkins <steve(_at_)blighty(_dot_)com> 
wrote:

Nobody has answered the basic question of what harm would be caused
with the text being left in.

It makes the spec significantly less clean, as it stops being about
anything DKIM related and starts redefining how SMTP works. For a BCP
that wouldn't be a problem (as the practices it's suggesting are, IMO,
"best" in at least that specific case) but stomping on the toes of
unrelated standards is an issue for a standard.

Fine! Then let us write a BCP.

It could be a separate BCP draft specifying "Best Practice" for Verifiers  
who wished to take advantage of ADSP.

Or it could be a distinct section within the ADSP draft, clearly marked as  
being Non-Normative but nevertheless describing Verifiers "Best Practice".

In either case, it could still use RFC 2119 language "MUST" and "SHOULD",  
but with a clear proviso that those REQUIREMENTS/RECOMMENDATIONS were only  
obligatory for a Verifier who wished to claim "Compliance with this BCP".  
A Verifier would remain free to do whatever he saw fit (as at present),  
provided he did not claim to adhere to the BCP.

And the BCP would not be applicable at all to receivers who did not take  
notice of ADSP at all (so it is not a "behind the scenes" attempt to  
change basic SMTP).

Proper topics to be discussed within this BCP document/section would  
include
1. The extent of treewalking to be done (if any), and the consequences for  
cousin domains.
2. What to do about non-existent domains (if anything), including just how  
"non-existent" was to be defined.
3. What addresses were to be checked for ADSP compliance (currently, we  
have every address in the From header).
4. All other things Verifiers should or should not be doing.

And everything regarding Verifiers would be removed from the ADSP draft  
(or from the Normative sections thereof). The (normative parts of) the  
ADSP draft would be limited to

1. Describing what was to be contained in the ADSP records.
2. Which domains and subdomains should have them
3. Possible requirement that MX records MUST be provided alongisde ADSP  
records.

And, of course, the contents of the normative ADSP draft and the  
non-normative BCP draft/section would be carefully coordinated to  
interoperate with each other (so as to a provide well-understood treatment  
for cousins).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html