I would think that probably the l*vpn and IPsec specs might be
better precedents for telling receivers to drop packets not
from the expected source.
However, in those cases, the attacks are probably less likely
to occur (compared to the SSP case) and the amount of legitimate
traffic that'd arrive at the receiver accidentally is probably
also less that in the case with SSP. However, the relative
similarities are probably debatable.
So, there're some precedents, but of course no exact match and
hence we get to decide what we want to do (and after that the
broader IETF community get to say what they think about it).
In the end, I think "unprecedented" is really a caution
that we should sit back and think before we do whatever we
do, but should not represent a barrier to doing something new,
if that's what we think is needed.
The question of how strongly or weakly to describe the sender's
actions/wishes is IMO a separable one, so I don't think we should
be that caught up with the nitty-gritty of specific possible
precedents here.
S.
Jim Fenton wrote:
> Dave Crocker wrote:
>>
>> Jim Fenton wrote:
>>> For those that are looking for a precedent, I'd like to point to RFC
>>> 2597 (Assured Forwarding PHB Group) as an example of where there is a
>>> requirement on the recipient, in this case of a packet, to handle it in
>>> a particular way. From Section 2: "Within an AF class, a DS node MUST
>>> NOT forward an IP packet with smaller probability..." In any case, the
>>> SSP draft is nowhere near as normative as this.
>>
>> Jim,
>>
>> 1. We seem to be seeing inconsistency between whether SSP is
>> providing information about potential signers, versus whether it is
>> directing the behavior of receivers. ("providing guidance" is giving
>> direction.)
> SSP is clearly providing information about the use of DKIM by domains.
> It is also allowing those domains to express their preference about the
> handling of mail that purports to come from them. The intent in this
> latter regard is that domains are encouraged to do as requested by the
> alleged originating domain, but that they are compliant with the
> specification even if they choose not to do so.
>> 2. RFC 2597 specifies actions relative to packets that are from the
>> specifier of the actions. SSP is about messages that the specifier
>> has not issued.
>
> True, but I consider that just a characteristic of the different use
> cases between SSP and Diffserv.
>>
>> 3. RFC 2597 has been at Proposed Standard for 8 years. Can you point
>> to some deployment discussion, so that we can see how broadly it has
>> been deployed and how well it works?
>
> The point is that RFC 2597 is an IETF standards-track document, and an
> example of a protocol which seeks to direct the behavior of receivers
> (to use your terminology). It does this with considerably more forceful
> language than the SSP draft currently uses.
>
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
