On Jun 11, 2008, at 12:00 PM, Frank Ellermann wrote:
Douglas Otis wrote:
Which TLDs should be ignored?
It's up to the implementors of the proprietary mail exchange you
have in mind to get this right, if they wish to implement the
Internet message format they will find some fresh specifications in
2822upd and RFC.ietf-usefor-usefor.
ADSP also purports as being applicable at MUAs. As such, this issue
is not limited to any specific protocol, proprietary SMTP or otherwise.
Do you agree there should be a means for making exceptions?
Do you agree that implementation details don't belong in an RFC, and
that this is no rocket science?
An algorithm that necessitates exceptions to retain operability for
crucial systems, should at least declare the necessity in the draft.
Specific details of a general mechanism would not be included, except
perhaps as example code.
MS Exchange is considered stupid
Allegedly it is now even possible to get a complete mail header. RFC
4871 didn't discuss this, ADSP also doesn't need to discuss it, it's
an implementation detail.
Disagree. Unlike DKIM (RFC4871) where use is self evident, a practice
assertion must declare which transport protocol is covered. Otherwise
it is impossible to discern specifically what is being asserted. Are
messages signed for SMTP, or NNTP, for example.
IMHO, a draft defining what might be an SMTP domain should exclude
AAAA from a list that provides confirmation of SMTP support.
In the great 2821bis flamewar some weeks ago some folks agreed to
address this issue in a separate draft.
It seems ADSP should also suspend efforts in how to validate a domain
and move this to a separate draft.
Judging by the growing impatience, this strategy should be
published in a separate draft from that of ADSP.
Yes, please move this part to the SMTP list. And if you want a
bunch of reserved TLDs check out that the 2606bis draft has all you
need for this business.
While 2606bis has expired, at least RFC2606 should be referenced in
the separate effort. The otis-dkim-adsp draft will be modified to
reflect adoption of a separate strategy. Of course, this is not the
WG document.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html