On Jun 5, 2008, at 2:41 PM, Damon wrote:
OK. Now that isn't going to happen. Let's be realistic. Anything
short of aliens landing in Miami is going to get something like this
into or out of Lotus Notes some time this century. (And sadly I am
being realistic here)
Saying that we ignore these systems because they haven't followed
the rules just disenfranchised a large enough piece of the pie for
this scheme to be called unworkable.
Precautions required for non-SMTP transport may involve the imposition
of domain specific exceptions. In cases where there might be a mix of
private/public name space, the exceptions would be only for a few
specific domains. Such an effort does not seem impractical,
especially when such domains are likely well known by the enterprise
making use of non-SMTP transports. Domains desiring that their NNTP
messages can carried over SMTP via a protocol gateway may find greater
acceptance by accommodating SMTP responses against their domain. In
most cases, this is likely already the case. Establishing provisions
for such exceptions seems realistic. It would be true that without an
exception provision, validating the absence of ADSP records may
disrupt the exchange of non-SMTP messages, such as those for MS
Exchange.
However, validating the absence of ADSP records for a domain is:
1) not required.
2) not needed for private messages from known sources exchanged over
non-SMTP transport.
3) likely already accommodated by SMTP as an alternative transport.
This is not attempting to disenfranchise any non-SMTP transport.
However, ADSP should be upfront about the potential disruption it may
cause when provisions for exceptions are not available. A disruption
of non-SMTP transport conversions will be caused when either
validating the absence of ADSP records or by imposing a CLOSED practice.
The DKIM WG has a few choices:
A) State that ADSP only applies to SMTP and indicate ADSP does not
prevent sub-domain related abuse. This approach should also
specifically exclude attempts at validating the absence of ADSP
records. (An approach that several have suggested.)
B) State that the absence of ADSP records should be validated by the
presence of SMTP resource records. This approach offers significant
and immediate benefits, however this also necessitates a means to make
domain specific exceptions.
C) Don't state what transport is involved, and then suggest the
absence of ADSP records might be validated by either the presence of
SMTP resource records or the lack of NXDOMAIN. This approach offers
few benefits, fails to confirm SMTP support, and fails to clarify what
exceptions would be needed to prevent the disruption of non-SMTP
transport.
Either A or B approach would be okay. Attempting approach C has the
potential of truly disenfranchising several non-SMTP transport users.
It seems approach C is now being attempted by the WG ADSP draft.
IMHO, approach B offers the greatest benefit over the long term.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html