On Wed, 20 Feb 2008 18:30:53 -0000, Douglas Otis <[EMAIL PROTECTED]>  
wrote:

> On Feb 20, 2008, at 3:41 AM, Charles Lindsey wrote:
>
>> On Fri, 15 Feb 2008 19:27:29 -0000, Douglas Otis <[EMAIL PROTECTED]
>> 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 <[EMAIL PROTECTED]
>>>> >
>>>> 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.

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  
reject/discard/suspect/whatever it.

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  
reject/discard/suspect/whatever it.

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  
delivered.

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                       
   Web: http://www.cs.man.ac.uk/~chl
Email:[EMAIL PROTECTED]: 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 
http://mipassoc.org/dkim/ietf-list-rules.html

Reply via email to