On Feb 20, 2008, at 3:41 AM, Charles Lindsey wrote:
On Fri, 15 Feb 2008 19:27:29 -0000, Douglas Otis <dotis(_at_)mail-
abuse.org>
wrote:
On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote:
On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org
wrote:
s= Policy Scope (plain-text; OPTIONAL; default is "SMTP"). A
colon-
No! The default must be '*'.
The concern regarding defaults was addressed in Take #3. This
version includes a means to exclude policy.
And indeed Take #3 starts:
s= Policy Scope (plain-text; OPTIONAL; default is "*").
so it seems my point is accepted.
* matches against all unlisted transport protocols
! disavows protocol use
- excludes protocol from policy assertions
I suspect the default should be "s=SMTP" where this would be the
same as "s=SMTP:-*". When the domain exchanges no communication
whatsoever, "s=!*" could be used. When only SMTP messages are
used, then "s=SMTP:!*" would make this assertion.
But now you are contradicting yourself. First you say 'default is
"*"';
now you are saying 'I suspect the default should be "s=SMTP"'. Which
is it?
The policy assertion of "s=*", this would mean that other protocols
might be affected the publisher did not expect. Rather than
potentially blocking other protocols, an assertion of "s=SMTP", as a
default, would require publishers to proactively make explicit
restrictions on other protocols. From the comments on this list, it
seems most view the policy record as being related to messages
entering the SMTP related infrastructure. In that respect, the SMTP
policy would be applied anyway. Having this policy record impact
fully independent and separate message transports seems as though it
should be explicit. Having an explicit policy will also allow the
verifier to better trust that this restriction was the intent of the
policy. Trust in assertion is important.
But you have to make it clear that verifiers can only discern the
protocol used by the originating site by carefull examination of
Received headers (and believable ones at that). So I am still very
dubious about adding this feature.
Trace headers can not be included within DKIM signatures.
Then in that case the whole idea of a protocol parameter in SSP
falls flat on its face. Because there is no other method, apart from
Received headers, for telling what was the original protocol used in
sending the message, and we all know how easy Received headers are
to spoof.
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.
So we are back to what Hector is saying. SSP MUST be applicable to
any message in RFC 2822 format, or any format similar to that (which
clearly includes News). Because other formats are regularly gated
_into_ SMTP (often with the removal of headers such as Newsgroups
and Path which might have indicated their origin). So sites that
publish strict/discardable/whatever policies will just have to be
careful.
If this view prevails, then the *SP should be defined as being
applicable to SMTP related messages, which includes any other
protocols that might be delivered to the same location as those
carried over SMTP.
-Doug
-
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html