On Wed, 20 Feb 2008 18:30:53 -0000, Douglas Otis
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-
On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote:
On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis
s= Policy Scope (plain-text; OPTIONAL; default is "SMTP"). A
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
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.
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).
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
But if they publish "s=SMTP" and something leaves their domain via
UUCP/NNTP/whatever-else, then they are syaing it is OK not to be signed.
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
Or if you intend that the "s=SMTP" is to be avaluated 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; 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
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.
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?
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
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