On Feb 21, 2008, at 4:01 AM, Charles Lindsey wrote:
On Wed, 20 Feb 2008 18:30:53 -0000, Douglas Otis <dotis(_at_)mail-
abuse.org>
wrote:
And after all that waffle, you still have not answered the question.
Are you proposing the default is "s=*" or are you proposing the
default "s=SMTP" (since your message seemed to be proposing both).
The change in defaults was to meet your requested default. From your
comments, it would seem you view the policy scope statement
differently from what was intended. The view that SSP policy records
only pertain to SMTP related infrastructure, which includes messages
introduced into this infrastructure, would also be acceptable (When
disavow can be confirmed of course). There are other message
transports able to operate independently from SMTP and yet utilize
DKIM. It would help reduce DNS overhead combining DKIM policy records
for various independent protocols into a single record, while also
limiting exposure to abuse otherwise sent over disavowed transports.
Policy scope would permit fully independent protocols a means to
assert both protocol support and the application of DKIM policy
against the protocol. This scope statement could thereby block
possible vectors of abuse. The policy scope would provide an
incentive for domains not implementing DKIM to assert a policy scope
just to disavow use of a protocol at an existing domain to mitigate
traffic that distributed spoofing might otherwise create.
The scope parameter offers three states:
1) Status Quo,
2) DKIM policy Applies to the specific transport protocol carrying the
message,
3) Transport Protocol Disavowed.
In the case of another protocols bridged into SMTP, the policy defined
for SMTP would apply. The policy scope does not refer to transports
being bridged into SMTP, expect at the bridge when the transport
itself has been disavowed.
But as for publishers of SSP records, the stricter the policy they
declare, the more careful they must be that users of their domain,
are not able to bypass the signing mechanism by using strange
protocols/whatever. How they do that is their problem. So if they
publish "s=*" (or if that is the default), then they are saying that
if anything arrives looking like an RFC 2822 message from our
dopmain, but unsigned, then you should reject/discard/suspect/
whatever it.
Agreed. But requiring an explicit restriction would minimize the
number of domains astonished by the impact of the policy. When too
many make a mistake using the default, then the default assertion has
little meaning. As such, in the long run, it would be safer to
require restrictions for other protocols be expressed explicitly.
But if they publish "s=SMTP" and something leaves their domain via
UUCP/NNTP/whatever-else, then they are saying it is OK not to be
signed.
When messages enter into infrastructure supporting messages normally
carried by SMTP, then the policy defined for SMTP should be used.
This may block messages from other transports integrated into SMTP
related infrastructure. When NTTP messages never touch SMTP
infrastructure, and the policy scope is s=SMTP, then NTTP messages are
excluded from assertions of being signed. This default would create
less astonishment, and not affect NTTP messages that are handled
separately from those related to SMTP.
But then it it gets gatewayed back into SMTP, verifiers may not be
able to tell that it was not SMTP originally, and so will still
reject/discard/suspect/whatever it.
Yes. When a message is carried over SMTP, there is nothing
differentiating the messages from the perspective of the recipient.
When the recipient uses a different client for different transports,
or when messages carried over different transports are delivered to a
different location, then explicitly indicating whether messages for a
particular transport are "all" signed would be highly beneficial.
Or if you intend that the "s=SMTP" is to be evaluated according to
the protocol by which it was received by the verifier, then it will
still be rejected/whatever, even though it legitimately left the
original domain unsigned via UUCP/NNTP;
When the domain also signs all messages carried by NNTP, then the
policy scope could be "s=SMTP:NTTP dkim=all". When it does not, then
"s=SMTP dkim=all" would accurately reflect that situation. When scope
is introduced after SSP is initially published, the scope default will
need to be "s=SMTP".
is the gateway supposed not to have gatewayed it in that situation.
All you have created then is a glorious opportunity for everyone to
blame everyone else for preventing the mail from being delivered.
When protocol bridging is done internal to the administrative domain,
then Authentication-Results headers with the parameter Transport=<>
added could allow each message type to be handled properly and perhaps
delivered to a separate folder. DKIM in conjunction with SSP policy
may cause some of these protocol bridged messages to become blocked.
This is unavoidable. The policy scope would provide a means for this
problem to handled according to the assertions of the signing domain.
In short, the only thing which will work in the face of gatewaying
of any sort is to say that SSP applies to anything looking like an
RFC 2822 object, in which case you don't need an "s=" tag at all.
This would be assuming independent protocol transports are not using
DKIM. When different protocols are bridged into SMTP, of course
"s=SMTP" policy scope can be assumed.
Type of transport is always implied. Messages handled primarily by
SMTP transport, you would be absolutely right, SMTP is the only
assumption that should be made. DKIM can also be used by
independent and separate message transports protocols that are
completely unrelated to SMTP. In that case, the transport is also
implied, but it would not be SMTP.
And just what is all that supposed to mean?
Messages received by your IM client may implement DKIM over a
transport protocol unrelated to SMTP, where its messages are not
destine for a location also receiving messages carried by SMTP. At
some point in the future, the signing domain may wish to include more
than just SMTP within their assertion as to which messages are being
signed. As it is now, SSP policy MUST BE assumed to apply to those
messages related to the SMTP infrastructure.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html